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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
