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