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 > 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. Is there anyway we can record a reason for the last shutdown? Something we can set in the flash, that u-boot can fetch? I'm just thinking about the somewhat-outstanding resume-fails-after-30-minutes-suspended problem, and how one might distinguish a purposeful power-off from a failure to resume. > - -Andy Mike
