Dear Dirk,
In message 49A427D1.6050700@googlemail.com you wrote:
Wolfgang Denk wrote:
Dear Nishanth Menon,
In message 49A296F0.4000509@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