On Wed, Jun 25, 2014 at 11:12:13AM +0100, Arnd Bergmann wrote: > On Wednesday 25 June 2014 10:57:36 Will Deacon wrote: > > So far, I've been avoiding the hardcoding. However, you could potentially > > build a system with a small number of SMRs (compared to the number of > > StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic > > configuration would be NP complete if we require an optimal SMR allocation. > > > > However: > > > > (1) I don't know of a system where this is the case > > (2) Not much work has been done on improving the dynamic allocator yet > > > > which is why I'm still favouring dynamic configuration in the driver. > > > > The other thing I forgot to mention earlier is that we need to support > > device hotplug in the future, so some level of dynamic configuration > > will always be required. > > Ok, got it. So we just hope that we can make dynamic configuration > work all the time, but if it all fails, then we come up with a > hardcoded configuration method. > > I guess this could be done similarly to how we handle clocks on > a lot of systems: generally these are dynamic, but you have the > option to provide hints in the clock controller node about how > you expect things to be configured. > > For the SMMU that could mean that (if we get into the situation you > describe), we add optional properties to the SMMU node itself > describing how we expect the SMRs to be used. That sounds good to me! Thanks for the discussion. 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
