On Tue, Mar 25, 2014 at 01:38:47AM +0100, Mike Turquette wrote: > Quoting Peter De Schrijver (2014-03-21 01:12:17) > > On Thu, Mar 20, 2014 at 10:23:08PM +0100, Mike Turquette wrote: > > > Quoting Tero Kristo (2014-03-05 05:10:17) > > > > Ping. > > > > > > > > Mike, any feedback on this? > > > > > > Hi Tero, > > > > > > Have you seen Sylwester's approach[1]? I prefer it since it is more > > > device-oriented and less "centralized". The clock consumer enumerates > > > the default parent or rate of a consumed clock. This can be made to work > > > > That assumes driver writers are aware of the clock tree topology. IME that's > > seldomly the case. > > It assumes no such thing. > > The point of Sylwester's patch is that if a driver consumes a clock and > needs to do the very typical setup regarding that clock's rate or > parent, then we now have a sensible way to express that in DT. > > One of the strengths of DT is that the C code does not have to know all > of the details about topology or how things are hooked up. We can hide > some of those cute embedded nonsense hacks in DTS and the device > integrator can manage it there. It would be much better to specify this as part of the clock provider binding though, as the person writing those, generally knows what topology needs to be setup. The driver writer writing the consumer node often doesn't. Cheers, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
