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 -- 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
