login
Header Space

 
 

Re: [PATCH 0/5] Clocklib: generic clocks framework

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Dmitry <dbaryshkov@...>
Cc: Paul Walmsley <paul@...>, <linux-kernel@...>, <akpm@...>, Haavard Skinnemoen <haavard.skinnemoen@...>, Russell King <rmk+lkml@...>, Paul Mundt <lethal@...>, pHilipp Zabel <philipp.zabel@...>, Pavel Machek <pavel@...>, <tony@...>, <hiroshi.DOYU@...>
Date: Saturday, April 26, 2008 - 2:02 pm

On Saturday 26 April 2008, Dmitry wrote:

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
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0/5] Clocklib: generic clocks framework, Dmitry Baryshkov, (Sun Apr 20, 4:29 am)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Paul Walmsley, (Mon Apr 21, 3:44 am)
Re: [PATCH 0/5] Clocklib: generic clocks framework, David Brownell, (Fri Apr 25, 6:46 pm)
Re: [PATCH 0/5] Clocklib: generic clocks framework, David Brownell, (Sat Apr 26, 12:29 pm)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Paul Walmsley, (Fri Apr 25, 5:36 am)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Paul Walmsley, (Fri May 2, 1:23 am)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Pavel Machek, (Mon May 5, 3:59 am)
Re: [PATCH 0/5] Clocklib: generic clocks framework, David Brownell, (Sat Apr 26, 2:02 pm)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Pavel Machek, (Fri Apr 25, 6:39 am)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Russell King, (Fri Apr 25, 4:20 pm)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Pavel Machek, (Fri Apr 25, 4:51 pm)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Russell King, (Fri Apr 25, 5:13 pm)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Russell King, (Fri Apr 25, 4:44 pm)
Re: [PATCH 0/5] Clocklib: generic clocks framework, Hiroshi DOYU, (Mon Apr 21, 5:15 am)
[PATCH 5/5] Clocklib: Use correct clock for IrDA on pxa, Dmitry Baryshkov, (Sun Apr 20, 4:31 am)
[PATCH 4/5] Clocklib: support ARM pxa sub-arch., Dmitry Baryshkov, (Sun Apr 20, 4:31 am)
[PATCH 3/5] Clocklib: support sa1100 sub-arch., Dmitry Baryshkov, (Sun Apr 20, 4:31 am)
[PATCH 2/5] Clocklib: debugfs support, Dmitry Baryshkov, (Sun Apr 20, 4:30 am)
speck-geostationary