On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote: > Maybe we can make clock-names non-optional though in the DT as an > incentive not to use the simple 1-clock "NULL" path.
Yeah, that was more what I was thinking - apply some pressure on people not to use the NULL clock feature for the device tree stuff. > Possibly yes, and that's a reason why we tend to discourage that ;-) But > again, it boils down to settling with a naming convention for a given > device. If clocks are added later on, the driver will have to cope with > the new clocks not existing, of course, or the platform can cater for > it. ...which is much easier if you discourage people from using the NULL name in the first place :) My concern is more about new device tree and older driver code than the other way round (which wouldn't suprise me, if only during things like bisection). > Do you have maybe a precise example scenario where your above statement > about the lack of facility for registering new clocks is a problem ? I'm > curious to see a real life example so I can think better about how it > can be solved (or whether it needs to be solved). There was a recent thread on linux-kernel (last week) about the tmio_mmc drivers - it's a MMC controller which is present in both some SH CPUs and some MFD chips. I can probably dig up a more exact reference if required. Probably you will be able to, like the ARMs have, get a very long way with just supporting the on-SoC clock tree just now and can punt on dealing with other things for now. It's where a large part of the interesting clocking in a lot of embedded systems is. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev