GTA series power design

[Andy Green]

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

Somebody in the thread at some point said:

| power management is an interesting cross-layer issue. Being a software
| guy, I will only comment on this side.

It does indeed go from the top to the very bottom.

| Using e.g. the org.freesmartphone.Device.PowerManagement API you can
| then turn on and turn off the devices via dbus.
|
| (The next step on top of that would be a policy engine, so that you
| could express rules like
|  * turn on GPS every 10 minutes for until you have a fix,
|  * turn off WLAN if idle for 2 minutes
|  * turn on AUX LED on missed call or missed calendar event

It sounds good and do-able.  The only thing to note is that in future,
the CPU will hopefully be prone to a quite advanced case of narcolepsy,
it can get externally pushed into suspend at any moment... sort of
suffer from blackouts driven by power optimization.  It means that
whatever the backbone for the timer scheduling is, it needs to be a bit
abstracted because on these devices it may actually be queuing wake
timer events at the MPU, not inside Linux.

It has an advantage that the one timed event policy encompasses and
naturally integrates wake from suspend, but really it needs taking care
of so we can still suspend randomly any time and not violate the
requested policies.

|> *Any power management project existing in open source project that could
|> suit for device power management?
|
| There's a couple of approaches, including HAL, OHM, PolicyKit, and a
| multitude of device-specific daemons. Neither one is ready to use nor
| did it really take off. I think we should carry on the work @
| freesmartphone.org for that.

DBUS seems very popular and not very heavy.

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

iEYEARECAAYFAkf0oAYACgkQOjLpvpq7dMom7gCghjAx/fkRair3AHJswUyot7BF
+v8An0lL9L/IL3RKTqe59YAYqBK7X+Bi
=fnvb
-----END PGP SIGNATURE-----