u-boot low-battery handling

[Joerg Reisenweber]

Am Do  28. August 2008 schrieb Mike Montour:
> Andy Green wrote:
> 
> > What I am hoping we can do here is boot at slow CPU for the initial part
> > of Linux boot to always be below 500mW on average, and stall in pcf50633
> > driver init (which will be early in boot with 2.6.26 soon) until we
> > either detect we have no charger, 1A charger, or get enumeration from
> > host PC and can use 500mA ower.  Typically this will add a second or so.
> 
> It's the "on average" that concerns me here, as that relies on having 
> enough battery capacity to supply current for the above-average pulses.
> 
> I've been doing quite a bit of testing in u-boot, and my current 
> preference is to have a simple check in u-boot/Qi that will program a 
> few PMU registers and then shut down the device if the battery is too 
> low. There can be a distinctive LED-flash pattern to tell the user that 
> this has happened, and we can allow the user to bypass this check by 
> holding Aux.
> 
> Related to this, I recommend programming the PMU as follows whenever we 
> turn the device off (e.g. "neo1973 poweroff" command, Linux shutdown, 
> low-battery shutdown described above):
>   - charger enabled
>   - 98mA usb fast-charge limit (MBCC5=0x19)
>   - wake-on-USB disabled (OOCWAKE bit 6)
> 
> In this configuration the device should automatically charge the battery 
> at a safe 100mA whenever it is connected to a power source (meaning 
> there's no need to wake the CPU). This even works for a battery in which 
> the internal cutoff has triggered (I've tested this), so we reduce the 
> chance that the user will need to find a "jump-start" battery.
> 
> When the device is suspended, wake-on-USB-insert/removal needs be 
> enabled so that the device can respond to changes in available USB 
> current (e.g. unplug from charger and connect to an unpowered hub).
> 
> I'll try to send an updated u-boot patch in the next day or two.

I strongly recommend reading of 
Battery Charging
    Specification
         Revision 1.0
          Mar 8, 2007
to be found at
http://www.usb.org/developers/devclass_docs/batt_charging_1_0.zip

for background data about behaviour of hosts etc.

First approach like above seems the right way to go. Though device should 
*try* to boot up anyway and simply die when current-limiter on USB-inbound 
current cuts out and we got no battery backup. As long as the PMU-registers 
stay in the state as mentioned above, we will end up same "place", except 
maybe the nice flash-pattern to inform user. User might not need any 
additional info if charging on 100mA is guaranteed even when device doesn't 
boot up.
We should check if there is an interrupt in PMU on reaching and going above 
Vbat-min, so we could wake device a second time at the moment battery has 
reached a minimum charge level sufficient for boot. This would be consistent 
with above mentioned spec and user expectations.

cheers
jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080829/25fb0d28/attachment.pgp