[RFC] [PATCH] Device Tree on ARM platform

[Russell King - ARM Linux]

On Sat, May 30, 2009 at 07:52:46PM +1000, Benjamin Herrenschmidt wrote:
> 
> > Sure.  My only big concern with it is that it compeltely sidesteps
> > clocking decisions so there's a lot of codecs it's not going to be
> > immediately useful with and I don't have a clear idea how it could be
> > extended to be so.  Most other things look like they can be added on
> > fairly easily when required.
> 
> Regarding clocks ...
> 
> Paulus and I had a discussion the other day and he mentioned a very good
> idea to represent the clock net in the device-tree.

I think the first thing to do is to get an accurate description of the
problem before thinking about how to come up with solutions.  I saw
that this kept coming up in Mark's emails, so I asked him about it
in private.

There are several issues surrounding clock stuff which he's seeing:

1. implementers of the clock API which have not been subject to my
   rigorous review abuse it to the point of making the API essentially
   useless, and that causes Mark problems.

   This basically comes down to people trying to uniquely name every
   single clock, and use just the name to do the lookup, ignoring the
   struct device.  This approach, really, does not work and makes the
   API pointless.

2. inter-relationships between several clocks.  To take his example,
   for clocking a DAC and ADC, you may have three clocks (dac_clk,
   adc_clk and bclk).  You may want dac_clk to be xkHz, adc_clk ykHz
   and bclk (which could well be related to both) to be zkHz.  For
   each of these, you might be able to accept an error of so-many-
   percent.

I believe (2) is an entirely separate problem to the device tree, and
really shouldn't concern the device tree beyond, maybe, providing the
contraints for individual clock _sources_.

(1) on the other hand is related, but is not really a device tree problem.
It's a problem with the way people use the API (even though that wrong
usage is explicitly documented as being wrong, this doesn't stop people
being lazy.)

I hadn't been doing the rigorous review of implementations on ARM as they
come in, in the interests of getting platform support into the kernel.
However, earlier this year I came up with a solution to this (clkdev) and
implemented it initially for the platforms I had, and later extended it to
the most complex ARM platform we have - OMAP.

clkdev doesn't stop the abuse per-se, but it _does_ make it damned easy
to change the lookup relationships, even build new relationships at run
time - which I can see will be an advantage to device tree stuff.

To put it another way, the conversion from broken-clk-get implementation
to clkdev is very simple and localised - you can use clkdev to continue
matching by clock connection name.  Once you've made that step, you can
then go through the drivers, one by one, fixing them and updating the
table.

Unlike previous attempts at putting a set of generic code behind the clk
API, clkdev does not place any requirements on the contents of struct clk.
To do so is fundamentally wrong - firstly, a struct clk is merely what the
clk_get API returns to represent the desired clock as a cookie, and
secondly, it has always been intended for there to be a many-to-one
relationship between the arguments to clk_get() and the returned cookie.

At the moment, clkdev lives in the ARM architecture, which seemed like a
sane place while it proves itself.  Moving it out into generic code is
the next step in its evolution - but I'm certainly not going to play
bun-fights with people over non-ARM clk API implementations, so it's
something other people will need to convert over to.

> It may also be useful to define properties in the clock controllers
> themselves mapping clock IDs to actual frequencies or things like that
> but I'm only half convinced here. IE. Let's start by defining the
> -wiring- and leave the -values- (on,off, slewing, freq adjustement,
> spreading) to an API between drivers and clock providers for now.

We have an API for that already (see above).