inhibiting suspend via dbus

[John Gilmore]

>     The problem with the pure hereustic approach is that there may
> be times when we don't have enough knowledge about the system state
> and more importantly the user's behaviour to really make a decision 
> without information from the application. For example, if I am streaming
> music on my computer, and I walk away for sometime, it may be perfectly
> OK to go to do a full suspend, or it maybe the case that I don't want to 
> go to sleep but it's OK for me to shutdown the screen.  Simply looking at 
> what is the current process doing (using network and audio resources) is 
> not enough to make a smart judgement on what to do in this situation. 
> There must be a way for the user to tell the application what to do
> and a way for the application to pass that information into the system 
> power manager.

There are already a couple of knobs for users to tweak their
power-control desires with (in the Sugar control panel).  We could add
a few more (though this makes more combinations to test, and to
explain, and that will break some things for some users).  User
controls are orthogonal to whether "Activities" request a suspend or
no suspending, which was the suggestion I was dissing.

> > We should understand why ohm isn't noticing that the activity updater
> > isn't idle.  Should Ohm be looking for a higher cpu idle% in the
> > seconds before it suspends?  Should it be looking for minimal numbers
> > of context switches per second before it suspends? ...
> 
> What happens when the updater is modified?  Do we have to reanalyze 
> the behaviour pattern everyime we have chage the updater and then rewrite 
> the heurestic code in OHM? What if I'm doing something else at the
> same time as running the updater which completely modifies the behaviour?
> And what about when we change to a new kernel and the scheduler behaviour
> changes (see #7603)?

For an idea of where Linux power management is going, see Richard
Woodruff's presentation from the Ottawa Linux Power Management summit:

  http://www.celinux.org/elc08_presentations/TI_OMAP3430_Linux_PM_reference.ppt
  http://article.gmane.org/gmane.linux.acpi.devel/33176

What OLPC is doing was cutting-edge -- before Richard got started.
And he's not putting kludges into applications -- he's hacking how the
kernel allocates resources (which is its job and its only job).

His code is in mainline kernels, runs on the Texas Instruments OMAP3
system-on-chip, and aims for cellphone-like battery life with
Linux-laptop-like features and performance.  (I have no inside
knowledge, but would be surprised if the OMAP3 wasn't a possible
candidate processor for the XO-2.)  My favorite slide is #3, the graph
of volts and amps -- which sits at zero volts, zero amps most of the
time, and rises to 0.9 volts at 50 mA occasionally, spending 94% of
its time at zero.  This is running Linux on a 550 MHz ARM.

In Richard's model, drivers clock down and/or power down their devices
whenever they aren't in use, and can rapidly power them up and restore
their registers as needed, invisibly to user software.  This includes
the "CPU driver", i.e. the scheduler, dispatcher, and cpuidle
implementation.  The CPU goes through 7 increasingly power-miserly
states, resuming from the deepest (CPU power-off) in about 30ms.

The reason the XO-1 has had so much trouble with suspend is because
it's a first-generation effort, using a processor that was designed
for Winblows' multi-second manual suspends.  Our board design also
took a lot of evolution and still has a few misfeatures.  Things will
be very different in the hardware world shortly.  OLPC gets
significant credit for pushing the chip industry to notice how badly
its power management sucked.  Let's not mess up our code base (or our
mindsets) while they're going through the design cycles to get it
right.

(The XO-1 hardware can do much better than it's doing.  I see in
Joyride-2263 that USB drivers are in modules now, so Ohm can unload
'em when it wants to suspend and resume in only HALF a second instead
of a whole second.  But when I enable "Extreme Power Management", ohm
is not actually powering off the USB bus and unloading the USB modules
yet!  My USB keyboard works if plugged in; and the modules are still
there.  Chris, does this need a new TRAC besides #7113 and #7434?)

	John