powering devices (was: [PATCH] odeviced-power-off-gps-at-init.patch)

[Rob Sims]

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
                        gps off
                        bluetooth on
                        wifi restore

  battery -> full power gsm retain
                        gps on
                        bluetooth on
                        wifi on

  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.

-- 
Rob
  C is quirky, flawed, and an enormous success
  		-- Dennis M. Ritchie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.linuxtogo.org/pipermail/smartphones-standards/attachments/20080913/d3ec31b5/attachment.pgp>