Power Management

[Richard Hughes]

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 :)

No, that's sane. I think the general plan was to put some of the
hardware policy control of this stuff out of session, else you're going
to need something of the complexity of gnome-power-manager. The OHM idea
is just that it's a really small daemon to talk to HAL and enforce
policy that's not based in the desktop. Other embedded projects need a
policy manager to start early and do actions quickly and securely, and I
figured we could leverage some of that.

Also, by not having hundreds of preferences to tweak, we don't need this
to be in the session, it can do simple policy matching in the system.

> > 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:

Sounds good.

> 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.

Sounds good. We just let the DCON do it's own thing here I guess.

>    b) Can put the Geode itself to sleep here

Manually, i.e. with /sys/power/sleep?

> 2) Turn panel refresh rate down from 50Hz to 25Hz (saves 60mW)
> 3) Backlight on/off/up/down

Do we have any concrete numbers on power consumption of the panel at
different brightnes levels?

> 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".

Sure. So there's nothing running in the session that needs wakeups?

> The motto is "sleep as often as possible".

Completely agree.

> > • 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".

Yes, sorry.

> > • 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.

Okay, sure. I can't test the suspend resume on my B2 so I don't know how
quick it actually is. I think blizzard is sorting me out with some new
h/w.

> > • 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.

Okay, sure. How do we turn off the mesh? Using iwconfig or hardware?

> > • 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.

Sure. What's the power consumption when in suspend state?

>   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.

Of course, I keep forgetting I'm not on a laptop...

> > • 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.

I was planning to use the 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.

Ahh, so you don't want a LED blinking every 30 seconds...

>   If the camera is on and no activity you're in
> is using the camera, there's something wrong.

Sure.

> 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.

Have you got assigned keys for this?

Richard.