Power Management

[Dan Williams]

On Fri, 2007-06-08 at 11:14 -0400, Dan Williams wrote:
> 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.

let me clarify here; this is somewhat activity dependent.  Ebook, Web,
Abiword, and text Chat are great cases for very aggressive suspend.  But
of course games are likely not.  The sugar shell itself may also have
different heuristics.

We will have Wake On LAN functionality too so that, for example, if
we're chatting with somebody, we can suspend the CPU and do DCON refresh
when idle, and then get woken up when the other person sends an IM.

dan

> > • 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
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel