Disallowing draining until bricking

Mike (mwester) mwester at dls.net
Thu Jul 17 16:53:30 CEST 2008

Andy Green wrote:
> 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


More information about the openmoko-kernel mailing list