mbox series

[0/3] Enable PCIe ATS for devicetree boot

Message ID 20240429113938.192706-2-jean-philippe@linaro.org (mailing list archive)
Headers show
Series Enable PCIe ATS for devicetree boot | expand

Message

Jean-Philippe Brucker April 29, 2024, 11:39 a.m. UTC
Before enabling Address Translation Support (ATS) in endpoints, the OS
needs to confirm that the Root Complex supports it. Obtain this
information from the firmware description since there is no architected
method. ACPI provides a bit via IORT tables, so add the devicetree
equivalent.

It was discussed a while ago [1], but at the time only a software model
supported it. Respin it now that hardware is available [2].

To test this with the Arm RevC model, enable ATS in the endpoint and
note that ATS is enabled. Address translation is transparent to the OS.

	-C pci.pcie_rc.ahci0.endpoint.ats_supported=1

    $ lspci -s 00:1f.0 -vv
    	Capabilities: [100 v1] Address Translation Service (ATS)
		ATSCap: Invalidate Queue Depth: 00
    		ATSCtl: Enable+, Smallest Translation Unit: 00


[1] https://lore.kernel.org/linux-iommu/20200213165049.508908-1-jean-philippe@linaro.org/
[2] https://lore.kernel.org/linux-arm-kernel/ZeJP6CwrZ2FSbTYm@Asurada-Nvidia/

Jean-Philippe Brucker (3):
  dt-bindings: PCI: generic: Add ats-supported property
  iommu/of: Support ats-supported device-tree property
  arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP

 .../devicetree/bindings/pci/host-generic-pci.yaml        | 6 ++++++
 drivers/iommu/of_iommu.c                                 | 9 +++++++++
 arch/arm64/boot/dts/arm/fvp-base-revc.dts                | 1 +
 3 files changed, 16 insertions(+)

Comments

Vidya Sagar May 15, 2024, 6:28 p.m. UTC | #1
Thanks, Jean for this series.
May I know the current status of it?
Although it was actively reviewed, I see that its current status is set to 
'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
What is the plan to get this series accepted?

Thanks,
Vidya Sagar

> -----Original Message-----
> From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Sent: Monday, April 29, 2024 5:10 PM
> To: will@kernel.org; lpieralisi@kernel.org; kw@linux.com; robh@kernel.org;
> bhelgaas@google.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> liviu.dudau@arm.com; sudeep.holla@arm.com; joro@8bytes.org
> Cc: robin.murphy@arm.com; Nicolin Chen <nicolinc@nvidia.com>; Ketan Patil
> <ketanp@nvidia.com>; linux-pci@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; iommu@lists.linux.dev; devicetree@vger.kernel.org;
> Jean-Philippe Brucker <jean-philippe@linaro.org>
> Subject: [PATCH 0/3] Enable PCIe ATS for devicetree boot
> 
> External email: Use caution opening links or attachments
> 
> 
> Before enabling Address Translation Support (ATS) in endpoints, the OS needs to
> confirm that the Root Complex supports it. Obtain this information from the
> firmware description since there is no architected method. ACPI provides a bit via
> IORT tables, so add the devicetree equivalent.
> 
> It was discussed a while ago [1], but at the time only a software model supported
> it. Respin it now that hardware is available [2].
> 
> To test this with the Arm RevC model, enable ATS in the endpoint and note that
> ATS is enabled. Address translation is transparent to the OS.
> 
>         -C pci.pcie_rc.ahci0.endpoint.ats_supported=1
> 
>     $ lspci -s 00:1f.0 -vv
>         Capabilities: [100 v1] Address Translation Service (ATS)
>                 ATSCap: Invalidate Queue Depth: 00
>                 ATSCtl: Enable+, Smallest Translation Unit: 00
> 
> 
> [1] https://lore.kernel.org/linux-iommu/20200213165049.508908-1-jean-
> philippe@linaro.org/
> [2] https://lore.kernel.org/linux-arm-kernel/ZeJP6CwrZ2FSbTYm@Asurada-
> Nvidia/
> 
> Jean-Philippe Brucker (3):
>   dt-bindings: PCI: generic: Add ats-supported property
>   iommu/of: Support ats-supported device-tree property
>   arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP
> 
>  .../devicetree/bindings/pci/host-generic-pci.yaml        | 6 ++++++
>  drivers/iommu/of_iommu.c                                 | 9 +++++++++
>  arch/arm64/boot/dts/arm/fvp-base-revc.dts                | 1 +
>  3 files changed, 16 insertions(+)
> 
> --
> 2.44.0
>
Bjorn Helgaas May 15, 2024, 6:52 p.m. UTC | #2
On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> Thanks, Jean for this series.
> May I know the current status of it?
> Although it was actively reviewed, I see that its current status is set to 
> 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> What is the plan to get this series accepted?

I probably marked it "handled elsewhere" in the PCI patchwork because
it doesn't touch PCI files (the binding has already been reviewed by
Rob and Liviu), so I assumed the iommu folks would take the series.
I don't know how they track patches.

The merge window is open now, so likely they would wait until the next
cycle so it would have some time in linux-next, but that's up to them.

> > -----Original Message-----
> > From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > Sent: Monday, April 29, 2024 5:10 PM
> > To: will@kernel.org; lpieralisi@kernel.org; kw@linux.com; robh@kernel.org;
> > bhelgaas@google.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> > liviu.dudau@arm.com; sudeep.holla@arm.com; joro@8bytes.org
> > Cc: robin.murphy@arm.com; Nicolin Chen <nicolinc@nvidia.com>; Ketan Patil
> > <ketanp@nvidia.com>; linux-pci@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; iommu@lists.linux.dev; devicetree@vger.kernel.org;
> > Jean-Philippe Brucker <jean-philippe@linaro.org>
> > Subject: [PATCH 0/3] Enable PCIe ATS for devicetree boot
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > Before enabling Address Translation Support (ATS) in endpoints, the OS needs to
> > confirm that the Root Complex supports it. Obtain this information from the
> > firmware description since there is no architected method. ACPI provides a bit via
> > IORT tables, so add the devicetree equivalent.
> > 
> > It was discussed a while ago [1], but at the time only a software model supported
> > it. Respin it now that hardware is available [2].
> > 
> > To test this with the Arm RevC model, enable ATS in the endpoint and note that
> > ATS is enabled. Address translation is transparent to the OS.
> > 
> >         -C pci.pcie_rc.ahci0.endpoint.ats_supported=1
> > 
> >     $ lspci -s 00:1f.0 -vv
> >         Capabilities: [100 v1] Address Translation Service (ATS)
> >                 ATSCap: Invalidate Queue Depth: 00
> >                 ATSCtl: Enable+, Smallest Translation Unit: 00
> > 
> > 
> > [1] https://lore.kernel.org/linux-iommu/20200213165049.508908-1-jean-
> > philippe@linaro.org/
> > [2] https://lore.kernel.org/linux-arm-kernel/ZeJP6CwrZ2FSbTYm@Asurada-
> > Nvidia/
> > 
> > Jean-Philippe Brucker (3):
> >   dt-bindings: PCI: generic: Add ats-supported property
> >   iommu/of: Support ats-supported device-tree property
> >   arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP
> > 
> >  .../devicetree/bindings/pci/host-generic-pci.yaml        | 6 ++++++
> >  drivers/iommu/of_iommu.c                                 | 9 +++++++++
> >  arch/arm64/boot/dts/arm/fvp-base-revc.dts                | 1 +
> >  3 files changed, 16 insertions(+)
> > 
> > --
> > 2.44.0
> > 
>
Jean-Philippe Brucker May 16, 2024, 7:35 a.m. UTC | #3
Hi,

On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > Thanks, Jean for this series.
> > May I know the current status of it?
> > Although it was actively reviewed, I see that its current status is set to 
> > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > What is the plan to get this series accepted?
> 
> I probably marked it "handled elsewhere" in the PCI patchwork because
> it doesn't touch PCI files (the binding has already been reviewed by
> Rob and Liviu), so I assumed the iommu folks would take the series.
> I don't know how they track patches.

Yes I think this can go through the IOMMU tree. Since patch 3 is still
missing an Ack, I'm resendng the series next cycle.

Thanks,
Jean

> 
> The merge window is open now, so likely they would wait until the next
> cycle so it would have some time in linux-next, but that's up to them.
Sudeep Holla May 16, 2024, 10:41 a.m. UTC | #4
On Thu, May 16, 2024 at 08:35:00AM +0100, Jean-Philippe Brucker wrote:
> Hi,
> 
> On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> > On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > > Thanks, Jean for this series.
> > > May I know the current status of it?
> > > Although it was actively reviewed, I see that its current status is set to 
> > > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > > What is the plan to get this series accepted?
> > 
> > I probably marked it "handled elsewhere" in the PCI patchwork because
> > it doesn't touch PCI files (the binding has already been reviewed by
> > Rob and Liviu), so I assumed the iommu folks would take the series.
> > I don't know how they track patches.
> 
> Yes I think this can go through the IOMMU tree. Since patch 3 is still
> missing an Ack, I'm resendng the series next cycle.
> 

Extremely sorry for that, since I saw Liviu on the thread, I assumed he
would have acked/reviewed 3/3 as well but now I see that is not the case.
That said, you must not delay the change just for the DTS file changes.
Anyways I will ack it now.

--
Regards,
Sudeep
Jean-Philippe Brucker May 16, 2024, 11:42 a.m. UTC | #5
On Thu, May 16, 2024 at 11:41:28AM +0100, Sudeep Holla wrote:
> On Thu, May 16, 2024 at 08:35:00AM +0100, Jean-Philippe Brucker wrote:
> > Hi,
> > 
> > On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> > > On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > > > Thanks, Jean for this series.
> > > > May I know the current status of it?
> > > > Although it was actively reviewed, I see that its current status is set to 
> > > > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > > > What is the plan to get this series accepted?
> > > 
> > > I probably marked it "handled elsewhere" in the PCI patchwork because
> > > it doesn't touch PCI files (the binding has already been reviewed by
> > > Rob and Liviu), so I assumed the iommu folks would take the series.
> > > I don't know how they track patches.
> > 
> > Yes I think this can go through the IOMMU tree. Since patch 3 is still
> > missing an Ack, I'm resendng the series next cycle.
> > 
> 
> Extremely sorry for that, since I saw Liviu on the thread, I assumed he
> would have acked/reviewed 3/3 as well but now I see that is not the case.
> That said, you must not delay the change just for the DTS file changes.
> Anyways I will ack it now.

Thanks Sudeep!  It's no problem really, I sent the series very late in the
cycle so wasn't really aiming for 6.10 anyway

Thanks,
Jean
Liviu Dudau May 21, 2024, 10:25 a.m. UTC | #6
On Thu, May 16, 2024 at 11:41:28AM +0100, Sudeep Holla wrote:
> On Thu, May 16, 2024 at 08:35:00AM +0100, Jean-Philippe Brucker wrote:
> > Hi,
> > 
> > On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> > > On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > > > Thanks, Jean for this series.
> > > > May I know the current status of it?
> > > > Although it was actively reviewed, I see that its current status is set to 
> > > > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > > > What is the plan to get this series accepted?
> > > 
> > > I probably marked it "handled elsewhere" in the PCI patchwork because
> > > it doesn't touch PCI files (the binding has already been reviewed by
> > > Rob and Liviu), so I assumed the iommu folks would take the series.
> > > I don't know how they track patches.
> > 
> > Yes I think this can go through the IOMMU tree. Since patch 3 is still
> > missing an Ack, I'm resendng the series next cycle.
> > 
> 
> Extremely sorry for that, since I saw Liviu on the thread, I assumed he
> would have acked/reviewed 3/3 as well but now I see that is not the case.
> That said, you must not delay the change just for the DTS file changes.
> Anyways I will ack it now.

Appologies, I was travelling last week and thought DT changes will be taken
via Robin.

Best regards,
Liviu

> 
> --
> Regards,
> Sudeep