XO 1.5 ACPI hardware support
| 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) (p) |
| 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 |
SB == southbridge, EC == embedded controller
(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, Richard seemed to think there was data missing from this interface, compared to the olpc-battery.c implementation for the xo-1. 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) Current (rev A) h/w will only generate events on one of the two transitions. Rev B boards can generate on either. Linux only supports automatic creation of a /dev/input/eventN node for power, sleep, and lid buttons. Support for ebook input node will require an external driver.
(l) Currently the lid will cause wakeups correctly, but because of a logic flip in dsdt.dsl, the wakeup occurs on lid close, not open. What we actually need is separately controllable wakeups on either transition.
(p) Currently the power button will cause wakeups correctly, but generates nothing on /dev/input/event0
(r) rtcwake can schedule alarms which successfully wake the system. 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.
One other thing: 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.
