ARM clock API to PowerPC
Mark Brown
broonie at sirena.org.uk
Thu Aug 13 08:20:31 EST 2009
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.
More information about the Linuxppc-dev
mailing list