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