| title: | Re RFC PATCH Device Tree on ARM platform |
|
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 theres a lot of codecs its not going to be
immediately useful with and I dont 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 Marks emails, so I asked him about it
in private.
There are several issues surrounding clock stuff which hes 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 shouldnt 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.
Its a problem with the way people use the API (even though that wrong
usage is explicitly documented as being wrong, this doesnt stop people
being lazy.)
I hadnt 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 doesnt 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 youve 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 Im certainly not going to play
bun-fights with people over non-ARM clk API implementations, so its
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 Im only half convinced here. IE. Lets 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).
-------------------------------------------------------------------
List admin: rel="nofollow" lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: rel="nofollow" www.arm.linux.org.uk/mailinglists/faq.php www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: rel="nofollow" www.arm.linux.org.uk/mailinglists/etiquette.php www.arm.linux.org.uk/mailinglists/etiquette.php
|
