Messages in this thread | | | From | David Brownell <> | Subject | Re: [PATCH 0/5] Clocklib: generic clocks framework | Date | Sat, 26 Apr 2008 11:02:15 -0700 |
| |
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 callers.
- 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |