[RFC,PATCH 1/7] arm: add a common struct clk

[benh@kernel.crashing.org (Benjamin Herrenschmidt)]

On Fri, 2010-01-08 at 09:42 +0000, Russell King - ARM Linux wrote:
> What is clear from the clk API as implemented today is that what's
> right
> for one platform isn't right for another platform.  That's why we have
> each platform implementing struct clk in their own way. 

Such platforms would just not set CONFIG_HAVE_COMMON_STRUCT_CLK then.

I think what Jeremy is trying to achieve is a way for platforms that
which to use the device-tree to retrieve the clock binding to be able to
chose to do so, using as much common code as possible.

The problem with the more "static" variants of struct clk is that while
they are probably fine for a single SoC with a reasonably unified clock
mechanism, having more than one clock source programmed differently and
wanting to deal with potentially out-of-SoC clock links between devices
becomes quickly prohibitive without function pointers.

The moment you start having function pointers, you may as well have a
common infrastructure for "indirect" clk ops since that eases code
re-use. Which you do already in some of the ARM platforms afaik.

For example, while discussing the porting of struct clk to powerpc a
while back with some ARM folks, some people told me one issue they had
was to use it to represent clocks between an external i2c PLL chip and
an external device.

Such a scenario becomes trivial to deal with using the device-tree, as
the i2c clock provider "registers" with the device-tree aware clock
infrastructure, which will then transparently, bind the device to the
clock provider and provide the right struct clk to the device.

But again, if a platform choice to use or not to use that facility. If a
platform prefers not to use the facility, for example for performances
reasons, or because of a lot of existing code which would be hard to
update or not worth changing, that platform then just needs to not set
CONFIG_HAVE_COMMON_STRUCT_CLK.

Cheers,
Ben.