suspend-to-disk

[Andres Salomon]

Hi,

I'd like to figure out how feasible it would be to implement
suspend-to-disk (STD) on the XO.  Currently, we support suspend-to-ram
(STR).  I'm aware that suspend-to-nand would probably be a better choice
of name compared to STD, but I'd prefer to stick with the name STD for now.

Use cases for STD:

1) Saving state upon low battery.

We're planning on having kids power on
and power off their XO very infrequently.  The quick STR and aggressive
power savings are intended to extended the battery life for as long as
possible, and make it so that kids don't have to deal with the traditional
shutdown-machine-when-not-in-use-for-short-periods-of-time mentality.
Unfortunately, we *are* going to run out of battery power, especially
given our target audience.  When that happens, the machine is not going
to be shut down gracefully.  Our filesystem and kernel should be fine,
but applications will have to manage their own state savings (ie, if
in the middle of composing a document, the document editor will need
to save the current progress in case of a crash or power outage).  This
is something that applications should do anyways, but not something that
we should require or depend upon applications to do.

If we're getting dangerously low on battery power, it makes sense to have
the machine save its state to NAND before powering off.  If the machine
is not in use and is in STR state, it will probably be woken up
on a regular basis by battery state change (SoC) events.  In the SoC
handler, if we discover that the battery is dangerously low, it makes
sense to save the machine's state to NAND and then go back to STR (or
power off).

2) Additional power savings in a "deep sleep" mode. 

On a lid close event, we'd normally put the DCON/panel to sleep, put
the rest of the machine to sleep, and wait around in STR state.
According to power measurements [0] done earlier, we consume 1.4W in
this state (with DCON off).  This is due to the wireless, EC,
keyboard/touchpad power rails, and possibly a bug in the DCON hardware
(if it *is* a bug in the hardware, STD might be our only available
workaround).  If we supported STD, we could turn additional rails off;
the machine would essentially power off, with the keyboard/touchpad rails
off, the EC's clocks shut down (dubbed "low power" mode), and only the
wireless active.  The obvious method for waking up from STD mode is
the power button, but the EC can also wake up from additional sources;
according to Richard Smith, the EC can wake up from GPIOs and some timers.
It may be possible to hook up lid switch events to the EC to wake up the
EC.

3) The battery swap scenario

We have X kids in a classroom, and they don't have enough power outlets
(if any) to power all of their laptops.  Our answer to this has been a
gang charger; the kids spend the day on battery power, swapping in
batteries from the gang charger when their batteries get low.  However,
that requires each child to shut down the machine when they pull their
battery out (unless they line up to use one of the few power outlets
available; getting kids to line up to do anything is a challenge).  STD
would be a much nicer solution; the machine goes into STD state, the
child swaps in a fully charged battery, the machine resumes, and the
child continues whatever activity they were in the middle of.  I'm
not sure the best way to trigger STD is in this scenario.


Implementation questions:

I'm not going to concern myself with our B1s, for they have more ram
and less nand.  Our B2s have 128MB of ram, and 512MB of nand; B3s and
up have 256MB of ram, and 1GB of nand.  We need to figure out just
how much space we'd need to set aside in a snapshot partition for STD.
I'm not sure what would be required from the OFW side; Mitch?  From
the kernel side, I still need to examine kernel/power/disk.c's
hibernate() and friends to see what will require changing on that side..

[0] http://dev.laptop.org/~joel/power-measurement-summary