lkml.org 
[lkml]   [2012]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 3/4] clk: introduce the common clock framework
> 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.

So

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()?

3) Maybe, if the parent is missing, clk_get_rate() should return an
error?

Andrew


\
 
 \ /
  Last update: 2012-03-08 07:31    [W:0.220 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site