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

[Dirk Behme]

Nishanth Menon wrote:
> 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..

As yesterday: Yes, I agree. Again ;)

Thanks

Dirk