2008/7/17 Mike (mwester) <[EMAIL PROTECTED]>: > Andy Green wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi - >> >> Folks in the wild have managed to drain their battery until it is not >> able to get the device over the VB_SYS problem on startup even with USB >> connected. >> >> As I see it there's a bunch of things we need to do to work towards >> disallowing this as something that can be done easily. >> >> 1: our battery monitoring stuff lives in the X world at the moment. For >> our purposes this either needs to become a daemon, or because of the >> critical nature of battery monitoring with this issue, better leave it >> as it is in X and add a kernel thread for this purpose alone. > > (Is there a smiley symbol for biting one's tongue?) > >> 2: PMU has LOWBAT concept based on VB+ pin of battery level. But, we >> need some considerable juice left in our battery to work around VB_SYS >> dip issue on next start. So, better that we monitor it from the kernel >> thread via HDQ where possible to learn true "capacity" figure and turn >> ourselves OFF if no USB and we reach say 3% capacity. Separately
PalmOS had a nice solution: at ~10% capacity it would suspend and refuse to resume until the bootloader can see that battery is above ~20% again. The ~10% was enough for at least three weeks. With modem forced off maybe we could reach a couple of days on Neo, that would perhaps be enough for non tech users to (almost) never have to witness the system boot up. >> userspace stuff can be looking at this as well and reacting earlier with >> UI feedback about critical battery state. But in the kernel, this >> critical action has less dependencies and we need to do it whether >> userspace is happy or not, or we brick the device for the user. >> >> 3: Suspend needs the wake scheduler that I mentioned a few times. We >> can book a wake from suspend periodically (period depends on capacity >> before suspend) and still turn ourselves OFF even from suspend at the 3% >> level, for the case it's stuck in a drawer for a month in suspend. >> >> 4: Stuff like PANIC response needs to time out and go OFF. S3C24xx has a watchdog timer for this (not sure if it's enabled in our current defconfig). The watchdog timer causes a reset and u-boot will know the reset came from the watchdog and can shut down. It is enabled through /sys or kernel params. Regards
