[PATCH v2] clk: Add support for rate table based dividers

[mturquette@ti.com (Mike Turquette)]

On 20120627-18:28, Sascha Hauer wrote:
> On Wed, Jun 27, 2012 at 04:31:33PM +0530, Rajendra Nayak wrote:
> > Some divider clks do not have any obvious relationship
> > between the divider and the value programmed in the
> > register. For instance, say a value of 1 could signify divide
> > by 6 and a value of 2 could signify divide by 4 etc.
> > Also there are dividers where not all values possible
> > based on the bitfield width are valid. For instance
> > a 3 bit wide bitfield can be used to program a value
> > from 0 to 7. However its possible that only 0 to 4
> > are valid values.
> > 
> > All these cases need the platform code to pass a simple
> > table of divider/value tuple, so the framework knows
> > the exact value to be written based on the divider
> > calculation and can also do better error checking.
> > 
> > This patch adds support for such rate table based
> > dividers.
> > 
> > Also since this means adding a new parameter to the
> > clk_register_divider(), update all existing users of
> > it.
> 
> I'm not sure whether we should overload the divider code with another
> type of divider. Maybe it would be better to add a new
> clk-divider-table.c for this? Just an idea, the result may or may not be
> better.
> 

Sascha,

I had the same concerns originally, but the code reuse in clk-divider.c
is pretty good.  Before this patch I have it about 200 lines, most of
which would have to be reproduced for a separate clk-rate-table.c.  So I
think marginally added complexity is OK compared to code duplication
(and duplicate bugfixes, etc).

Rajendra,

After thinking about it a bit more I still think a separate
clk_register_divider_table is needed.  Primarily this would reduce
needless churn in having to update all existing users of
clk_register_divider.  I also think that clearly separating the two
functions will make it a bit easier on folks trying to port their clocks
trees over.

Unless there is a technical reason why having two registration functions
is a bad idea, can you send a V4 with that new registration function?
I'll take it into clk-next.

Thanks,
Mike

> Sascha
> 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |