aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorHenrique de Moraes Holschuh <hmh@hmh.eng.br>2008-01-08 10:02:52 -0500
committerLen Brown <len.brown@intel.com>2008-02-01 22:26:08 -0500
commita713b4d7bca51e56cdb5357507f46674111d032c (patch)
tree6269011e5c2971df32c552eb60879c5a176de939 /Documentation
parent3b64b51d20d9b633bb2efe63af785a49f8092898 (diff)
ACPI: thinkpad-acpi: wakeup on hotunplug reporting
Handle some HKEY events that the firmware uses to report the reason for a wake up, and to also notify that the system could go back to sleep (if it woke up just to eject something from the bay, or to undock). The driver will report the reason of the last wake up in the sysfs attribute "wakeup_reason": 0 for "none, unknown, or standard ACPI wake up event", 1 for "bay ejection request" and 2 for "undock request". The firmware will also report if the operation that triggered the wake up has been completed, by issuing an HKEY 0x3003 or 0x4003 event. If the operation fails, no event is sent. When such a hotunplug sucessfull notification is issued, the driver sets the attribute "wakeup_hotunplug_complete" to 1. While the firmware does tell us whether we are waking from a suspend or hibernation scenario, the Linux way of hibernating makes this information not reliable, and therefore it is not reported. The idea is that if any of these attributes are non-zero, userspace might want to do something at the end of the "wake up from sleep" procedures, such as offering to send the machine back into sleep as soon as it is safe to do so. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/thinkpad-acpi.txt24
1 files changed, 24 insertions, 0 deletions
diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 3fb864733ca1..9d08e472ef74 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -325,6 +325,21 @@ sysfs notes:
325 May return -EPERM (write access locked out by module 325 May return -EPERM (write access locked out by module
326 parameter) or -EACCES (read-only). 326 parameter) or -EACCES (read-only).
327 327
328 wakeup_reason:
329 Set to 1 if the system is waking up because the user
330 requested a bay ejection. Set to 2 if the system is
331 waking up because the user requested the system to
332 undock. Set to zero for normal wake-ups or wake-ups
333 due to unknown reasons.
334
335 wakeup_hotunplug_complete:
336 Set to 1 if the system was waken up because of an
337 undock or bay ejection request, and that request
338 was sucessfully completed. At this point, it might
339 be useful to send the system back to sleep, at the
340 user's choice. Refer to HKEY events 0x4003 and
341 0x3003, below.
342
328input layer notes: 343input layer notes:
329 344
330A Hot key is mapped to a single input layer EV_KEY event, possibly 345A Hot key is mapped to a single input layer EV_KEY event, possibly
@@ -475,6 +490,15 @@ Non hot-key ACPI HKEY event map:
475The above events are not propagated by the driver, except for legacy 490The above events are not propagated by the driver, except for legacy
476compatibility purposes when hotkey_report_mode is set to 1. 491compatibility purposes when hotkey_report_mode is set to 1.
477 492
4930x2304 System is waking up from suspend to undock
4940x2305 System is waking up from suspend to eject bay
4950x2404 System is waking up from hibernation to undock
4960x2405 System is waking up from hibernation to eject bay
497
498The above events are never propagated by the driver.
499
5000x3003 Bay ejection (see 0x2x05) complete, can sleep again
5010x4003 Undocked (see 0x2x04), can sleep again
4780x5010 Brightness level changed (newer Lenovo BIOSes) 5020x5010 Brightness level changed (newer Lenovo BIOSes)
479 503
480The above events are propagated by the driver. 504The above events are propagated by the driver.