[PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration

[sricharan@codeaurora.org (Sricharan)]

Hi Lorenzo,

>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Lorenzo Pieralisi
>Sent: Thursday, January 19, 2017 8:11 PM
>To: Sricharan <sricharan@codeaurora.org>
>Cc: linux-arm-msm at vger.kernel.org; joro at 8bytes.org; will.deacon at arm.com; iommu at lists.linux-foundation.org; 'Robin Murphy'
><robin.murphy@arm.com>; linux-arm-kernel at lists.infradead.org
>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