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