powering devices (was: [PATCH] odeviced-power-off-gps-at-init.patch)
smartphones-z at robsims.com
Sun Sep 14 01:44:03 CEST 2008
On Tue, Sep 09, 2008 at 01:21:41AM +0200, Michael 'Mickey' Lauer wrote:
> Thanks for this patch,
> I don't think we should apply this right now though, let's think a bit more
> about how we actually want to handle the power situation wrt. peripherals.
> The basic question is what policy do we want to enforce?
> * All peripherals off on startup
> * All peripherals on on startup
> * All peripherals to the same state when we shut down the last time
How about a bit more general:
for each peripheral:
for each power state change (states: off, suspend, battery low, on
battery, on external low power, on external high power, etc.),
take an action - retain, restore, restoreoff, off, on
on: peripheral is turned on if not already on.
off: peripheral is turned off if not already off.
restore: peripheral state is restored from the last time the phone was
in this power state. This state could be saved only when the
user flips the state manually, or certain program interfaces.
This helps issues like turning on GPS with a healthy battery,
state changes to low battery; the "last" state for low
battery should not be remembered as on.
Store last state on user-directed events only.
restoreoff: restore state from immediately before the most recent
suspend/off state, ignoring what that powered state was.
retain: take no action.
The following is not meant to be a suggestion for defaults:
[any state] -> off: [all devices] action off
off -> battery gsm restoreoff
battery -> full power gsm retain
How about a user policy daemon? Hook the power change events and
switch power as desired. We just need to be sure it gets hit early
in power-on and late in shutdown/suspend to do switching and state
storage; other transitions could be lazy.
Provide a simple script for the default. Let the user replace with
complex scripts or even GUI applets as desired. The policy daemon can
even be extended by external factors, such as turning bluetooth on
when the phone rings, or turning it off after no peripheral has been
seen for three minutes.
> The proper location for dealing with this is OUsage.
> Next question is: what do we do on suspend/resume?
> * Do nothing and hope the kernel will handle everything
> * Save state and power off devices before suspend, power on after resume
> depending onstate
I don't really want to exactly match state before and after resume, so
relying on the kernel seems impractical if configurabilty is desired. I
may want different actions based on the suspend interval and the wakeup
reason, and even on the apps that are running. If I wake up
line-powered and see TangoGPS running, turn on GPS, regardless of what
the previous state was believed to be.
I consider the "save state" and "power off devices" as two separate
issues. I think state should be user space retained if retention is
desired, and the kernel should come up with peripherals off.
1) powering up with a weak battery would work better.
2) the policy daemon could react to buttons early in the boot sequence
to alter startup behavior on the fly - for example starting in
flight mode, even though normally things turn on at boot.
C is quirky, flawed, and an enormous success
-- Dennis M. Ritchie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the smartphones-standards