[PATCH v5 3/4] clk: introduce the common clock framework
mturquette at ti.com
Fri Mar 9 18:18:58 UTC 2012
On Wed, Mar 7, 2012 at 10:27 PM, Andrew Lunn <andrew at lunn.ch> wrote:
>> Assuming that some day OMAP code can be refactored to allow for lazy
>> (or at least initcall-based) registration of clocks then perhaps your
>> suggestion can take root. Which leads me to this question: are there
>> any other platforms out there that require the level of expose to
>> struct clk present in this patchset? OMAP does, for now, but if that
>> changes then I need to know if others require this as well.
> Hi Mike
> For kirkwood, i use static clk's for all but my root clock. I cannot
> statically know the rate of the root clock, so i have to determine it
> at boot time using heuristics, PCI ID, etc.
> I used statics thinking it would be less code. No idea if it actually
> is, and there is nothing stopping me moving to creating the clocks
> after creating the root clock.
> One comment i have about the current static clks. I completely missing
> you need to call __clk_init() on them and so ended up with lots of
> division by zero errors, since they did not have a parent, and so the
> code seemed not be to able to determine the rate.
> 1) Please add __clk_init() to the documentation in the section about
> static clocks.
> 2) Should maybe the name change? It seems strange having to call a
> __X() function. If this is a function which is supposed to be used,
> drop the __. Maybe clk_static_register()?
That function is used internally by clk_register and is only exposed
by clk-private.h, so I think the naming scheme is sane. I basically
want to create a sense of worry in anyone using clk-private.h :-)
> 3) Maybe, if the parent is missing, clk_get_rate() should return an
Non-root, non-fixed-rate, orphan clocks can return an error in this
case. Will update for V6. Any idea on best -EERROR? I'm thinking
ENODEV, but ECHILD and EPIPE are kinda funny in this context.
More information about the linaro-dev