RE: ARM clock API to PowerPC

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.

On Fri, Aug 14, 2009 at 10:07:44PM +1000, Benjamin Herrenschmidt wrote:

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

If you look at OMAP, doing that gets very expensive, both in terms of
number of lines of code, size of structure and maintainence thereof.
Neither does a 'clk_ops' structure containing all of the function
pointers work either for OMAP (OMAP has such a structure just for
enable and disable methods, of which there are about two or three to
chose from, but the rounding, set_rate and propagation methods are
per-clk.  This balance seems to work well for OMAP.)

FYI, there are 140 struct clk definitions for OMAP24xx, and 215 for
OMAP34xx, all statically initialized.  See arch/arm/mach-omap2/clock?4xx.h

-- 
Russell King