Power Management

[Dan Williams]

On Fri, 2007-06-08 at 14:51 +0100, Richard Hughes wrote:
> OLPC now uses the olpc-hardware-manager python service to do power
> management tasks. This is not really suitable for long term use, and we
> can't easily do clever things with this infrastructure.

Right; we'd pretty much decided that we should be moving most of the
functions that control hardware to HAL callouts and just poking HAL to
do things like this.  Perhaps my idea of how all this should work is out
of date :)

> I'm proposing to use OHM (ohm.freedesktop.org) to do the clever things,
> and apply system wide policy. OHM has working code, and I'm currently
> preparing a package for olpc. I've got some time now I'm interning at
> Red Hat (and now I've finished my exams...). I want to integrate this,
> and hopefully have a kick-ass solution that is long-term supportable in
> as little time as possible.
> 
> OHM sits above HAL and lets HAL do the heavy lifting for reporting
> events and doing actions. HAL is already packaged and being used for
> OLPC. OHM is incredibly lightweight, and has a flexible compiled plugin
> system for the rules, making it an ideal choice in my opinion. I wrote
> most of the code, so consider my opinion very biased :-)
> 
> I'm thinking about system power management interactions for the OLPC. So
> far I've got:

Just on the _display_ side we've got 4 orthogonal choices for power
management, so things can be as fine-grained as we want:

1) Let DCON do the display refreshes
   a) when we do this, there is no point to have the Video Processor of
      the Geode on.  So we can forcibly turn this off independent of
      the normal Geode sleep state.  The Graphics Processor will notice
      this automatically and power itself down.
   b) Can put the Geode itself to sleep here
2) Turn panel refresh rate down from 50Hz to 25Hz (saves 60mW)
3) Backlight on/off/up/down
4) Panel itself on/off

We also want to be _very_ aggressive about putting the system to sleep
and waking it up on keypresses or mouse events.  For example, the system
should go to sleep whenever it's idle for more then a few seconds.  The
canonical case here is ebook mode; if you haven't pressed a button for a
few seconds, make the DCON refresh the display and put the main CPU to
sleep.  Key presses will wake the machine up when you hit "page down".

The motto is "sleep as often as possible".

> • When system idle for > 10 seconds and on battery we dim screen to 40%
> • When system idle for > 30 seconds we turn the screen off

I assume here you mean "turn off backlight".

> • When system idle for > 1 minute we suspend, assuming we have no
> inhibits and CPU load is low

This is way too laid-back.  We should be suspending and letting the DCON
refresh the display within a few seconds of going idle.  A minute is
really a long time.

> • When AC removed reduce brightness by 20%
> • When battery power < 10% turn of wireless

Way too high a threshold here too.  The wireless should be always on
except when the machine is completely shut down.  It should be maybe 2%
or 3%, not 10.

> • When battery power < 2% then shutdown
> • When the lid is closed then turn off screen and suspend
> • When battery power < 30% and not on AC then tell applications to use
> low power mode (low quality video, only essential tasks)
> • When the power button is pressed then save state and shutdown (we
> probably should hibernate... can we do this yet?)

No, the power button is the "suspend me" button.  The only way of
completely powering off is either (a) through the UI or (b) removing the
battery.  We'll never be doing suspend-to-disk/hibernate because there's
just not enough flash.  It's either suspend-to-ram or off.

> • If we interrupt the screen dim or power-off, then the time to dim is
> doubled (task)
> • If we are inhibited (system update) we do not auto-suspend
> • If the ambient brightness is very high (outside mode), switch the
> panel into reflective mode

Not sure we can detect this, even with a camera.  We don't have a
brightness sensor like some phones do, and the camera should only be on
when it's needed by an activity (for security reasons).  There are also
hardware-connected LEDs that tell you when the camera and mic are on for
specifically this reason.  If the camera is on and no activity you're in
is using the camera, there's something wrong.

We may have to have some UI bits here or a keyboard combo to switch to
reflective mode since it's very hard to autodetect when you want this or
not.

Dan

> I've been talking much to cjb and dwmw2, and of course blizzard, and
> they have given me much of the hardware information I need.
> 
> Suggestions, feedback and cool feature ideas welcome,
> 
> Thanks,
> 
> Richard.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel