On 11/01/2013 10:34 AM, Will Deacon wrote: > 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? ... >>> 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. Well, the reason I ask is that if the SMMU clients know which SMMU they're affected by, it's easy for them to implement deferred probe. If the SMMU knows which clients it affects, the clients won't have access to that information, and hence implementing deferred probe will be hard. That then impacts what might be the preferred style of DT bindings for SMMUs. Of course, that is driver implementation details forcing a particular DT binding, which isn't great, but I expect similar issues would exist on any OS, so this doesn't seem too terrible in this case. -- 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
