[lkml]   [2008]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/5] Clocklib: generic clocks framework
On Saturday 26 April 2008, Dmitry wrote:
> > I wouldn't pretend to have a comprehensive list at this point.  But from a
> > brief look, your clk_round_rate() and clk_set_rate() implementations will
> > not work for the present OMAP clock tree.  In OMAP, many parent clocks do
> > not have the same rate as their children.
> You can easily override any calculations in your clk->set_rate/clk->round_rate/
> clk->get_rate functions.

Speaking of which: those clk_*() interfaces need to be better
specified. Right now they're too vague to support fully portable

- What kind of "rounding" is provided? Using a 10 MHz target
rate as an example, with a 48 MHz base and a binary divider:
* "not-lower-than" would give 12 MHz (divide-by-4)
* "not-higher-than" would give 6 MHz (divide-by-8)
* "closest" would give 12 MHz, only 2 MHz off
The differences can matter, depending on what the clock drives.

Similarly, for DPLL based clocks (out = (in/DIV)*MUL) there
can be "lowest power" goals, like "use biggest DIV that
produces an output within <this> error bound".

- Does clk_set_rate() round, or does it fail when it can't set
that exact rate? (Would an 0.05% difference matter?)

This issue is orthogonal to whether clocklib merges or not (and
if so, when) ... except that if it does merge, then the answers
from clocklib will become the de facto answer to those questions.

- Dave
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-04-26 20:05    [W:0.126 / U:2.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site