From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Tue, 24 Feb 2009 18:01:26 +0100 Subject: [U-Boot] Clock handling (wasRe: [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB) In-Reply-To: <49A32B54.3080606@gmail.com> References: <1234464946-20400-1-git-send-email-dirk.behme@googlemail.com> <1234464946-20400-2-git-send-email-dirk.behme@googlemail.com> <1234464946-20400-3-git-send-email-dirk.behme@googlemail.com> <1234464946-20400-4-git-send-email-dirk.behme@googlemail.com> <1234464946-20400-5-git-send-email-dirk.behme@googlemail.com> <1234464946-20400-6-git-send-email-dirk.behme@googlemail.com> <1234464946-20400-7-git-send-email-dirk.behme@googlemail.com> <20090222155940.GD9867@game.jcrosoft.org> <49A17BCD.1030803@googlemail.com> <6ed0b2680902230413o33f98059q7239cbba0114c2b3@mail.gmail.com> <49A296F0.4000509@gmail.com> <20090223213636.8E526832E43F@gemini.denx.de> <49A32B54.3080606@gmail.com> Message-ID: <49A427E6.5040305@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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