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