[PATCH] band-aid for stopping triggering the SECOND interrupt after modem wakeup

Andy Green andy at openmoko.com
Mon Jul 14 16:59:35 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Holger Freyther wrote:
|> On Monday 14 July 2008 12:14:59 Andy Green wrote:
|>
|>> Does anything use that ioctl interface, if so what for?
|> It is part of the /dev/rtc userspace API, I have not yet encountered
a user of
|> that feature in the wild. But codesearch from google is revealing
some users.
|
| Future uses of this might include periodic wakeups so that the device
| can alert the user of a low-battery situation.

I plan to add a "suspend-piercing sleep" scheduler for userspace apps
using the RTC soon, which is good for this plan, AFAIK it is the only
action I need to take about it.

| I think we get 8 seconds on the GTA01 on the BATLOW event, which is
| clearly not sufficient (we need the device to blink LEDs or make noise
| at least 30 mins before it exhausts the battery, IMO).  Does the GTA02
| provide us some other way to do this besides a periodic wakeup and a
| user-space app that checks battery state?

PMU LOWBAT concept is based on voltage at +ve terminal of battery.  From
a quick read of the BVM part of the datasheet it just looks
informational and not forcing a shutdown (unlike is Vsys goes too low).

Since we already have things looking periodically at battery level
(although they are bound into X stuff AFAIK, which is not ideal) we are
better off ignoring LOWBAT and using the wake scheduler to keep an eye
on the battery using HDQ for "capacity" if the battery has it or the PMU
ADC level if not.  It could vary the wake-to-check period according to
the capacity left too.

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

iEYEARECAAYFAkh7adEACgkQOjLpvpq7dMrIzACdHIgEXJPWCvPDwfmvl1lUv5+0
3X4An0Ag01qgADaGt7qiYjDMCYtzKu0B
=8YqY
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list