[U-Boot] [PATCH 6/7 v2] OMAP3: Add OMAP3 core changes for MUSB

[Wolfgang Denk]

Dear Dirk,

In message <49A427D1.6050700 at googlemail.com> you wrote:
> Wolfgang Denk wrote:
> > Dear Nishanth Menon,
> > 
> > In message <49A296F0.4000509 at gmail.com> you wrote:
> >>> He probably wants to say that clocks should be enabled only when "usb
> >>> start" is issued, as you might have u-boot compiled with USB defines
> >>> set, but never actually use USB.
> > 
> > Correct.
> 
> Don't get me wrong, but I find it a little funny that we are 
> speculating (?) here about what someone else might have wanted to say ;)

That was not my intention. What I meant was that the statement was
correct. U-Boot design rules say "Initialize devices only when they
are needed within U-Boot" (see for example
http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#2_Keep_it_Fast),
and applied to clocks that means we should enable clocks only when we
really need them. There are many reasons for that, power consumption
being one of them.

> While I totally agree, I think the point of discussion 
> (misunderstanding?) is what does "_enabling_ clock only if needed" mean.

If "needed" means that the clocks are needed to execute a specific
command within U-Boot.

> One can argue that "enabling clock only if needed" is done by
> 
> #ifdef MUSB
>   enable_musbclock()
> #endif
> 
> While doing this, clock is enabled if somebody _enables_ MUSB in 
> config. While doing this, clock is enabled when interface is enabled 
> (at compile time), assuming that user who enables interface in config 

One can argue like that, but it's wrong. The intention is to enable
interfaces only when really *used* by U-Boot to run some command. So
if nobody ever executes an USB command in U-Boot, then the clocks
should NOT be enabled.

> knows why and uses it. Else it makes no sense to enable it (in 
> config). And by enabling serial output over USB in upcoming patch, the 
> interface is used. Seems that this is my point of view ;)

Only if serial output over USB is permanently enabled this would make
sense. Otherwise, there is no reason to turn the clocks on  before  a
command in U-Boot turns on the serial output over USB.

> Other point of view of "enabling clock only if need" can be "enable 
> clock only if code is compiled into uboot _and_ is accessed (e.g. by 
> serial output over USB)" (i.e. runtime enable). I think this what 

Yes, that is the intention.

> Wolfgang's point of view is. I wonder why someone might enable an 
> interface for an bootloader at compile time, getting a larger binary, 
> but then not using it, though. But this might be an other topic ;)

Isn't that obvious? You enable features liek Ethernet and USB support
in the configuration because they offer features you  need.  You  may
for example download the kernel and application images and write them
to  flash. Then you boot many, many times from flash. Now, the vendor
ships a software update on USB sticks, so you plug in that stick  and
run  the update procedure. After that, you run from flash again for a
long time.

Of course it is important to have that features built  in  and  ready
available, but it makes no sense to acvtivate these on each and every
boot  - waiting for the Ethernet PHY to initialize and to establish a
link (or to time out) or performing a USB bus scan on each boot would
only add to the boot time and the power coinsumption  of  the  system
without any benefits.


Do you really mean you didn't know that? I cannot believe that.


> I wonder a little why you try to improve code that is ideally running 
> < 10s like a bootloader for e.g. power consumption aspects instead of 
> keeping it small, simple and easy to maintain. But this might be an 
> other topic, too ;)

Power consumption is just one aspect, as is boot time etc.  But  even
if  the  power consumption in U-Boot is negligible - the clocks would
most probably continue to run in Linux, too, right?

We had this problem and did see what  happens  when  we  for  example
enable  a  USB  controller  in  U-Boot  and don't shut it down before
booting an OS. The result was well over a year of bug hunting  and  a
lot  of frustration - both to the engineers and - even worse - to the
customers.

It makes perfect sense to shut off what's not in use. U-Boot goes
green :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The Gates in my computer are AND, OR and NOT; they are not Bill.