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.