RE: ARM clock API to PowerPC

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2009-08-14 at 13:29 +0200, Guennadi Liakhovetski wrote:
> but since they are quite long, in short, in them a patch has been 
> discussed, that allowed to re-use an MMC driver, used on some MFDs, on 
> SuperH SoCs. The patch was taking the "easy route" of adding the 
> possibility to use the clock API to the tmio_mmc.c driver, while leaving 
> it to use static clock configurations with MFD drivers. This approach has 
> been rejected and initially it has been suggested to implement a 
> platform-independent clock API like what had been proposed by clocklib, 
> but since the future of clocklib is unclear, it has then been decided to 
> remove the clock (and power) management from the driver proper and move 
> them to some callbacks. I.e., there would be more users interested in a 
> unified clock API, including other platforms and platform-independent 
> drivers like MFD. Currently the reason, why MFD drivers cannot implement 
> their own clock devices is that the "struct clk" differs between 
> platforms.

But there is no reason for it to differ !

My idea is that struct clock would contain function pointers for the
enable/disable/get_rate/ etc... methods

Thus it's up to clk_get() to provide an object with the right pointers.

Now, on ARM, it's currently done in such a way that it's mostly up to
the platform (though that's less true with clkdev).

But with the help of the device-tree, it becomes trivial to have
somebody register clock providers (ie, objects that can product struct
clk *) and bind them to driver.

I think struct clk is the way to go. The problem is to sort out the
binding between the clock provider and the driver. The DT is an easy and
nice way to do it for archs that have it. But there are other ways.

Cheers,
Ben.