Re: [PATCHv3 14/19] iommu/tegra: smmu: Get "nvidia,memory-clients" from DT

[Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>]

On Fri, Nov 01, 2013 at 04:08:52PM +0000, Stephen Warren wrote:
> On 10/31/2013 01:39 PM, Will Deacon wrote:
> > On Thu, Oct 31, 2013 at 07:25:25PM +0000, Stephen Warren wrote:
> >> On 10/31/2013 01:16 PM, Stephen Warren wrote:
> >>> Hmm. That's interesting. I see that the ARM SMMU has a list of the
> >>> clients it affects, whereas this Tegra series puts information into each
> >>> client device about the SMMU(s) that affect it. Is it better to flip the
> >>> Tegra binding around to match the style of the ARM SMMU?
> >>
> >> One question here: How do you ensure that the SMMU driver probe()s
> >> before probe() runs for devices affected by the SMMU?
> > 
> > I think we get away with this by virtue of nobody actually creating IOMMU
> > mappings from within drivers,
> 
> Where are the mapping set up? What prevents that action from happening
> before the IOMMU is set up and the various devices have their DMA ops
> hooked through the IOMMU? It's fairly clear how deferred probe of client
> devices could achieve that, but I'm quite unsure how some what other
> mechanism would ensure that.

This is the part where I start to struggle. If you look at a mainline
kernel, arm_iommu_create_mapping isn't really used, so it's difficult to
know at which point the IOMMU needs to be initialised across different ARM
SoCs.

For other architectures, it looks like the IOMMU initialisation hangs
directly off arch code (which in turn are driven from initcalls), but that's
generally possible because either the IOMMU is architected, or it's strongly
tied to PCI initialisation.

What are the requirements for Tegra? If the IOMMU isn't initialised, does it
act as a passthrough?

> > so the ordering is already handled. However, I
> > also have a patch queued to move the SMMU initialisation to a
> > subsys_initcall. I'm not particularly fond of that, but it seems to be the
> > done thing (even for other architectures).
> 
> We've been trying very hard not to rely on initcall ordering to solve
> issues like this, simply it doesn't scale to complex use-cases, and
> different HW/drivers/... might have conflicting requirements that aren't
> possible to solve by tweaking initcall levels. It seems much more
> preferable to use something that's guaranteed to work and adapt to any
> situation, such as deferred probe.

Indeed. As I said, I'm not a huge fan of initcalls either, but that's the
way things are at the moment. If deferred probe can be used to make that
less fragile, then that sounds like a good thing to do, perhaps across other
architectures too.

Will