Hi Lorenzo, >-----Original Message----- >From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Lorenzo Pieralisi >Sent: Thursday, January 19, 2017 8:11 PM >To: Sricharan <sricharan@xxxxxxxxxxxxxx> >Cc: linux-arm-msm@xxxxxxxxxxxxxxx; joro@xxxxxxxxxx; will.deacon@xxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; 'Robin Murphy' ><robin.murphy@xxxxxxx>; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx >Subject: Re: [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration > >Hi Sricharan, > >On Fri, Jan 06, 2017 at 04:24:00PM +0000, Lorenzo Pieralisi wrote: >> On Thu, Jan 05, 2017 at 08:21:53PM +0530, Sricharan wrote: >> > Hi, >> > >> > [...] >> > >> > >>> >> > >>> With the thinking of taking this series through, would it be fine if i >> > >>> cleanup the pci configure hanging outside and push it in to >> > >>> of/acpi_iommu configure respectively ? This time with all neeeded for >> > >>> ACPI added as well. Also on the last post of V4, Lorenzo commented >> > >>> that it worked for him, although still the of_match_node equivalent in >> > >>> ACPI has to be added. If i can get that, then i will add that as well >> > >>> to make this complete. >> > >> >> > >> Question: I had a look into this and instead of fiddling about with the >> > >> linker script entries in ACPI (ie IORT_ACPI_DECLARE - which I hope this >> > >> patchset would help remove entirely), I think that the only check we >> > >> need in IORT is, depending on what type of SMMU a given device is >> > >> connected to, to check if the respective SMMU driver is compiled in the >> > >> kernel and it will be probed, _eventually_. >> > >> >> > >> As Robin said, by the time a device is probed the respective SMMU >> > >> devices are already created and registered with IORT kernel code or >> > >> they will never be, so to understand if we should defer probing >> > >> SMMU device creation is _not_ really a problem in ACPI. >> > >> >> > >> To check if a SMMU driver is enabled, do we really need a linker >> > >> table ? >> > >> >> > >> Would not a check based on eg: >> > >> >> > >> /** >> > >> * @type: IOMMU IORT node type of the IOMMU a device is connected to >> > >> */ >> > >> static bool iort_iommu_driver_enabled(u8 type) >> > >> { >> > >> switch (type) { >> > >> case ACPI_IORT_SMMU_V3: >> > >> return IS_ENABLED(CONFIG_ARM_SMMU_V3); >> > > >> > >IS_BUILTIN(...) >> > > >> > >> case ACPI_IORT_SMMU: >> > >> return IS_ENABLED(CONFIG_ARM_SMMU); >> > >> default: >> > >> pr_warn("Unknown IORT SMMU type\n"); >> > > >> > >Might displaying the actual value be helfpul for debugging a broken IORT >> > >table? >> > > >> > >> return false; >> > >> } >> > >> } >> > >> >> > >> be sufficient (it is a bit gross, agreed, but it is to understand if >> > >> that's all we need) ? Is there anything I am missing ? >> > >> >> > >> Let me know, I will put together a patch for you I really do not >> > >> want to block your series for this trivial niggle. >> > > >> > >Other than that, though, I like it :) IORT has a small, strictly >> > >bounded, set of supported devices, so I really don't see the need to go >> > >overboard putting it on parity with DT when something this neat and >> > >simple will suffice. >> > > >> > >> > Ok sure, looks correct for me as well in whole of the context here. >> >> Ok, I put together a branch where you can find your original series >> plus some ACPI patches for you to test and use: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral >> >> Feel free to post the additional patches I added along with your series >> (that from what I gather you have reworked already) and please both have a >> look if the deferral mechanism I put in place in ACPI makes sense to you. > >Did you have time to make progress on this ? I think it is time we >posted the complete series to aim for 4.11 please, if you need help just >let us know. > I just posted V5 now. I have mainly reworked the pci dma configure code which was lying outside and having it all in one place in dma_configure. The ACPI changes from you looked fine for me. I have tested on arm64/32 with DT, and require testing help on ACPI. Thanks. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
