Disallowing draining until bricking
mwester at dls.net
Thu Jul 17 16:53:30 CEST 2008
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
> 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
More information about the openmoko-kernel