XO 1.5 ACPI hardware support


Jump to: navigation, search


This page is an attempt to summarize where and how we will support all of the XO's power management and reporting features on XO-1.5. The plan of record is to use ACPI for power management. The table below compares the implementation of various features on XO-1 to their (propose) implementation on XO-1.5.

SB == southbridge, EC == embedded controller

Wakeup and event implementations on XO-1 and XO-1.5
XO-1 XO-1.5
wakeups events wakeups events
power button SB/EC,non-maskable /dev/input (olpc-pm.c) ACPI /dev/input (linux ACPI)
lid SB, non-maskable /dev/input (olpc-pm.c) ACPI (l) /dev/input (linux ACPI)
ebook EC /dev/input (olpc-pm.c) ACPI (e) /dev/input (private)
AC insert EC /dev/input (olpc-pm.c) ACPI via EC (c) ? (a)
kbd/tpad EC n/a ACPI via EC (c) n/a
game keys EC n/a ACPI via EC (c) n/a
wlan EC n/a ACPI? (w) n/a
wlan-enable EC /sys/power/wlan-enabled (olpc-pm.c) ? (w) ? (w)
battery (b) EC /sys/class/power_supply/olpc-battery/* ? ACPI(+private?)
RTC "rtcwake" n/a "rtcwake" (r) n/a

(a) Recent XO-1 kernels have a /dev/input device which reports AC power jack plug/unplug events. Like the ebook switch, this will require a new driver for 1.5.

(b) ACPI reports battery state and info in /sys/class/power_supply/BATT, but this data has not been assessed for either completeness or accuracy. Last we talked, Data (ACR) is missing from this interface, compared to the olpc-battery.c implementation for the XO-1, so we'll be providing both interfaces in parallel. As for wakeups, XO-1 supports four different types: SOC change, state, error, critical.

(c) On XO-1, we had /sys/power/wakeup_events with which to control wakeups from the EC. We no longer have a kernel mechanism for setting the SCI mask. On XO-1, ohmd only uses the "all" "none but battery or AC" possibilities. powerd similarly uses only "all" and "none but battery").

(e) Linux only supports automatic creation of a /dev/input/eventN node for power, sleep, and lid buttons. Support for ebook input node requires an external driver.

(l) Currently the lid will cause wakeups correctly -- what we actually need is separately controllable wakeups on either transition.

(r) rtcwake can schedule alarms which successfully wake the system. BUG: The actual time taken by the sleep seems to be either 8 seconds too long, or 23 seconds too long.

(w) WLAN wakeups are intended to be driven via the SD interrupt. It's not clear how this will be combined with the ACPI wakeup mechanism. Also not clear how power on/off will be done.


It's not clear how all of the expected functionality of power management and events will be implemented on XO-1.5.

ACPI will buy us compatibility in some ways (common battery gauge code, for instance), but will complicate support for things like EC and ebook switch wakeups. For event reporting, it's clear that ACPI is insufficient. ACPI battery reporting may also be incomplete, from OLPC's point of view.

We used to have /sys/power/wakeup-source, which conveniently exposed the reason for the previous wakeup. It's not clear what the replacement for this will be -- I assume the information is available via ACPI somewhere, but I haven't found it. (and if it is, it likely will be incomplete: consider the various wakeup sources handled by the EC, for instance -- it's unlikely that ACPI supports the notion of "sub-"wakeup sources.)

Personal tools
  • Log in
  • Login with OpenID
About OLPC
About the laptop
About the tablet
OLPC wiki