Message ID | 20200213165049.508908-1-jean-philippe@linaro.org (mailing list archive) |
---|---|
Headers | show |
Series | PCI/ATS: Device-tree support and other improvements | expand |
Hi Jean-Philippe, On Thu, Feb 13, 2020 at 05:50:38PM +0100, Jean-Philippe Brucker wrote: > Jean-Philippe Brucker (11): > dt-bindings: PCI: generic: Add ats-supported property > PCI: Add ats_supported host bridge flag > PCI: OF: Check whether the host bridge supports ATS > ACPI/IORT: Check ATS capability in root complex node > PCI/ATS: Gather checks into pci_ats_supported() > iommu/amd: Use pci_ats_supported() > iommu/arm-smmu-v3: Use pci_ats_supported() > iommu/vt-d: Use pci_ats_supported() > ACPI/IORT: Drop ATS fwspec flag > arm64: dts: fast models: Enable PCIe ATS for Base RevC FVP > Documentation: Generalize the "pci=noats" boot parameter Nice patch-set! Thanks for the consolidation work. I can take it into the iommu-tree, given that the non-iommu parts get the necessary Acks. Regards, Joerg
On 2020/2/14 0:50, Jean-Philippe Brucker wrote: > Enable ATS on device-tree based systems, and factor the common ATS > enablement checks into pci_enable_ats(). > > ATS support in PCIe endpoints is discovered through the ATS capability, > but there is no common method for discovering whether the host bridge > supports ATS. Each vendor provides their own ACPI method: > * DMAR (Intel) reports ATS support per domain or per root port. > * IVRS (AMD) reports negative ATS support for a range of devices. > * IORT (ARM) reports ATS support for a root complex. Tested this patch set against 5.6-rc2 on a Kunpeng920 ARM server, I just confirmed that this patch set didn't break anything in my box with ACPI booting, PCI devices work as expected, FWIW, Tested-by: Hanjun Guo <guohanjun@huawei.com> Thanks Hanjun