[U-Boot] Clock handling (wasRe: [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB)

[Nishanth Menon]

Wolfgang Denk said the following on 02/23/2009 11:36 PM:
>
>> Comparing having all clock initialization at a central point (clock.c) -
>> which seems simple vs having get-put kind of clock apis in U-boot : I
>>     
>
> But the explicit rule is only to enable interfaces (and this includes
> clocks) when they are actually being used. Enabling all clocks even if
> not needed may for example add significantly to the power consumption
> and to EMC problems.
>   
I agree power consumption in u-boot is higher due to lack of power
management support -> but just having clocks is just one factor of it..
if power management is our concern, we probably need a unified strategy
for it. But inherently is'nt it an overkill at u-boot level (normal boot
time is less than few seconds)..

if we look at clock handling -> there are multiple levels of clock handling:
a) enable all required clocks at a go -> current omap3 code does that
b) proposed change -> clock enable/disable on need basis.
c) clock tree architecture -> OMAP3 as an example has a complex clock
tree, cascading clock dependencies etc. as an example: sys_clk OR clk32
could be functional clock source of gptimer module. to access gptimer
you need interface clock -> but once you program it, unless you need to
access the regs, you can essentially shut the interface clock off.. till
lets say interrupt occurs..  we could even think of cascading clock
divisors here.. just to make things a little more complex..

How about voltage handling etc.. are we thinking of a complete power
architecture here? what kind of gains do we expect by having just (b)?
My feel is that it would make things a lot more complex than the need
is.. For the modules one needs (they are not too many at u-boot level),
enable the clocks at one place. if we go to (b) we might as well go to
(c).. mebbe even pull in clocksource like u-boot-v2 has, while we are it..

But in anycase, do we have a generic clock architecture(clock register,
unregister, get, put apis) we are to adhere to? or are we holding off
each patch and rejecting unless they call thier own omap3_musb_clk_get,
omap3_musb_clk_put? that does not sound to be a good idea :(.. maybe I
am missing the conversation here..

Regards,
Nishanth Menon