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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
