On Mon, Jan 29, 2018 at 04:16:33PM +0000, Shameerali Kolothum Thodi wrote: > > -----Original Message----- > > From: Will Deacon [mailto:will.deacon@xxxxxxx] > > Sent: Monday, January 29, 2018 3:40 PM > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> > > Cc: lorenzo.pieralisi@xxxxxxx; robin.murphy@xxxxxxx; > > marc.zyngier@xxxxxxx; joro@xxxxxxxxxx; John Garry > > <john.garry@xxxxxxxxxx>; xuwei (O) <xuwei5@xxxxxxxxxx>; Guohanjun > > (Hanjun Guo) <guohanjun@xxxxxxxxxx>; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; > > devicetree@xxxxxxxxxxxxxxx; Linuxarm <linuxarm@xxxxxxxxxx> > > Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon > > 161010801 erratum(reserve HW MSI) > > On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote: > > > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC > > > deviates from the standard implementation and this breaks PCIe MSI > > > functionality when SMMU is enabled. > > > > > > The HiSilicon erratum 161010801 describes this limitation of certain > > > HiSilicon platforms to support the SMMU mappings for MSI transactions. > > > On these platforms GICv3 ITS translator is presented with the deviceID > > > by extending the MSI payload data to 64 bits to include the deviceID. > > > Hence, the PCIe controller on this platforms has to differentiate the > > > MSI payload against other DMA payload and has to modify the MSI payload. > > > This basically makes it difficult for this platforms to have a SMMU > > > translation for MSI. > > > > > > This patch implements an ACPI based quirk to reserve the hw msi > > > regions in the smmu-v3 driver which means these address regions will > > > not be translated and will be excluded from iova allocations. > > > > > > To implement this quirk, the following changes are incorporated: > > > 1. Added a generic helper function to IORT code to retrieve and reserve > > > the associated ITS base address from a device IORT node. The function > > > has a check for smmu model to determine whether the platform requires > > > the HW MSI reservation or not. > > > 2. Added smmu node entries and explicitly disabled them in hip06/hip07 > > > dts files so that users are warned about the non-DT support for this > > > erratum. > > > > [...] > > > > > arch/arm64/boot/dts/hisilicon/hip06.dtsi | 56 ++++++++++++++++ > > > arch/arm64/boot/dts/hisilicon/hip07.dtsi | 25 +++++++ > > > drivers/acpi/arm64/iort.c | 111 > > ++++++++++++++++++++++++++++++- > > > drivers/iommu/dma-iommu.c | 8 ++- > > > drivers/irqchip/irq-gic-v3-its.c | 3 +- > > > include/linux/acpi_iort.h | 7 +- > > > 6 files changed, 204 insertions(+), 6 deletions(-) > > > > It occurred to me this morning that this series probably isn't queued anywhere > > because it's not obvious which tree is supposed to take it and I can't see it in - > > next. > > > > Is this one for arm64, IOMMU, irqchip or something else? It's probably missed > > the boat for 4.16 now... > > > > I have been trying to ping you guys on this[1]. My expectation was that it will be > through IOMMU. Anyway missed the boat now, I will re-spin for 4.17. The problem with "ping" emails is that they don't really mean anything. In this case, everybody probably assumed somebody else was picking it up so you didn't get a reply. Joerg may be ok pulling this, but it's odd to have dts changes going via his tree. You might want to split those out, at least. Talk to him. Will -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
