On 07/17/2015 05:36 AM, Al Stone wrote:
On 06/16/2015 07:09 AM, Hanjun Guo wrote:
IORT, IO remapping tables, which is a table to describe the connections of PCI root complex, devices, ITS (msi controller) and SMMU, for example, it presents the topology of which device under which SMMU and(or) ITS.
This patch set first do some cleanup for the ITS dirver, then init the ITS with the information presented by MADT ITS entries, then follows the IORT spec, implementing:
PCI root complex using ITS as msi controller, mapping its domain (segemnt) number with the MSI controller;
init the SMMU and use the mapping of PCI and no-PCI device to SMMU to connect them
No-PCI devices using MSI (connect to ITS) is not covered by this patch set.
please refer to the ARM documentation: http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapp...
This patch set is based on Tomasz Nowicki's work, but I rework some of the patches significantly, more work is needed for this patch set and I'm still not satisfy with the some of implementation, anyway, I will continue working on that, and at the same time, sending them out for review to see if there are some major problems.
you can get them form git://git.linaro.org/leg/acpi/acpi.git devel
Comments and test are warmly welcomed.
Hanjun Guo (5): irqchip / GICv3: remove gic root node in ITS irqchip / GICv3 / ITS: mark its_init() as __init irqchip/GICv3/ITS: refator ITS dt init code to prepare for ACPI irqchip: gicv3: its: probe ITS in ACPI way ARM64, ACPI, PCI, MSI: I/O Remapping Table (IORT) initial support.
Tomasz Nowicki (2): arm, smmu: Use more generic structure for SMMU master list. ARM64, ACPI, IORT: Bind SMMU driver via IORT table
drivers/acpi/Kconfig | 3 + drivers/acpi/Makefile | 1 + drivers/acpi/iort.c | 536 +++++++++++++++++++++++++++++++++++++++ drivers/acpi/pci_root.c | 2 + drivers/iommu/arm-smmu.c | 290 ++++++++++++++++----- drivers/irqchip/Kconfig | 1 + drivers/irqchip/irq-gic-v3-its.c | 188 ++++++++++---- include/linux/iort.h | 63 +++++ 8 files changed, 966 insertions(+), 118 deletions(-) create mode 100644 drivers/acpi/iort.c create mode 100644 include/linux/iort.h
So, in general, these patches seem okay. My primary concern is: can we test them? There's enough subtle stuff here to give me a headache -- especially since there's a connection to virtualization. If we can test it, can we do that on anything other than the Cavium ThunderX that no one else has access to?
I'm not sure if FVP base model can test it or not, I will try to find it, I will let you know.
I think for now, Thunder-X is the best platform for testing.
Thanks Hanjun