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.