matt_hsu wrote: > Attached file is the patch for initial power setting. Basically, it's > necessary to check the following conditions are satisfied with boot up.
Thanks a lot ! I picked this up and rearranged some of the logic. I didn't use the battery voltage check yet (but see below). My current experimental version is here: http://svn.openmoko.org/trunk/src/target/u-boot/patches/wait-for-power-DONTUSE.patch (Not in series and not really useful anyway.) What this does is that it leaves the LCM dark until we actually need it. I put the wait loop into board_late_init, like you did. It's not a great place, because all the driver initialization has been done at that point, so we may draw more power than we need. (In fact, I had to move much of the video initialization into board_late_init.) However, given that we need USB and interrupts to be available at that time, it's also hard to find a better place, without plenty of changes to board-independent code. The current measurements are here: http://people.openmoko.org/werner/wait-for-power-try1/usb-batt.html Sequence of events: - disconnect USB D+/D- - apply power to USB and battery - connect D+/D- after 5 blinks - stop somewhere in kernel startup The LED blinking at 2Hz is clearly visible. (The 50mA drop is due to the missing base resistors in GTA02v5.) Alas, we still draw a lot more power (about 200mA) than we should (about 80mA for GTA02v6 or 50mA if we want this to work also on GTA02v5), even when the LED is off. We probably power a number of things we don't need, so GPIO and PMU intialization want a second look. I also noticed that we set LEDENA.led_on during PMU init. This looks questionable. Furthermore, we should run at a slower clock. All we need to be at full speed is USB. The rest can be (almost) as slow as it wants to be. Now, this is a lot of changes. Changes we'd also need to make if we wanted to find a "100mA corridor" to just bring up Linux and let it handle all the details of power management. Another thing I noticed is that I actually can't get the system to power up without a high enough battery voltage. Not sure if this for real or just an artefact of my test setup. Time for some more PCF50633 manual reading. Matt, is this why you implemented that battery voltage threshold ? What also needs looking into is why we actually charge in the first ~1200ms. The PCF50633-04 comes with a USB current limit of 500mA pre-configured, which we only reduce to 100mA in board_late_init, so drawing more than 100mA is expected (but undesired) behaviour at this point. There's also the question of what really happens if we don't do all this, and just go ahead and try to boot. At least for NOR, we don't really care about being nice to the battery. (If you have a u-boot emergency and a battery situation at the same time, just consider staying in bed that day ;-) - Werner
