| Message ID | 20240429113938.192706-2-jean-philippe@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Enable PCIe ATS for devicetree boot | expand |
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 >
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 > > >
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.
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
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
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
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(+)