Disallowing draining until bricking

Andy Green andy at openmoko.com
Thu Jul 17 12:03:20 CEST 2008


-----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.

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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh/GOEACgkQOjLpvpq7dMq1FACfdofH3Eff2hZ4YHCLPZItENEf
vAMAnRBFH00Jr9cLhGsjh7eUc+zmA6jc
=kMr3
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list