From: Mauro Carvalho Chehab Date: Thu, 18 Apr 2019 14:12:57 +0000 (-0300) Subject: docs: laptops: convert to ReST X-Git-Url: http://git.cdn.openwrt.org/?a=commitdiff_plain;h=b02f1651ff7758c4db0d759ab765d39986a79f5a;p=openwrt%2Fstaging%2Fblogic.git docs: laptops: convert to ReST Rename the laptops documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab Acked-by: Andy Shevchenko --- diff --git a/Documentation/ABI/testing/sysfs-block-device b/Documentation/ABI/testing/sysfs-block-device index 82ef6eab042d..0d57bbb4fddc 100644 --- a/Documentation/ABI/testing/sysfs-block-device +++ b/Documentation/ABI/testing/sysfs-block-device @@ -45,7 +45,7 @@ Description: - Values below -2 are rejected with -EINVAL For more information, see - Documentation/laptops/disk-shock-protection.txt + Documentation/laptops/disk-shock-protection.rst What: /sys/block/*/device/ncq_prio_enable diff --git a/Documentation/ABI/testing/sysfs-platform-asus-laptop b/Documentation/ABI/testing/sysfs-platform-asus-laptop index cd9d667c3da2..d67fa4bafa70 100644 --- a/Documentation/ABI/testing/sysfs-platform-asus-laptop +++ b/Documentation/ABI/testing/sysfs-platform-asus-laptop @@ -31,7 +31,7 @@ Description: To control the LED display, use the following : echo 0x0T000DDD > /sys/devices/platform/asus_laptop/ where T control the 3 letters display, and DDD the 3 digits display. - The DDD table can be found in Documentation/laptops/asus-laptop.txt + The DDD table can be found in Documentation/laptops/asus-laptop.rst What: /sys/devices/platform/asus_laptop/bluetooth Date: January 2007 diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index ed104a44e8b2..a342dd5c95a9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4347,7 +4347,7 @@ Format: sonypi.*= [HW] Sony Programmable I/O Control Device driver - See Documentation/laptops/sonypi.txt + See Documentation/laptops/sonypi.rst spectre_v2= [X86] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. diff --git a/Documentation/laptops/asus-laptop.rst b/Documentation/laptops/asus-laptop.rst new file mode 100644 index 000000000000..95176321a25a --- /dev/null +++ b/Documentation/laptops/asus-laptop.rst @@ -0,0 +1,271 @@ +================== +Asus Laptop Extras +================== + +Version 0.1 + +August 6, 2009 + +Corentin Chary +http://acpi4asus.sf.net/ + + This driver provides support for extra features of ACPI-compatible ASUS laptops. + It may also support some MEDION, JVC or VICTOR laptops (such as MEDION 9675 or + VICTOR XP7210 for example). It makes all the extra buttons generate input + events (like keyboards). + + On some models adds support for changing the display brightness and output, + switching the LCD backlight on and off, and most importantly, allows you to + blink those fancy LEDs intended for reporting mail and wireless status. + +This driver supersedes the old asus_acpi driver. + +Requirements +------------ + + Kernel 2.6.X sources, configured for your computer, with ACPI support. + You also need CONFIG_INPUT and CONFIG_ACPI. + +Status +------ + + The features currently supported are the following (see below for + detailed description): + + - Fn key combinations + - Bluetooth enable and disable + - Wlan enable and disable + - GPS enable and disable + - Video output switching + - Ambient Light Sensor on and off + - LED control + - LED Display control + - LCD brightness control + - LCD on and off + + A compatibility table by model and feature is maintained on the web + site, http://acpi4asus.sf.net/. + +Usage +----- + + Try "modprobe asus-laptop". Check your dmesg (simply type dmesg). You should + see some lines like this : + + Asus Laptop Extras version 0.42 + - L2D model detected. + + If it is not the output you have on your laptop, send it (and the laptop's + DSDT) to me. + + That's all, now, all the events generated by the hotkeys of your laptop + should be reported via netlink events. You can check with + "acpi_genl monitor" (part of the acpica project). + + Hotkeys are also reported as input keys (like keyboards) you can check + which key are supported using "xev" under X11. + + You can get information on the version of your DSDT table by reading the + /sys/devices/platform/asus-laptop/infos entry. If you have a question or a + bug report to do, please include the output of this entry. + +LEDs +---- + + You can modify LEDs be echoing values to `/sys/class/leds/asus/*/brightness`:: + + echo 1 > /sys/class/leds/asus::mail/brightness + + will switch the mail LED on. + + You can also know if they are on/off by reading their content and use + kernel triggers like disk-activity or heartbeat. + +Backlight +--------- + + You can control lcd backlight power and brightness with + /sys/class/backlight/asus-laptop/. Brightness Values are between 0 and 15. + +Wireless devices +---------------- + + You can turn the internal Bluetooth adapter on/off with the bluetooth entry + (only on models with Bluetooth). This usually controls the associated LED. + Same for Wlan adapter. + +Display switching +----------------- + + Note: the display switching code is currently considered EXPERIMENTAL. + + Switching works for the following models: + + - L3800C + - A2500H + - L5800C + - M5200N + - W1000N (albeit with some glitches) + - M6700R + - A6JC + - F3J + + Switching doesn't work for the following: + + - M3700N + - L2X00D (locks the laptop under certain conditions) + + To switch the displays, echo values from 0 to 15 to + /sys/devices/platform/asus-laptop/display. The significance of those values + is as follows: + + +-------+-----+-----+-----+-----+-----+ + | Bin | Val | DVI | TV | CRT | LCD | + +-------+-----+-----+-----+-----+-----+ + | 0000 | 0 | | | | | + +-------+-----+-----+-----+-----+-----+ + | 0001 | 1 | | | | X | + +-------+-----+-----+-----+-----+-----+ + | 0010 | 2 | | | X | | + +-------+-----+-----+-----+-----+-----+ + | 0011 | 3 | | | X | X | + +-------+-----+-----+-----+-----+-----+ + | 0100 | 4 | | X | | | + +-------+-----+-----+-----+-----+-----+ + | 0101 | 5 | | X | | X | + +-------+-----+-----+-----+-----+-----+ + | 0110 | 6 | | X | X | | + +-------+-----+-----+-----+-----+-----+ + | 0111 | 7 | | X | X | X | + +-------+-----+-----+-----+-----+-----+ + | 1000 | 8 | X | | | | + +-------+-----+-----+-----+-----+-----+ + | 1001 | 9 | X | | | X | + +-------+-----+-----+-----+-----+-----+ + | 1010 | 10 | X | | X | | + +-------+-----+-----+-----+-----+-----+ + | 1011 | 11 | X | | X | X | + +-------+-----+-----+-----+-----+-----+ + | 1100 | 12 | X | X | | | + +-------+-----+-----+-----+-----+-----+ + | 1101 | 13 | X | X | | X | + +-------+-----+-----+-----+-----+-----+ + | 1110 | 14 | X | X | X | | + +-------+-----+-----+-----+-----+-----+ + | 1111 | 15 | X | X | X | X | + +-------+-----+-----+-----+-----+-----+ + + In most cases, the appropriate displays must be plugged in for the above + combinations to work. TV-Out may need to be initialized at boot time. + + Debugging: + + 1) Check whether the Fn+F8 key: + + a) does not lock the laptop (try a boot with noapic / nolapic if it does) + b) generates events (0x6n, where n is the value corresponding to the + configuration above) + c) actually works + + Record the disp value at every configuration. + 2) Echo values from 0 to 15 to /sys/devices/platform/asus-laptop/display. + Record its value, note any change. If nothing changes, try a broader range, + up to 65535. + 3) Send ANY output (both positive and negative reports are needed, unless your + machine is already listed above) to the acpi4asus-user mailing list. + + Note: on some machines (e.g. L3C), after the module has been loaded, only 0x6n + events are generated and no actual switching occurs. In such a case, a line + like:: + + echo $((10#$arg-60)) > /sys/devices/platform/asus-laptop/display + + will usually do the trick ($arg is the 0000006n-like event passed to acpid). + + Note: there is currently no reliable way to read display status on xxN + (Centrino) models. + +LED display +----------- + + Some models like the W1N have a LED display that can be used to display + several items of information. + + LED display works for the following models: + + - W1000N + - W1J + + To control the LED display, use the following:: + + echo 0x0T000DDD > /sys/devices/platform/asus-laptop/ + + where T control the 3 letters display, and DDD the 3 digits display, + according to the tables below:: + + DDD (digits) + 000 to 999 = display digits + AAA = --- + BBB to FFF = turn-off + + T (type) + 0 = off + 1 = dvd + 2 = vcd + 3 = mp3 + 4 = cd + 5 = tv + 6 = cpu + 7 = vol + + For example "echo 0x01000001 >/sys/devices/platform/asus-laptop/ledd" + would display "DVD001". + +Driver options +-------------- + + Options can be passed to the asus-laptop driver using the standard + module argument syntax (= when passing the option to the + module or asus-laptop.= on the kernel boot line when + asus-laptop is statically linked into the kernel). + + wapf: WAPF defines the behavior of the Fn+Fx wlan key + The significance of values is yet to be found, but + most of the time: + + - 0x0 should do nothing + - 0x1 should allow to control the device with Fn+Fx key. + - 0x4 should send an ACPI event (0x88) while pressing the Fn+Fx key + - 0x5 like 0x1 or 0x4 + + The default value is 0x1. + +Unsupported models +------------------ + + These models will never be supported by this module, as they use a completely + different mechanism to handle LEDs and extra stuff (meaning we have no clue + how it works): + + - ASUS A1300 (A1B), A1370D + - ASUS L7300G + - ASUS L8400 + +Patches, Errors, Questions +-------------------------- + + I appreciate any success or failure + reports, especially if they add to or correct the compatibility table. + Please include the following information in your report: + + - Asus model name + - a copy of your ACPI tables, using the "acpidump" utility + - a copy of /sys/devices/platform/asus-laptop/infos + - which driver features work and which don't + - the observed behavior of non-working features + + Any other comments or patches are also more than welcome. + + acpi4asus-user@lists.sourceforge.net + + http://sourceforge.net/projects/acpi4asus diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt deleted file mode 100644 index 5f2858712aa0..000000000000 --- a/Documentation/laptops/asus-laptop.txt +++ /dev/null @@ -1,257 +0,0 @@ -Asus Laptop Extras - -Version 0.1 -August 6, 2009 - -Corentin Chary -http://acpi4asus.sf.net/ - - This driver provides support for extra features of ACPI-compatible ASUS laptops. - It may also support some MEDION, JVC or VICTOR laptops (such as MEDION 9675 or - VICTOR XP7210 for example). It makes all the extra buttons generate input - events (like keyboards). - On some models adds support for changing the display brightness and output, - switching the LCD backlight on and off, and most importantly, allows you to - blink those fancy LEDs intended for reporting mail and wireless status. - -This driver supercedes the old asus_acpi driver. - -Requirements ------------- - - Kernel 2.6.X sources, configured for your computer, with ACPI support. - You also need CONFIG_INPUT and CONFIG_ACPI. - -Status ------- - - The features currently supported are the following (see below for - detailed description): - - - Fn key combinations - - Bluetooth enable and disable - - Wlan enable and disable - - GPS enable and disable - - Video output switching - - Ambient Light Sensor on and off - - LED control - - LED Display control - - LCD brightness control - - LCD on and off - - A compatibility table by model and feature is maintained on the web - site, http://acpi4asus.sf.net/. - -Usage ------ - - Try "modprobe asus-laptop". Check your dmesg (simply type dmesg). You should - see some lines like this : - - Asus Laptop Extras version 0.42 - L2D model detected. - - If it is not the output you have on your laptop, send it (and the laptop's - DSDT) to me. - - That's all, now, all the events generated by the hotkeys of your laptop - should be reported via netlink events. You can check with - "acpi_genl monitor" (part of the acpica project). - - Hotkeys are also reported as input keys (like keyboards) you can check - which key are supported using "xev" under X11. - - You can get information on the version of your DSDT table by reading the - /sys/devices/platform/asus-laptop/infos entry. If you have a question or a - bug report to do, please include the output of this entry. - -LEDs ----- - - You can modify LEDs be echoing values to /sys/class/leds/asus::*/brightness : - echo 1 > /sys/class/leds/asus::mail/brightness - will switch the mail LED on. - You can also know if they are on/off by reading their content and use - kernel triggers like disk-activity or heartbeat. - -Backlight ---------- - - You can control lcd backlight power and brightness with - /sys/class/backlight/asus-laptop/. Brightness Values are between 0 and 15. - -Wireless devices ---------------- - - You can turn the internal Bluetooth adapter on/off with the bluetooth entry - (only on models with Bluetooth). This usually controls the associated LED. - Same for Wlan adapter. - -Display switching ------------------ - - Note: the display switching code is currently considered EXPERIMENTAL. - - Switching works for the following models: - L3800C - A2500H - L5800C - M5200N - W1000N (albeit with some glitches) - M6700R - A6JC - F3J - - Switching doesn't work for the following: - M3700N - L2X00D (locks the laptop under certain conditions) - - To switch the displays, echo values from 0 to 15 to - /sys/devices/platform/asus-laptop/display. The significance of those values - is as follows: - - +-------+-----+-----+-----+-----+-----+ - | Bin | Val | DVI | TV | CRT | LCD | - +-------+-----+-----+-----+-----+-----+ - + 0000 + 0 + + + + + - +-------+-----+-----+-----+-----+-----+ - + 0001 + 1 + + + + X + - +-------+-----+-----+-----+-----+-----+ - + 0010 + 2 + + + X + + - +-------+-----+-----+-----+-----+-----+ - + 0011 + 3 + + + X + X + - +-------+-----+-----+-----+-----+-----+ - + 0100 + 4 + + X + + + - +-------+-----+-----+-----+-----+-----+ - + 0101 + 5 + + X + + X + - +-------+-----+-----+-----+-----+-----+ - + 0110 + 6 + + X + X + + - +-------+-----+-----+-----+-----+-----+ - + 0111 + 7 + + X + X + X + - +-------+-----+-----+-----+-----+-----+ - + 1000 + 8 + X + + + + - +-------+-----+-----+-----+-----+-----+ - + 1001 + 9 + X + + + X + - +-------+-----+-----+-----+-----+-----+ - + 1010 + 10 + X + + X + + - +-------+-----+-----+-----+-----+-----+ - + 1011 + 11 + X + + X + X + - +-------+-----+-----+-----+-----+-----+ - + 1100 + 12 + X + X + + + - +-------+-----+-----+-----+-----+-----+ - + 1101 + 13 + X + X + + X + - +-------+-----+-----+-----+-----+-----+ - + 1110 + 14 + X + X + X + + - +-------+-----+-----+-----+-----+-----+ - + 1111 + 15 + X + X + X + X + - +-------+-----+-----+-----+-----+-----+ - - In most cases, the appropriate displays must be plugged in for the above - combinations to work. TV-Out may need to be initialized at boot time. - - Debugging: - 1) Check whether the Fn+F8 key: - a) does not lock the laptop (try a boot with noapic / nolapic if it does) - b) generates events (0x6n, where n is the value corresponding to the - configuration above) - c) actually works - Record the disp value at every configuration. - 2) Echo values from 0 to 15 to /sys/devices/platform/asus-laptop/display. - Record its value, note any change. If nothing changes, try a broader range, - up to 65535. - 3) Send ANY output (both positive and negative reports are needed, unless your - machine is already listed above) to the acpi4asus-user mailing list. - - Note: on some machines (e.g. L3C), after the module has been loaded, only 0x6n - events are generated and no actual switching occurs. In such a case, a line - like: - - echo $((10#$arg-60)) > /sys/devices/platform/asus-laptop/display - - will usually do the trick ($arg is the 0000006n-like event passed to acpid). - - Note: there is currently no reliable way to read display status on xxN - (Centrino) models. - -LED display ------------ - - Some models like the W1N have a LED display that can be used to display - several items of information. - - LED display works for the following models: - W1000N - W1J - - To control the LED display, use the following : - - echo 0x0T000DDD > /sys/devices/platform/asus-laptop/ - - where T control the 3 letters display, and DDD the 3 digits display, - according to the tables below. - - DDD (digits) - 000 to 999 = display digits - AAA = --- - BBB to FFF = turn-off - - T (type) - 0 = off - 1 = dvd - 2 = vcd - 3 = mp3 - 4 = cd - 5 = tv - 6 = cpu - 7 = vol - - For example "echo 0x01000001 >/sys/devices/platform/asus-laptop/ledd" - would display "DVD001". - -Driver options: ---------------- - - Options can be passed to the asus-laptop driver using the standard - module argument syntax (= when passing the option to the - module or asus-laptop.= on the kernel boot line when - asus-laptop is statically linked into the kernel). - - wapf: WAPF defines the behavior of the Fn+Fx wlan key - The significance of values is yet to be found, but - most of the time: - - 0x0 should do nothing - - 0x1 should allow to control the device with Fn+Fx key. - - 0x4 should send an ACPI event (0x88) while pressing the Fn+Fx key - - 0x5 like 0x1 or 0x4 - - The default value is 0x1. - -Unsupported models ------------------- - - These models will never be supported by this module, as they use a completely - different mechanism to handle LEDs and extra stuff (meaning we have no clue - how it works): - - - ASUS A1300 (A1B), A1370D - - ASUS L7300G - - ASUS L8400 - -Patches, Errors, Questions: --------------------------- - - I appreciate any success or failure - reports, especially if they add to or correct the compatibility table. - Please include the following information in your report: - - - Asus model name - - a copy of your ACPI tables, using the "acpidump" utility - - a copy of /sys/devices/platform/asus-laptop/infos - - which driver features work and which don't - - the observed behavior of non-working features - - Any other comments or patches are also more than welcome. - - acpi4asus-user@lists.sourceforge.net - http://sourceforge.net/projects/acpi4asus - diff --git a/Documentation/laptops/disk-shock-protection.rst b/Documentation/laptops/disk-shock-protection.rst new file mode 100644 index 000000000000..e97c5f78d8c3 --- /dev/null +++ b/Documentation/laptops/disk-shock-protection.rst @@ -0,0 +1,151 @@ +========================== +Hard disk shock protection +========================== + +Author: Elias Oltmanns + +Last modified: 2008-10-03 + + +.. 0. Contents + + 1. Intro + 2. The interface + 3. References + 4. CREDITS + + +1. Intro +-------- + +ATA/ATAPI-7 specifies the IDLE IMMEDIATE command with unload feature. +Issuing this command should cause the drive to switch to idle mode and +unload disk heads. This feature is being used in modern laptops in +conjunction with accelerometers and appropriate software to implement +a shock protection facility. The idea is to stop all I/O operations on +the internal hard drive and park its heads on the ramp when critical +situations are anticipated. The desire to have such a feature +available on GNU/Linux systems has been the original motivation to +implement a generic disk head parking interface in the Linux kernel. +Please note, however, that other components have to be set up on your +system in order to get disk shock protection working (see +section 3. References below for pointers to more information about +that). + + +2. The interface +---------------- + +For each ATA device, the kernel exports the file +`block/*/device/unload_heads` in sysfs (here assumed to be mounted under +/sys). Access to `/sys/block/*/device/unload_heads` is denied with +-EOPNOTSUPP if the device does not support the unload feature. +Otherwise, writing an integer value to this file will take the heads +of the respective drive off the platter and block all I/O operations +for the specified number of milliseconds. When the timeout expires and +no further disk head park request has been issued in the meantime, +normal operation will be resumed. The maximal value accepted for a +timeout is 30000 milliseconds. Exceeding this limit will return +-EOVERFLOW, but heads will be parked anyway and the timeout will be +set to 30 seconds. However, you can always change a timeout to any +value between 0 and 30000 by issuing a subsequent head park request +before the timeout of the previous one has expired. In particular, the +total timeout can exceed 30 seconds and, more importantly, you can +cancel a previously set timeout and resume normal operation +immediately by specifying a timeout of 0. Values below -2 are rejected +with -EINVAL (see below for the special meaning of -1 and -2). If the +timeout specified for a recent head park request has not yet expired, +reading from `/sys/block/*/device/unload_heads` will report the number +of milliseconds remaining until normal operation will be resumed; +otherwise, reading the unload_heads attribute will return 0. + +For example, do the following in order to park the heads of drive +/dev/sda and stop all I/O operations for five seconds:: + + # echo 5000 > /sys/block/sda/device/unload_heads + +A simple:: + + # cat /sys/block/sda/device/unload_heads + +will show you how many milliseconds are left before normal operation +will be resumed. + +A word of caution: The fact that the interface operates on a basis of +milliseconds may raise expectations that cannot be satisfied in +reality. In fact, the ATA specs clearly state that the time for an +unload operation to complete is vendor specific. The hint in ATA-7 +that this will typically be within 500 milliseconds apparently has +been dropped in ATA-8. + +There is a technical detail of this implementation that may cause some +confusion and should be discussed here. When a head park request has +been issued to a device successfully, all I/O operations on the +controller port this device is attached to will be deferred. That is +to say, any other device that may be connected to the same port will +be affected too. The only exception is that a subsequent head unload +request to that other device will be executed immediately. Further +operations on that port will be deferred until the timeout specified +for either device on the port has expired. As far as PATA (old style +IDE) configurations are concerned, there can only be two devices +attached to any single port. In SATA world we have port multipliers +which means that a user-issued head parking request to one device may +actually result in stopping I/O to a whole bunch of devices. However, +since this feature is supposed to be used on laptops and does not seem +to be very useful in any other environment, there will be mostly one +device per port. Even if the CD/DVD writer happens to be connected to +the same port as the hard drive, it generally *should* recover just +fine from the occasional buffer under-run incurred by a head park +request to the HD. Actually, when you are using an ide driver rather +than its libata counterpart (i.e. your disk is called /dev/hda +instead of /dev/sda), then parking the heads of one drive (drive X) +will generally not affect the mode of operation of another drive +(drive Y) on the same port as described above. It is only when a port +reset is required to recover from an exception on drive Y that further +I/O operations on that drive (and the reset itself) will be delayed +until drive X is no longer in the parked state. + +Finally, there are some hard drives that only comply with an earlier +version of the ATA standard than ATA-7, but do support the unload +feature nonetheless. Unfortunately, there is no safe way Linux can +detect these devices, so you won't be able to write to the +unload_heads attribute. If you know that your device really does +support the unload feature (for instance, because the vendor of your +laptop or the hard drive itself told you so), then you can tell the +kernel to enable the usage of this feature for that drive by writing +the special value -1 to the unload_heads attribute:: + + # echo -1 > /sys/block/sda/device/unload_heads + +will enable the feature for /dev/sda, and giving -2 instead of -1 will +disable it again. + + +3. References +------------- + +There are several laptops from different vendors featuring shock +protection capabilities. As manufacturers have refused to support open +source development of the required software components so far, Linux +support for shock protection varies considerably between different +hardware implementations. Ideally, this section should contain a list +of pointers at different projects aiming at an implementation of shock +protection on different systems. Unfortunately, I only know of a +single project which, although still considered experimental, is fit +for use. Please feel free to add projects that have been the victims +of my ignorance. + +- http://www.thinkwiki.org/wiki/HDAPS + + See this page for information about Linux support of the hard disk + active protection system as implemented in IBM/Lenovo Thinkpads. + + +4. CREDITS +---------- + +This implementation of disk head parking has been inspired by a patch +originally published by Jon Escombe . My efforts +to develop an implementation of this feature that is fit to be merged +into mainline have been aided by various kernel developers, in +particular by Tejun Heo and Bartlomiej Zolnierkiewicz. diff --git a/Documentation/laptops/disk-shock-protection.txt b/Documentation/laptops/disk-shock-protection.txt deleted file mode 100644 index 0e6ba2663834..000000000000 --- a/Documentation/laptops/disk-shock-protection.txt +++ /dev/null @@ -1,149 +0,0 @@ -Hard disk shock protection -========================== - -Author: Elias Oltmanns -Last modified: 2008-10-03 - - -0. Contents ------------ - -1. Intro -2. The interface -3. References -4. CREDITS - - -1. Intro --------- - -ATA/ATAPI-7 specifies the IDLE IMMEDIATE command with unload feature. -Issuing this command should cause the drive to switch to idle mode and -unload disk heads. This feature is being used in modern laptops in -conjunction with accelerometers and appropriate software to implement -a shock protection facility. The idea is to stop all I/O operations on -the internal hard drive and park its heads on the ramp when critical -situations are anticipated. The desire to have such a feature -available on GNU/Linux systems has been the original motivation to -implement a generic disk head parking interface in the Linux kernel. -Please note, however, that other components have to be set up on your -system in order to get disk shock protection working (see -section 3. References below for pointers to more information about -that). - - -2. The interface ----------------- - -For each ATA device, the kernel exports the file -block/*/device/unload_heads in sysfs (here assumed to be mounted under -/sys). Access to /sys/block/*/device/unload_heads is denied with --EOPNOTSUPP if the device does not support the unload feature. -Otherwise, writing an integer value to this file will take the heads -of the respective drive off the platter and block all I/O operations -for the specified number of milliseconds. When the timeout expires and -no further disk head park request has been issued in the meantime, -normal operation will be resumed. The maximal value accepted for a -timeout is 30000 milliseconds. Exceeding this limit will return --EOVERFLOW, but heads will be parked anyway and the timeout will be -set to 30 seconds. However, you can always change a timeout to any -value between 0 and 30000 by issuing a subsequent head park request -before the timeout of the previous one has expired. In particular, the -total timeout can exceed 30 seconds and, more importantly, you can -cancel a previously set timeout and resume normal operation -immediately by specifying a timeout of 0. Values below -2 are rejected -with -EINVAL (see below for the special meaning of -1 and -2). If the -timeout specified for a recent head park request has not yet expired, -reading from /sys/block/*/device/unload_heads will report the number -of milliseconds remaining until normal operation will be resumed; -otherwise, reading the unload_heads attribute will return 0. - -For example, do the following in order to park the heads of drive -/dev/sda and stop all I/O operations for five seconds: - -# echo 5000 > /sys/block/sda/device/unload_heads - -A simple - -# cat /sys/block/sda/device/unload_heads - -will show you how many milliseconds are left before normal operation -will be resumed. - -A word of caution: The fact that the interface operates on a basis of -milliseconds may raise expectations that cannot be satisfied in -reality. In fact, the ATA specs clearly state that the time for an -unload operation to complete is vendor specific. The hint in ATA-7 -that this will typically be within 500 milliseconds apparently has -been dropped in ATA-8. - -There is a technical detail of this implementation that may cause some -confusion and should be discussed here. When a head park request has -been issued to a device successfully, all I/O operations on the -controller port this device is attached to will be deferred. That is -to say, any other device that may be connected to the same port will -be affected too. The only exception is that a subsequent head unload -request to that other device will be executed immediately. Further -operations on that port will be deferred until the timeout specified -for either device on the port has expired. As far as PATA (old style -IDE) configurations are concerned, there can only be two devices -attached to any single port. In SATA world we have port multipliers -which means that a user-issued head parking request to one device may -actually result in stopping I/O to a whole bunch of devices. However, -since this feature is supposed to be used on laptops and does not seem -to be very useful in any other environment, there will be mostly one -device per port. Even if the CD/DVD writer happens to be connected to -the same port as the hard drive, it generally *should* recover just -fine from the occasional buffer under-run incurred by a head park -request to the HD. Actually, when you are using an ide driver rather -than its libata counterpart (i.e. your disk is called /dev/hda -instead of /dev/sda), then parking the heads of one drive (drive X) -will generally not affect the mode of operation of another drive -(drive Y) on the same port as described above. It is only when a port -reset is required to recover from an exception on drive Y that further -I/O operations on that drive (and the reset itself) will be delayed -until drive X is no longer in the parked state. - -Finally, there are some hard drives that only comply with an earlier -version of the ATA standard than ATA-7, but do support the unload -feature nonetheless. Unfortunately, there is no safe way Linux can -detect these devices, so you won't be able to write to the -unload_heads attribute. If you know that your device really does -support the unload feature (for instance, because the vendor of your -laptop or the hard drive itself told you so), then you can tell the -kernel to enable the usage of this feature for that drive by writing -the special value -1 to the unload_heads attribute: - -# echo -1 > /sys/block/sda/device/unload_heads - -will enable the feature for /dev/sda, and giving -2 instead of -1 will -disable it again. - - -3. References -------------- - -There are several laptops from different vendors featuring shock -protection capabilities. As manufacturers have refused to support open -source development of the required software components so far, Linux -support for shock protection varies considerably between different -hardware implementations. Ideally, this section should contain a list -of pointers at different projects aiming at an implementation of shock -protection on different systems. Unfortunately, I only know of a -single project which, although still considered experimental, is fit -for use. Please feel free to add projects that have been the victims -of my ignorance. - -- http://www.thinkwiki.org/wiki/HDAPS - See this page for information about Linux support of the hard disk - active protection system as implemented in IBM/Lenovo Thinkpads. - - -4. CREDITS ----------- - -This implementation of disk head parking has been inspired by a patch -originally published by Jon Escombe . My efforts -to develop an implementation of this feature that is fit to be merged -into mainline have been aided by various kernel developers, in -particular by Tejun Heo and Bartlomiej Zolnierkiewicz. diff --git a/Documentation/laptops/index.rst b/Documentation/laptops/index.rst new file mode 100644 index 000000000000..001a30910d09 --- /dev/null +++ b/Documentation/laptops/index.rst @@ -0,0 +1,17 @@ +:orphan: + +============== +Laptop Drivers +============== + +.. toctree:: + :maxdepth: 1 + + asus-laptop + disk-shock-protection + laptop-mode + lg-laptop + sony-laptop + sonypi + thinkpad-acpi + toshiba_haps diff --git a/Documentation/laptops/laptop-mode.rst b/Documentation/laptops/laptop-mode.rst new file mode 100644 index 000000000000..c984c4262f2e --- /dev/null +++ b/Documentation/laptops/laptop-mode.rst @@ -0,0 +1,781 @@ +=============================================== +How to conserve battery power using laptop-mode +=============================================== + +Document Author: Bart Samwel (bart@samwel.tk) + +Date created: January 2, 2004 + +Last modified: December 06, 2004 + +Introduction +------------ + +Laptop mode is used to minimize the time that the hard disk needs to be spun up, +to conserve battery power on laptops. It has been reported to cause significant +power savings. + +.. Contents + + * Introduction + * Installation + * Caveats + * The Details + * Tips & Tricks + * Control script + * ACPI integration + * Monitoring tool + + +Installation +------------ + +To use laptop mode, you don't need to set any kernel configuration options +or anything. Simply install all the files included in this document, and +laptop mode will automatically be started when you're on battery. For +your convenience, a tarball containing an installer can be downloaded at: + + http://www.samwel.tk/laptop_mode/laptop_mode/ + +To configure laptop mode, you need to edit the configuration file, which is +located in /etc/default/laptop-mode on Debian-based systems, or in +/etc/sysconfig/laptop-mode on other systems. + +Unfortunately, automatic enabling of laptop mode does not work for +laptops that don't have ACPI. On those laptops, you need to start laptop +mode manually. To start laptop mode, run "laptop_mode start", and to +stop it, run "laptop_mode stop". (Note: The laptop mode tools package now +has experimental support for APM, you might want to try that first.) + + +Caveats +------- + +* The downside of laptop mode is that you have a chance of losing up to 10 + minutes of work. If you cannot afford this, don't use it! The supplied ACPI + scripts automatically turn off laptop mode when the battery almost runs out, + so that you won't lose any data at the end of your battery life. + +* Most desktop hard drives have a very limited lifetime measured in spindown + cycles, typically about 50.000 times (it's usually listed on the spec sheet). + Check your drive's rating, and don't wear down your drive's lifetime if you + don't need to. + +* If you mount some of your ext3/reiserfs filesystems with the -n option, then + the control script will not be able to remount them correctly. You must set + DO_REMOUNTS=0 in the control script, otherwise it will remount them with the + wrong options -- or it will fail because it cannot write to /etc/mtab. + +* If you have your filesystems listed as type "auto" in fstab, like I did, then + the control script will not recognize them as filesystems that need remounting. + You must list the filesystems with their true type instead. + +* It has been reported that some versions of the mutt mail client use file access + times to determine whether a folder contains new mail. If you use mutt and + experience this, you must disable the noatime remounting by setting the option + DO_REMOUNT_NOATIME to 0 in the configuration file. + + +The Details +----------- + +Laptop mode is controlled by the knob /proc/sys/vm/laptop_mode. This knob is +present for all kernels that have the laptop mode patch, regardless of any +configuration options. When the knob is set, any physical disk I/O (that might +have caused the hard disk to spin up) causes Linux to flush all dirty blocks. The +result of this is that after a disk has spun down, it will not be spun up +anymore to write dirty blocks, because those blocks had already been written +immediately after the most recent read operation. The value of the laptop_mode +knob determines the time between the occurrence of disk I/O and when the flush +is triggered. A sensible value for the knob is 5 seconds. Setting the knob to +0 disables laptop mode. + +To increase the effectiveness of the laptop_mode strategy, the laptop_mode +control script increases dirty_expire_centisecs and dirty_writeback_centisecs in +/proc/sys/vm to about 10 minutes (by default), which means that pages that are +dirtied are not forced to be written to disk as often. The control script also +changes the dirty background ratio, so that background writeback of dirty pages +is not done anymore. Combined with a higher commit value (also 10 minutes) for +ext3 or ReiserFS filesystems (also done automatically by the control script), +this results in concentration of disk activity in a small time interval which +occurs only once every 10 minutes, or whenever the disk is forced to spin up by +a cache miss. The disk can then be spun down in the periods of inactivity. + +If you want to find out which process caused the disk to spin up, you can +gather information by setting the flag /proc/sys/vm/block_dump. When this flag +is set, Linux reports all disk read and write operations that take place, and +all block dirtyings done to files. This makes it possible to debug why a disk +needs to spin up, and to increase battery life even more. The output of +block_dump is written to the kernel output, and it can be retrieved using +"dmesg". When you use block_dump and your kernel logging level also includes +kernel debugging messages, you probably want to turn off klogd, otherwise +the output of block_dump will be logged, causing disk activity that is not +normally there. + + +Configuration +------------- + +The laptop mode configuration file is located in /etc/default/laptop-mode on +Debian-based systems, or in /etc/sysconfig/laptop-mode on other systems. It +contains the following options: + +MAX_AGE: + +Maximum time, in seconds, of hard drive spindown time that you are +comfortable with. Worst case, it's possible that you could lose this +amount of work if your battery fails while you're in laptop mode. + +MINIMUM_BATTERY_MINUTES: + +Automatically disable laptop mode if the remaining number of minutes of +battery power is less than this value. Default is 10 minutes. + +AC_HD/BATT_HD: + +The idle timeout that should be set on your hard drive when laptop mode +is active (BATT_HD) and when it is not active (AC_HD). The defaults are +20 seconds (value 4) for BATT_HD and 2 hours (value 244) for AC_HD. The +possible values are those listed in the manual page for "hdparm" for the +"-S" option. + +HD: + +The devices for which the spindown timeout should be adjusted by laptop mode. +Default is /dev/hda. If you specify multiple devices, separate them by a space. + +READAHEAD: + +Disk readahead, in 512-byte sectors, while laptop mode is active. A large +readahead can prevent disk accesses for things like executable pages (which are +loaded on demand while the application executes) and sequentially accessed data +(MP3s). + +DO_REMOUNTS: + +The control script automatically remounts any mounted journaled filesystems +with appropriate commit interval options. When this option is set to 0, this +feature is disabled. + +DO_REMOUNT_NOATIME: + +When remounting, should the filesystems be remounted with the noatime option? +Normally, this is set to "1" (enabled), but there may be programs that require +access time recording. + +DIRTY_RATIO: + +The percentage of memory that is allowed to contain "dirty" or unsaved data +before a writeback is forced, while laptop mode is active. Corresponds to +the /proc/sys/vm/dirty_ratio sysctl. + +DIRTY_BACKGROUND_RATIO: + +The percentage of memory that is allowed to contain "dirty" or unsaved data +after a forced writeback is done due to an exceeding of DIRTY_RATIO. Set +this nice and low. This corresponds to the /proc/sys/vm/dirty_background_ratio +sysctl. + +Note that the behaviour of dirty_background_ratio is quite different +when laptop mode is active and when it isn't. When laptop mode is inactive, +dirty_background_ratio is the threshold percentage at which background writeouts +start taking place. When laptop mode is active, however, background writeouts +are disabled, and the dirty_background_ratio only determines how much writeback +is done when dirty_ratio is reached. + +DO_CPU: + +Enable CPU frequency scaling when in laptop mode. (Requires CPUFreq to be setup. +See Documentation/admin-guide/pm/cpufreq.rst for more info. Disabled by default.) + +CPU_MAXFREQ: + +When on battery, what is the maximum CPU speed that the system should use? Legal +values are "slowest" for the slowest speed that your CPU is able to operate at, +or a value listed in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies. + + +Tips & Tricks +------------- + +* Bartek Kania reports getting up to 50 minutes of extra battery life (on top + of his regular 3 to 3.5 hours) using a spindown time of 5 seconds (BATT_HD=1). + +* You can spin down the disk while playing MP3, by setting disk readahead + to 8MB (READAHEAD=16384). Effectively, the disk will read a complete MP3 at + once, and will then spin down while the MP3 is playing. (Thanks to Bartek + Kania.) + +* Drew Scott Daniels observed: "I don't know why, but when I decrease the number + of colours that my display uses it consumes less battery power. I've seen + this on powerbooks too. I hope that this is a piece of information that + might be useful to the Laptop Mode patch or its users." + +* In syslog.conf, you can prefix entries with a dash `-` to omit syncing the + file after every logging. When you're using laptop-mode and your disk doesn't + spin down, this is a likely culprit. + +* Richard Atterer observed that laptop mode does not work well with noflushd + (http://noflushd.sourceforge.net/), it seems that noflushd prevents laptop-mode + from doing its thing. + +* If you're worried about your data, you might want to consider using a USB + memory stick or something like that as a "working area". (Be aware though + that flash memory can only handle a limited number of writes, and overuse + may wear out your memory stick pretty quickly. Do _not_ use journalling + filesystems on flash memory sticks.) + + +Configuration file for control and ACPI battery scripts +------------------------------------------------------- + +This allows the tunables to be changed for the scripts via an external +configuration file + +It should be installed as /etc/default/laptop-mode on Debian, and as +/etc/sysconfig/laptop-mode on Red Hat, SUSE, Mandrake, and other work-alikes. + +Config file:: + + # Maximum time, in seconds, of hard drive spindown time that you are + # comfortable with. Worst case, it's possible that you could lose this + # amount of work if your battery fails you while in laptop mode. + #MAX_AGE=600 + + # Automatically disable laptop mode when the number of minutes of battery + # that you have left goes below this threshold. + MINIMUM_BATTERY_MINUTES=10 + + # Read-ahead, in 512-byte sectors. You can spin down the disk while playing MP3/OGG + # by setting the disk readahead to 8MB (READAHEAD=16384). Effectively, the disk + # will read a complete MP3 at once, and will then spin down while the MP3/OGG is + # playing. + #READAHEAD=4096 + + # Shall we remount journaled fs. with appropriate commit interval? (1=yes) + #DO_REMOUNTS=1 + + # And shall we add the "noatime" option to that as well? (1=yes) + #DO_REMOUNT_NOATIME=1 + + # Dirty synchronous ratio. At this percentage of dirty pages the process + # which + # calls write() does its own writeback + #DIRTY_RATIO=40 + + # + # Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been + # exceeded, the kernel will wake flusher threads which will then reduce the + # amount of dirty memory to dirty_background_ratio. Set this nice and low, + # so once some writeout has commenced, we do a lot of it. + # + #DIRTY_BACKGROUND_RATIO=5 + + # kernel default dirty buffer age + #DEF_AGE=30 + #DEF_UPDATE=5 + #DEF_DIRTY_BACKGROUND_RATIO=10 + #DEF_DIRTY_RATIO=40 + #DEF_XFS_AGE_BUFFER=15 + #DEF_XFS_SYNC_INTERVAL=30 + #DEF_XFS_BUFD_INTERVAL=1 + + # This must be adjusted manually to the value of HZ in the running kernel + # on 2.4, until the XFS people change their 2.4 external interfaces to work in + # centisecs. This can be automated, but it's a work in progress that still + # needs# some fixes. On 2.6 kernels, XFS uses USER_HZ instead of HZ for + # external interfaces, and that is currently always set to 100. So you don't + # need to change this on 2.6. + #XFS_HZ=100 + + # Should the maximum CPU frequency be adjusted down while on battery? + # Requires CPUFreq to be setup. + # See Documentation/admin-guide/pm/cpufreq.rst for more info + #DO_CPU=0 + + # When on battery what is the maximum CPU speed that the system should + # use? Legal values are "slowest" for the slowest speed that your + # CPU is able to operate at, or a value listed in: + # /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies + # Only applicable if DO_CPU=1. + #CPU_MAXFREQ=slowest + + # Idle timeout for your hard drive (man hdparm for valid values, -S option) + # Default is 2 hours on AC (AC_HD=244) and 20 seconds for battery (BATT_HD=4). + #AC_HD=244 + #BATT_HD=4 + + # The drives for which to adjust the idle timeout. Separate them by a space, + # e.g. HD="/dev/hda /dev/hdb". + #HD="/dev/hda" + + # Set the spindown timeout on a hard drive? + #DO_HD=1 + + +Control script +-------------- + +Please note that this control script works for the Linux 2.4 and 2.6 series (thanks +to Kiko Piris). + +Control script:: + + #!/bin/bash + + # start or stop laptop_mode, best run by a power management daemon when + # ac gets connected/disconnected from a laptop + # + # install as /sbin/laptop_mode + # + # Contributors to this script: Kiko Piris + # Bart Samwel + # Micha Feigin + # Andrew Morton + # Herve Eychenne + # Dax Kelson + # + # Original Linux 2.4 version by: Jens Axboe + + ############################################################################# + + # Source config + if [ -f /etc/default/laptop-mode ] ; then + # Debian + . /etc/default/laptop-mode + elif [ -f /etc/sysconfig/laptop-mode ] ; then + # Others + . /etc/sysconfig/laptop-mode + fi + + # Don't raise an error if the config file is incomplete + # set defaults instead: + + # Maximum time, in seconds, of hard drive spindown time that you are + # comfortable with. Worst case, it's possible that you could lose this + # amount of work if your battery fails you while in laptop mode. + MAX_AGE=${MAX_AGE:-'600'} + + # Read-ahead, in kilobytes + READAHEAD=${READAHEAD:-'4096'} + + # Shall we remount journaled fs. with appropriate commit interval? (1=yes) + DO_REMOUNTS=${DO_REMOUNTS:-'1'} + + # And shall we add the "noatime" option to that as well? (1=yes) + DO_REMOUNT_NOATIME=${DO_REMOUNT_NOATIME:-'1'} + + # Shall we adjust the idle timeout on a hard drive? + DO_HD=${DO_HD:-'1'} + + # Adjust idle timeout on which hard drive? + HD="${HD:-'/dev/hda'}" + + # spindown time for HD (hdparm -S values) + AC_HD=${AC_HD:-'244'} + BATT_HD=${BATT_HD:-'4'} + + # Dirty synchronous ratio. At this percentage of dirty pages the process which + # calls write() does its own writeback + DIRTY_RATIO=${DIRTY_RATIO:-'40'} + + # cpu frequency scaling + # See Documentation/admin-guide/pm/cpufreq.rst for more info + DO_CPU=${CPU_MANAGE:-'0'} + CPU_MAXFREQ=${CPU_MAXFREQ:-'slowest'} + + # + # Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been + # exceeded, the kernel will wake flusher threads which will then reduce the + # amount of dirty memory to dirty_background_ratio. Set this nice and low, + # so once some writeout has commenced, we do a lot of it. + # + DIRTY_BACKGROUND_RATIO=${DIRTY_BACKGROUND_RATIO:-'5'} + + # kernel default dirty buffer age + DEF_AGE=${DEF_AGE:-'30'} + DEF_UPDATE=${DEF_UPDATE:-'5'} + DEF_DIRTY_BACKGROUND_RATIO=${DEF_DIRTY_BACKGROUND_RATIO:-'10'} + DEF_DIRTY_RATIO=${DEF_DIRTY_RATIO:-'40'} + DEF_XFS_AGE_BUFFER=${DEF_XFS_AGE_BUFFER:-'15'} + DEF_XFS_SYNC_INTERVAL=${DEF_XFS_SYNC_INTERVAL:-'30'} + DEF_XFS_BUFD_INTERVAL=${DEF_XFS_BUFD_INTERVAL:-'1'} + + # This must be adjusted manually to the value of HZ in the running kernel + # on 2.4, until the XFS people change their 2.4 external interfaces to work in + # centisecs. This can be automated, but it's a work in progress that still needs + # some fixes. On 2.6 kernels, XFS uses USER_HZ instead of HZ for external + # interfaces, and that is currently always set to 100. So you don't need to + # change this on 2.6. + XFS_HZ=${XFS_HZ:-'100'} + + ############################################################################# + + KLEVEL="$(uname -r | + { + IFS='.' read a b c + echo $a.$b + } + )" + case "$KLEVEL" in + "2.4"|"2.6") + ;; + *) + echo "Unhandled kernel version: $KLEVEL ('uname -r' = '$(uname -r)')" >&2 + exit 1 + ;; + esac + + if [ ! -e /proc/sys/vm/laptop_mode ] ; then + echo "Kernel is not patched with laptop_mode patch." >&2 + exit 1 + fi + + if [ ! -w /proc/sys/vm/laptop_mode ] ; then + echo "You do not have enough privileges to enable laptop_mode." >&2 + exit 1 + fi + + # Remove an option (the first parameter) of the form option= from + # a mount options string (the rest of the parameters). + parse_mount_opts () { + OPT="$1" + shift + echo ",$*," | sed \ + -e 's/,'"$OPT"'=[0-9]*,/,/g' \ + -e 's/,,*/,/g' \ + -e 's/^,//' \ + -e 's/,$//' + } + + # Remove an option (the first parameter) without any arguments from + # a mount option string (the rest of the parameters). + parse_nonumber_mount_opts () { + OPT="$1" + shift + echo ",$*," | sed \ + -e 's/,'"$OPT"',/,/g' \ + -e 's/,,*/,/g' \ + -e 's/^,//' \ + -e 's/,$//' + } + + # Find out the state of a yes/no option (e.g. "atime"/"noatime") in + # fstab for a given filesystem, and use this state to replace the + # value of the option in another mount options string. The device + # is the first argument, the option name the second, and the default + # value the third. The remainder is the mount options string. + # + # Example: + # parse_yesno_opts_wfstab /dev/hda1 atime atime defaults,noatime + # + # If fstab contains, say, "rw" for this filesystem, then the result + # will be "defaults,atime". + parse_yesno_opts_wfstab () { + L_DEV="$1" + OPT="$2" + DEF_OPT="$3" + shift 3 + L_OPTS="$*" + PARSEDOPTS1="$(parse_nonumber_mount_opts $OPT $L_OPTS)" + PARSEDOPTS1="$(parse_nonumber_mount_opts no$OPT $PARSEDOPTS1)" + # Watch for a default atime in fstab + FSTAB_OPTS="$(awk '$1 == "'$L_DEV'" { print $4 }' /etc/fstab)" + if echo "$FSTAB_OPTS" | grep "$OPT" > /dev/null ; then + # option specified in fstab: extract the value and use it + if echo "$FSTAB_OPTS" | grep "no$OPT" > /dev/null ; then + echo "$PARSEDOPTS1,no$OPT" + else + # no$OPT not found -- so we must have $OPT. + echo "$PARSEDOPTS1,$OPT" + fi + else + # option not specified in fstab -- choose the default. + echo "$PARSEDOPTS1,$DEF_OPT" + fi + } + + # Find out the state of a numbered option (e.g. "commit=NNN") in + # fstab for a given filesystem, and use this state to replace the + # value of the option in another mount options string. The device + # is the first argument, and the option name the second. The + # remainder is the mount options string in which the replacement + # must be done. + # + # Example: + # parse_mount_opts_wfstab /dev/hda1 commit defaults,commit=7 + # + # If fstab contains, say, "commit=3,rw" for this filesystem, then the + # result will be "rw,commit=3". + parse_mount_opts_wfstab () { + L_DEV="$1" + OPT="$2" + shift 2 + L_OPTS="$*" + PARSEDOPTS1="$(parse_mount_opts $OPT $L_OPTS)" + # Watch for a default commit in fstab + FSTAB_OPTS="$(awk '$1 == "'$L_DEV'" { print $4 }' /etc/fstab)" + if echo "$FSTAB_OPTS" | grep "$OPT=" > /dev/null ; then + # option specified in fstab: extract the value, and use it + echo -n "$PARSEDOPTS1,$OPT=" + echo ",$FSTAB_OPTS," | sed \ + -e 's/.*,'"$OPT"'=//' \ + -e 's/,.*//' + else + # option not specified in fstab: set it to 0 + echo "$PARSEDOPTS1,$OPT=0" + fi + } + + deduce_fstype () { + MP="$1" + # My root filesystem unfortunately has + # type "unknown" in /etc/mtab. If we encounter + # "unknown", we try to get the type from fstab. + cat /etc/fstab | + grep -v '^#' | + while read FSTAB_DEV FSTAB_MP FSTAB_FST FSTAB_OPTS FSTAB_DUMP FSTAB_DUMP ; do + if [ "$FSTAB_MP" = "$MP" ]; then + echo $FSTAB_FST + exit 0 + fi + done + } + + if [ $DO_REMOUNT_NOATIME -eq 1 ] ; then + NOATIME_OPT=",noatime" + fi + + case "$1" in + start) + AGE=$((100*$MAX_AGE)) + XFS_AGE=$(($XFS_HZ*$MAX_AGE)) + echo -n "Starting laptop_mode" + + if [ -d /proc/sys/vm/pagebuf ] ; then + # (For 2.4 and early 2.6.) + # This only needs to be set, not reset -- it is only used when + # laptop mode is enabled. + echo $XFS_AGE > /proc/sys/vm/pagebuf/lm_flush_age + echo $XFS_AGE > /proc/sys/fs/xfs/lm_sync_interval + elif [ -f /proc/sys/fs/xfs/lm_age_buffer ] ; then + # (A couple of early 2.6 laptop mode patches had these.) + # The same goes for these. + echo $XFS_AGE > /proc/sys/fs/xfs/lm_age_buffer + echo $XFS_AGE > /proc/sys/fs/xfs/lm_sync_interval + elif [ -f /proc/sys/fs/xfs/age_buffer ] ; then + # (2.6.6) + # But not for these -- they are also used in normal + # operation. + echo $XFS_AGE > /proc/sys/fs/xfs/age_buffer + echo $XFS_AGE > /proc/sys/fs/xfs/sync_interval + elif [ -f /proc/sys/fs/xfs/age_buffer_centisecs ] ; then + # (2.6.7 upwards) + # And not for these either. These are in centisecs, + # not USER_HZ, so we have to use $AGE, not $XFS_AGE. + echo $AGE > /proc/sys/fs/xfs/age_buffer_centisecs + echo $AGE > /proc/sys/fs/xfs/xfssyncd_centisecs + echo 3000 > /proc/sys/fs/xfs/xfsbufd_centisecs + fi + + case "$KLEVEL" in + "2.4") + echo 1 > /proc/sys/vm/laptop_mode + echo "30 500 0 0 $AGE $AGE 60 20 0" > /proc/sys/vm/bdflush + ;; + "2.6") + echo 5 > /proc/sys/vm/laptop_mode + echo "$AGE" > /proc/sys/vm/dirty_writeback_centisecs + echo "$AGE" > /proc/sys/vm/dirty_expire_centisecs + echo "$DIRTY_RATIO" > /proc/sys/vm/dirty_ratio + echo "$DIRTY_BACKGROUND_RATIO" > /proc/sys/vm/dirty_background_ratio + ;; + esac + if [ $DO_REMOUNTS -eq 1 ]; then + cat /etc/mtab | while read DEV MP FST OPTS DUMP PASS ; do + PARSEDOPTS="$(parse_mount_opts "$OPTS")" + if [ "$FST" = 'unknown' ]; then + FST=$(deduce_fstype $MP) + fi + case "$FST" in + "ext3"|"reiserfs") + PARSEDOPTS="$(parse_mount_opts commit "$OPTS")" + mount $DEV -t $FST $MP -o remount,$PARSEDOPTS,commit=$MAX_AGE$NOATIME_OPT + ;; + "xfs") + mount $DEV -t $FST $MP -o remount,$OPTS$NOATIME_OPT + ;; + esac + if [ -b $DEV ] ; then + blockdev --setra $(($READAHEAD * 2)) $DEV + fi + done + fi + if [ $DO_HD -eq 1 ] ; then + for THISHD in $HD ; do + /sbin/hdparm -S $BATT_HD $THISHD > /dev/null 2>&1 + /sbin/hdparm -B 1 $THISHD > /dev/null 2>&1 + done + fi + if [ $DO_CPU -eq 1 -a -e /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq ]; then + if [ $CPU_MAXFREQ = 'slowest' ]; then + CPU_MAXFREQ=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq` + fi + echo $CPU_MAXFREQ > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq + fi + echo "." + ;; + stop) + U_AGE=$((100*$DEF_UPDATE)) + B_AGE=$((100*$DEF_AGE)) + echo -n "Stopping laptop_mode" + echo 0 > /proc/sys/vm/laptop_mode + if [ -f /proc/sys/fs/xfs/age_buffer -a ! -f /proc/sys/fs/xfs/lm_age_buffer ] ; then + # These need to be restored, if there are no lm_*. + echo $(($XFS_HZ*$DEF_XFS_AGE_BUFFER)) > /proc/sys/fs/xfs/age_buffer + echo $(($XFS_HZ*$DEF_XFS_SYNC_INTERVAL)) > /proc/sys/fs/xfs/sync_interval + elif [ -f /proc/sys/fs/xfs/age_buffer_centisecs ] ; then + # These need to be restored as well. + echo $((100*$DEF_XFS_AGE_BUFFER)) > /proc/sys/fs/xfs/age_buffer_centisecs + echo $((100*$DEF_XFS_SYNC_INTERVAL)) > /proc/sys/fs/xfs/xfssyncd_centisecs + echo $((100*$DEF_XFS_BUFD_INTERVAL)) > /proc/sys/fs/xfs/xfsbufd_centisecs + fi + case "$KLEVEL" in + "2.4") + echo "30 500 0 0 $U_AGE $B_AGE 60 20 0" > /proc/sys/vm/bdflush + ;; + "2.6") + echo "$U_AGE" > /proc/sys/vm/dirty_writeback_centisecs + echo "$B_AGE" > /proc/sys/vm/dirty_expire_centisecs + echo "$DEF_DIRTY_RATIO" > /proc/sys/vm/dirty_ratio + echo "$DEF_DIRTY_BACKGROUND_RATIO" > /proc/sys/vm/dirty_background_ratio + ;; + esac + if [ $DO_REMOUNTS -eq 1 ] ; then + cat /etc/mtab | while read DEV MP FST OPTS DUMP PASS ; do + # Reset commit and atime options to defaults. + if [ "$FST" = 'unknown' ]; then + FST=$(deduce_fstype $MP) + fi + case "$FST" in + "ext3"|"reiserfs") + PARSEDOPTS="$(parse_mount_opts_wfstab $DEV commit $OPTS)" + PARSEDOPTS="$(parse_yesno_opts_wfstab $DEV atime atime $PARSEDOPTS)" + mount $DEV -t $FST $MP -o remount,$PARSEDOPTS + ;; + "xfs") + PARSEDOPTS="$(parse_yesno_opts_wfstab $DEV atime atime $OPTS)" + mount $DEV -t $FST $MP -o remount,$PARSEDOPTS + ;; + esac + if [ -b $DEV ] ; then + blockdev --setra 256 $DEV + fi + done + fi + if [ $DO_HD -eq 1 ] ; then + for THISHD in $HD ; do + /sbin/hdparm -S $AC_HD $THISHD > /dev/null 2>&1 + /sbin/hdparm -B 255 $THISHD > /dev/null 2>&1 + done + fi + if [ $DO_CPU -eq 1 -a -e /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq ]; then + echo `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq` > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq + fi + echo "." + ;; + *) + echo "Usage: $0 {start|stop}" 2>&1 + exit 1 + ;; + + esac + + exit 0 + + +ACPI integration +---------------- + +Dax Kelson submitted this so that the ACPI acpid daemon will +kick off the laptop_mode script and run hdparm. The part that +automatically disables laptop mode when the battery is low was +written by Jan Topinski. + +/etc/acpi/events/ac_adapter:: + + event=ac_adapter + action=/etc/acpi/actions/ac.sh %e + +/etc/acpi/events/battery:: + + event=battery.* + action=/etc/acpi/actions/battery.sh %e + +/etc/acpi/actions/ac.sh:: + + #!/bin/bash + + # ac on/offline event handler + + status=`awk '/^state: / { print $2 }' /proc/acpi/ac_adapter/$2/state` + + case $status in + "on-line") + /sbin/laptop_mode stop + exit 0 + ;; + "off-line") + /sbin/laptop_mode start + exit 0 + ;; + esac + + +/etc/acpi/actions/battery.sh:: + + #! /bin/bash + + # Automatically disable laptop mode when the battery almost runs out. + + BATT_INFO=/proc/acpi/battery/$2/state + + if [[ -f /proc/sys/vm/laptop_mode ]] + then + LM=`cat /proc/sys/vm/laptop_mode` + if [[ $LM -gt 0 ]] + then + if [[ -f $BATT_INFO ]] + then + # Source the config file only now that we know we need + if [ -f /etc/default/laptop-mode ] ; then + # Debian + . /etc/default/laptop-mode + elif [ -f /etc/sysconfig/laptop-mode ] ; then + # Others + . /etc/sysconfig/laptop-mode + fi + MINIMUM_BATTERY_MINUTES=${MINIMUM_BATTERY_MINUTES:-'10'} + + ACTION="`cat $BATT_INFO | grep charging | cut -c 26-`" + if [[ ACTION -eq "discharging" ]] + then + PRESENT_RATE=`cat $BATT_INFO | grep "present rate:" | sed "s/.* \([0-9][0-9]* \).*/\1/" ` + REMAINING=`cat $BATT_INFO | grep "remaining capacity:" | sed "s/.* \([0-9][0-9]* \).*/\1/" ` + fi + if (($REMAINING * 60 / $PRESENT_RATE < $MINIMUM_BATTERY_MINUTES)) + then + /sbin/laptop_mode stop + fi + else + logger -p daemon.warning "You are using laptop mode and your battery interface $BATT_INFO is missing. This may lead to loss of data when the battery runs out. Check kernel ACPI support and /proc/acpi/battery folder, and edit /etc/acpi/battery.sh to set BATT_INFO to the correct path." + fi + fi + fi + + +Monitoring tool +--------------- + +Bartek Kania submitted this, it can be used to measure how much time your disk +spends spun up/down. See tools/laptop/dslm/dslm.c diff --git a/Documentation/laptops/laptop-mode.txt b/Documentation/laptops/laptop-mode.txt deleted file mode 100644 index 1c707fc9b141..000000000000 --- a/Documentation/laptops/laptop-mode.txt +++ /dev/null @@ -1,782 +0,0 @@ -How to conserve battery power using laptop-mode ------------------------------------------------ - -Document Author: Bart Samwel (bart@samwel.tk) -Date created: January 2, 2004 -Last modified: December 06, 2004 - -Introduction ------------- - -Laptop mode is used to minimize the time that the hard disk needs to be spun up, -to conserve battery power on laptops. It has been reported to cause significant -power savings. - -Contents --------- - -* Introduction -* Installation -* Caveats -* The Details -* Tips & Tricks -* Control script -* ACPI integration -* Monitoring tool - - -Installation ------------- - -To use laptop mode, you don't need to set any kernel configuration options -or anything. Simply install all the files included in this document, and -laptop mode will automatically be started when you're on battery. For -your convenience, a tarball containing an installer can be downloaded at: - -http://www.samwel.tk/laptop_mode/laptop_mode/ - -To configure laptop mode, you need to edit the configuration file, which is -located in /etc/default/laptop-mode on Debian-based systems, or in -/etc/sysconfig/laptop-mode on other systems. - -Unfortunately, automatic enabling of laptop mode does not work for -laptops that don't have ACPI. On those laptops, you need to start laptop -mode manually. To start laptop mode, run "laptop_mode start", and to -stop it, run "laptop_mode stop". (Note: The laptop mode tools package now -has experimental support for APM, you might want to try that first.) - - -Caveats -------- - -* The downside of laptop mode is that you have a chance of losing up to 10 - minutes of work. If you cannot afford this, don't use it! The supplied ACPI - scripts automatically turn off laptop mode when the battery almost runs out, - so that you won't lose any data at the end of your battery life. - -* Most desktop hard drives have a very limited lifetime measured in spindown - cycles, typically about 50.000 times (it's usually listed on the spec sheet). - Check your drive's rating, and don't wear down your drive's lifetime if you - don't need to. - -* If you mount some of your ext3/reiserfs filesystems with the -n option, then - the control script will not be able to remount them correctly. You must set - DO_REMOUNTS=0 in the control script, otherwise it will remount them with the - wrong options -- or it will fail because it cannot write to /etc/mtab. - -* If you have your filesystems listed as type "auto" in fstab, like I did, then - the control script will not recognize them as filesystems that need remounting. - You must list the filesystems with their true type instead. - -* It has been reported that some versions of the mutt mail client use file access - times to determine whether a folder contains new mail. If you use mutt and - experience this, you must disable the noatime remounting by setting the option - DO_REMOUNT_NOATIME to 0 in the configuration file. - - -The Details ------------ - -Laptop mode is controlled by the knob /proc/sys/vm/laptop_mode. This knob is -present for all kernels that have the laptop mode patch, regardless of any -configuration options. When the knob is set, any physical disk I/O (that might -have caused the hard disk to spin up) causes Linux to flush all dirty blocks. The -result of this is that after a disk has spun down, it will not be spun up -anymore to write dirty blocks, because those blocks had already been written -immediately after the most recent read operation. The value of the laptop_mode -knob determines the time between the occurrence of disk I/O and when the flush -is triggered. A sensible value for the knob is 5 seconds. Setting the knob to -0 disables laptop mode. - -To increase the effectiveness of the laptop_mode strategy, the laptop_mode -control script increases dirty_expire_centisecs and dirty_writeback_centisecs in -/proc/sys/vm to about 10 minutes (by default), which means that pages that are -dirtied are not forced to be written to disk as often. The control script also -changes the dirty background ratio, so that background writeback of dirty pages -is not done anymore. Combined with a higher commit value (also 10 minutes) for -ext3 or ReiserFS filesystems (also done automatically by the control script), -this results in concentration of disk activity in a small time interval which -occurs only once every 10 minutes, or whenever the disk is forced to spin up by -a cache miss. The disk can then be spun down in the periods of inactivity. - -If you want to find out which process caused the disk to spin up, you can -gather information by setting the flag /proc/sys/vm/block_dump. When this flag -is set, Linux reports all disk read and write operations that take place, and -all block dirtyings done to files. This makes it possible to debug why a disk -needs to spin up, and to increase battery life even more. The output of -block_dump is written to the kernel output, and it can be retrieved using -"dmesg". When you use block_dump and your kernel logging level also includes -kernel debugging messages, you probably want to turn off klogd, otherwise -the output of block_dump will be logged, causing disk activity that is not -normally there. - - -Configuration -------------- - -The laptop mode configuration file is located in /etc/default/laptop-mode on -Debian-based systems, or in /etc/sysconfig/laptop-mode on other systems. It -contains the following options: - -MAX_AGE: - -Maximum time, in seconds, of hard drive spindown time that you are -comfortable with. Worst case, it's possible that you could lose this -amount of work if your battery fails while you're in laptop mode. - -MINIMUM_BATTERY_MINUTES: - -Automatically disable laptop mode if the remaining number of minutes of -battery power is less than this value. Default is 10 minutes. - -AC_HD/BATT_HD: - -The idle timeout that should be set on your hard drive when laptop mode -is active (BATT_HD) and when it is not active (AC_HD). The defaults are -20 seconds (value 4) for BATT_HD and 2 hours (value 244) for AC_HD. The -possible values are those listed in the manual page for "hdparm" for the -"-S" option. - -HD: - -The devices for which the spindown timeout should be adjusted by laptop mode. -Default is /dev/hda. If you specify multiple devices, separate them by a space. - -READAHEAD: - -Disk readahead, in 512-byte sectors, while laptop mode is active. A large -readahead can prevent disk accesses for things like executable pages (which are -loaded on demand while the application executes) and sequentially accessed data -(MP3s). - -DO_REMOUNTS: - -The control script automatically remounts any mounted journaled filesystems -with appropriate commit interval options. When this option is set to 0, this -feature is disabled. - -DO_REMOUNT_NOATIME: - -When remounting, should the filesystems be remounted with the noatime option? -Normally, this is set to "1" (enabled), but there may be programs that require -access time recording. - -DIRTY_RATIO: - -The percentage of memory that is allowed to contain "dirty" or unsaved data -before a writeback is forced, while laptop mode is active. Corresponds to -the /proc/sys/vm/dirty_ratio sysctl. - -DIRTY_BACKGROUND_RATIO: - -The percentage of memory that is allowed to contain "dirty" or unsaved data -after a forced writeback is done due to an exceeding of DIRTY_RATIO. Set -this nice and low. This corresponds to the /proc/sys/vm/dirty_background_ratio -sysctl. - -Note that the behaviour of dirty_background_ratio is quite different -when laptop mode is active and when it isn't. When laptop mode is inactive, -dirty_background_ratio is the threshold percentage at which background writeouts -start taking place. When laptop mode is active, however, background writeouts -are disabled, and the dirty_background_ratio only determines how much writeback -is done when dirty_ratio is reached. - -DO_CPU: - -Enable CPU frequency scaling when in laptop mode. (Requires CPUFreq to be setup. -See Documentation/admin-guide/pm/cpufreq.rst for more info. Disabled by default.) - -CPU_MAXFREQ: - -When on battery, what is the maximum CPU speed that the system should use? Legal -values are "slowest" for the slowest speed that your CPU is able to operate at, -or a value listed in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies. - - -Tips & Tricks -------------- - -* Bartek Kania reports getting up to 50 minutes of extra battery life (on top - of his regular 3 to 3.5 hours) using a spindown time of 5 seconds (BATT_HD=1). - -* You can spin down the disk while playing MP3, by setting disk readahead - to 8MB (READAHEAD=16384). Effectively, the disk will read a complete MP3 at - once, and will then spin down while the MP3 is playing. (Thanks to Bartek - Kania.) - -* Drew Scott Daniels observed: "I don't know why, but when I decrease the number - of colours that my display uses it consumes less battery power. I've seen - this on powerbooks too. I hope that this is a piece of information that - might be useful to the Laptop Mode patch or its users." - -* In syslog.conf, you can prefix entries with a dash ``-'' to omit syncing the - file after every logging. When you're using laptop-mode and your disk doesn't - spin down, this is a likely culprit. - -* Richard Atterer observed that laptop mode does not work well with noflushd - (http://noflushd.sourceforge.net/), it seems that noflushd prevents laptop-mode - from doing its thing. - -* If you're worried about your data, you might want to consider using a USB - memory stick or something like that as a "working area". (Be aware though - that flash memory can only handle a limited number of writes, and overuse - may wear out your memory stick pretty quickly. Do _not_ use journalling - filesystems on flash memory sticks.) - - -Configuration file for control and ACPI battery scripts -------------------------------------------------------- - -This allows the tunables to be changed for the scripts via an external -configuration file - -It should be installed as /etc/default/laptop-mode on Debian, and as -/etc/sysconfig/laptop-mode on Red Hat, SUSE, Mandrake, and other work-alikes. - ---------------------CONFIG FILE BEGIN------------------------------------------- -# Maximum time, in seconds, of hard drive spindown time that you are -# comfortable with. Worst case, it's possible that you could lose this -# amount of work if your battery fails you while in laptop mode. -#MAX_AGE=600 - -# Automatically disable laptop mode when the number of minutes of battery -# that you have left goes below this threshold. -MINIMUM_BATTERY_MINUTES=10 - -# Read-ahead, in 512-byte sectors. You can spin down the disk while playing MP3/OGG -# by setting the disk readahead to 8MB (READAHEAD=16384). Effectively, the disk -# will read a complete MP3 at once, and will then spin down while the MP3/OGG is -# playing. -#READAHEAD=4096 - -# Shall we remount journaled fs. with appropriate commit interval? (1=yes) -#DO_REMOUNTS=1 - -# And shall we add the "noatime" option to that as well? (1=yes) -#DO_REMOUNT_NOATIME=1 - -# Dirty synchronous ratio. At this percentage of dirty pages the process -# which -# calls write() does its own writeback -#DIRTY_RATIO=40 - -# -# Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been -# exceeded, the kernel will wake flusher threads which will then reduce the -# amount of dirty memory to dirty_background_ratio. Set this nice and low, -# so once some writeout has commenced, we do a lot of it. -# -#DIRTY_BACKGROUND_RATIO=5 - -# kernel default dirty buffer age -#DEF_AGE=30 -#DEF_UPDATE=5 -#DEF_DIRTY_BACKGROUND_RATIO=10 -#DEF_DIRTY_RATIO=40 -#DEF_XFS_AGE_BUFFER=15 -#DEF_XFS_SYNC_INTERVAL=30 -#DEF_XFS_BUFD_INTERVAL=1 - -# This must be adjusted manually to the value of HZ in the running kernel -# on 2.4, until the XFS people change their 2.4 external interfaces to work in -# centisecs. This can be automated, but it's a work in progress that still -# needs# some fixes. On 2.6 kernels, XFS uses USER_HZ instead of HZ for -# external interfaces, and that is currently always set to 100. So you don't -# need to change this on 2.6. -#XFS_HZ=100 - -# Should the maximum CPU frequency be adjusted down while on battery? -# Requires CPUFreq to be setup. -# See Documentation/admin-guide/pm/cpufreq.rst for more info -#DO_CPU=0 - -# When on battery what is the maximum CPU speed that the system should -# use? Legal values are "slowest" for the slowest speed that your -# CPU is able to operate at, or a value listed in: -# /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies -# Only applicable if DO_CPU=1. -#CPU_MAXFREQ=slowest - -# Idle timeout for your hard drive (man hdparm for valid values, -S option) -# Default is 2 hours on AC (AC_HD=244) and 20 seconds for battery (BATT_HD=4). -#AC_HD=244 -#BATT_HD=4 - -# The drives for which to adjust the idle timeout. Separate them by a space, -# e.g. HD="/dev/hda /dev/hdb". -#HD="/dev/hda" - -# Set the spindown timeout on a hard drive? -#DO_HD=1 - ---------------------CONFIG FILE END--------------------------------------------- - - -Control script --------------- - -Please note that this control script works for the Linux 2.4 and 2.6 series (thanks -to Kiko Piris). - ---------------------CONTROL SCRIPT BEGIN---------------------------------------- -#!/bin/bash - -# start or stop laptop_mode, best run by a power management daemon when -# ac gets connected/disconnected from a laptop -# -# install as /sbin/laptop_mode -# -# Contributors to this script: Kiko Piris -# Bart Samwel -# Micha Feigin -# Andrew Morton -# Herve Eychenne -# Dax Kelson -# -# Original Linux 2.4 version by: Jens Axboe - -############################################################################# - -# Source config -if [ -f /etc/default/laptop-mode ] ; then - # Debian - . /etc/default/laptop-mode -elif [ -f /etc/sysconfig/laptop-mode ] ; then - # Others - . /etc/sysconfig/laptop-mode -fi - -# Don't raise an error if the config file is incomplete -# set defaults instead: - -# Maximum time, in seconds, of hard drive spindown time that you are -# comfortable with. Worst case, it's possible that you could lose this -# amount of work if your battery fails you while in laptop mode. -MAX_AGE=${MAX_AGE:-'600'} - -# Read-ahead, in kilobytes -READAHEAD=${READAHEAD:-'4096'} - -# Shall we remount journaled fs. with appropriate commit interval? (1=yes) -DO_REMOUNTS=${DO_REMOUNTS:-'1'} - -# And shall we add the "noatime" option to that as well? (1=yes) -DO_REMOUNT_NOATIME=${DO_REMOUNT_NOATIME:-'1'} - -# Shall we adjust the idle timeout on a hard drive? -DO_HD=${DO_HD:-'1'} - -# Adjust idle timeout on which hard drive? -HD="${HD:-'/dev/hda'}" - -# spindown time for HD (hdparm -S values) -AC_HD=${AC_HD:-'244'} -BATT_HD=${BATT_HD:-'4'} - -# Dirty synchronous ratio. At this percentage of dirty pages the process which -# calls write() does its own writeback -DIRTY_RATIO=${DIRTY_RATIO:-'40'} - -# cpu frequency scaling -# See Documentation/admin-guide/pm/cpufreq.rst for more info -DO_CPU=${CPU_MANAGE:-'0'} -CPU_MAXFREQ=${CPU_MAXFREQ:-'slowest'} - -# -# Allowed dirty background ratio, in percent. Once DIRTY_RATIO has been -# exceeded, the kernel will wake flusher threads which will then reduce the -# amount of dirty memory to dirty_background_ratio. Set this nice and low, -# so once some writeout has commenced, we do a lot of it. -# -DIRTY_BACKGROUND_RATIO=${DIRTY_BACKGROUND_RATIO:-'5'} - -# kernel default dirty buffer age -DEF_AGE=${DEF_AGE:-'30'} -DEF_UPDATE=${DEF_UPDATE:-'5'} -DEF_DIRTY_BACKGROUND_RATIO=${DEF_DIRTY_BACKGROUND_RATIO:-'10'} -DEF_DIRTY_RATIO=${DEF_DIRTY_RATIO:-'40'} -DEF_XFS_AGE_BUFFER=${DEF_XFS_AGE_BUFFER:-'15'} -DEF_XFS_SYNC_INTERVAL=${DEF_XFS_SYNC_INTERVAL:-'30'} -DEF_XFS_BUFD_INTERVAL=${DEF_XFS_BUFD_INTERVAL:-'1'} - -# This must be adjusted manually to the value of HZ in the running kernel -# on 2.4, until the XFS people change their 2.4 external interfaces to work in -# centisecs. This can be automated, but it's a work in progress that still needs -# some fixes. On 2.6 kernels, XFS uses USER_HZ instead of HZ for external -# interfaces, and that is currently always set to 100. So you don't need to -# change this on 2.6. -XFS_HZ=${XFS_HZ:-'100'} - -############################################################################# - -KLEVEL="$(uname -r | - { - IFS='.' read a b c - echo $a.$b - } -)" -case "$KLEVEL" in - "2.4"|"2.6") - ;; - *) - echo "Unhandled kernel version: $KLEVEL ('uname -r' = '$(uname -r)')" >&2 - exit 1 - ;; -esac - -if [ ! -e /proc/sys/vm/laptop_mode ] ; then - echo "Kernel is not patched with laptop_mode patch." >&2 - exit 1 -fi - -if [ ! -w /proc/sys/vm/laptop_mode ] ; then - echo "You do not have enough privileges to enable laptop_mode." >&2 - exit 1 -fi - -# Remove an option (the first parameter) of the form option= from -# a mount options string (the rest of the parameters). -parse_mount_opts () { - OPT="$1" - shift - echo ",$*," | sed \ - -e 's/,'"$OPT"'=[0-9]*,/,/g' \ - -e 's/,,*/,/g' \ - -e 's/^,//' \ - -e 's/,$//' -} - -# Remove an option (the first parameter) without any arguments from -# a mount option string (the rest of the parameters). -parse_nonumber_mount_opts () { - OPT="$1" - shift - echo ",$*," | sed \ - -e 's/,'"$OPT"',/,/g' \ - -e 's/,,*/,/g' \ - -e 's/^,//' \ - -e 's/,$//' -} - -# Find out the state of a yes/no option (e.g. "atime"/"noatime") in -# fstab for a given filesystem, and use this state to replace the -# value of the option in another mount options string. The device -# is the first argument, the option name the second, and the default -# value the third. The remainder is the mount options string. -# -# Example: -# parse_yesno_opts_wfstab /dev/hda1 atime atime defaults,noatime -# -# If fstab contains, say, "rw" for this filesystem, then the result -# will be "defaults,atime". -parse_yesno_opts_wfstab () { - L_DEV="$1" - OPT="$2" - DEF_OPT="$3" - shift 3 - L_OPTS="$*" - PARSEDOPTS1="$(parse_nonumber_mount_opts $OPT $L_OPTS)" - PARSEDOPTS1="$(parse_nonumber_mount_opts no$OPT $PARSEDOPTS1)" - # Watch for a default atime in fstab - FSTAB_OPTS="$(awk '$1 == "'$L_DEV'" { print $4 }' /etc/fstab)" - if echo "$FSTAB_OPTS" | grep "$OPT" > /dev/null ; then - # option specified in fstab: extract the value and use it - if echo "$FSTAB_OPTS" | grep "no$OPT" > /dev/null ; then - echo "$PARSEDOPTS1,no$OPT" - else - # no$OPT not found -- so we must have $OPT. - echo "$PARSEDOPTS1,$OPT" - fi - else - # option not specified in fstab -- choose the default. - echo "$PARSEDOPTS1,$DEF_OPT" - fi -} - -# Find out the state of a numbered option (e.g. "commit=NNN") in -# fstab for a given filesystem, and use this state to replace the -# value of the option in another mount options string. The device -# is the first argument, and the option name the second. The -# remainder is the mount options string in which the replacement -# must be done. -# -# Example: -# parse_mount_opts_wfstab /dev/hda1 commit defaults,commit=7 -# -# If fstab contains, say, "commit=3,rw" for this filesystem, then the -# result will be "rw,commit=3". -parse_mount_opts_wfstab () { - L_DEV="$1" - OPT="$2" - shift 2 - L_OPTS="$*" - PARSEDOPTS1="$(parse_mount_opts $OPT $L_OPTS)" - # Watch for a default commit in fstab - FSTAB_OPTS="$(awk '$1 == "'$L_DEV'" { print $4 }' /etc/fstab)" - if echo "$FSTAB_OPTS" | grep "$OPT=" > /dev/null ; then - # option specified in fstab: extract the value, and use it - echo -n "$PARSEDOPTS1,$OPT=" - echo ",$FSTAB_OPTS," | sed \ - -e 's/.*,'"$OPT"'=//' \ - -e 's/,.*//' - else - # option not specified in fstab: set it to 0 - echo "$PARSEDOPTS1,$OPT=0" - fi -} - -deduce_fstype () { - MP="$1" - # My root filesystem unfortunately has - # type "unknown" in /etc/mtab. If we encounter - # "unknown", we try to get the type from fstab. - cat /etc/fstab | - grep -v '^#' | - while read FSTAB_DEV FSTAB_MP FSTAB_FST FSTAB_OPTS FSTAB_DUMP FSTAB_DUMP ; do - if [ "$FSTAB_MP" = "$MP" ]; then - echo $FSTAB_FST - exit 0 - fi - done -} - -if [ $DO_REMOUNT_NOATIME -eq 1 ] ; then - NOATIME_OPT=",noatime" -fi - -case "$1" in - start) - AGE=$((100*$MAX_AGE)) - XFS_AGE=$(($XFS_HZ*$MAX_AGE)) - echo -n "Starting laptop_mode" - - if [ -d /proc/sys/vm/pagebuf ] ; then - # (For 2.4 and early 2.6.) - # This only needs to be set, not reset -- it is only used when - # laptop mode is enabled. - echo $XFS_AGE > /proc/sys/vm/pagebuf/lm_flush_age - echo $XFS_AGE > /proc/sys/fs/xfs/lm_sync_interval - elif [ -f /proc/sys/fs/xfs/lm_age_buffer ] ; then - # (A couple of early 2.6 laptop mode patches had these.) - # The same goes for these. - echo $XFS_AGE > /proc/sys/fs/xfs/lm_age_buffer - echo $XFS_AGE > /proc/sys/fs/xfs/lm_sync_interval - elif [ -f /proc/sys/fs/xfs/age_buffer ] ; then - # (2.6.6) - # But not for these -- they are also used in normal - # operation. - echo $XFS_AGE > /proc/sys/fs/xfs/age_buffer - echo $XFS_AGE > /proc/sys/fs/xfs/sync_interval - elif [ -f /proc/sys/fs/xfs/age_buffer_centisecs ] ; then - # (2.6.7 upwards) - # And not for these either. These are in centisecs, - # not USER_HZ, so we have to use $AGE, not $XFS_AGE. - echo $AGE > /proc/sys/fs/xfs/age_buffer_centisecs - echo $AGE > /proc/sys/fs/xfs/xfssyncd_centisecs - echo 3000 > /proc/sys/fs/xfs/xfsbufd_centisecs - fi - - case "$KLEVEL" in - "2.4") - echo 1 > /proc/sys/vm/laptop_mode - echo "30 500 0 0 $AGE $AGE 60 20 0" > /proc/sys/vm/bdflush - ;; - "2.6") - echo 5 > /proc/sys/vm/laptop_mode - echo "$AGE" > /proc/sys/vm/dirty_writeback_centisecs - echo "$AGE" > /proc/sys/vm/dirty_expire_centisecs - echo "$DIRTY_RATIO" > /proc/sys/vm/dirty_ratio - echo "$DIRTY_BACKGROUND_RATIO" > /proc/sys/vm/dirty_background_ratio - ;; - esac - if [ $DO_REMOUNTS -eq 1 ]; then - cat /etc/mtab | while read DEV MP FST OPTS DUMP PASS ; do - PARSEDOPTS="$(parse_mount_opts "$OPTS")" - if [ "$FST" = 'unknown' ]; then - FST=$(deduce_fstype $MP) - fi - case "$FST" in - "ext3"|"reiserfs") - PARSEDOPTS="$(parse_mount_opts commit "$OPTS")" - mount $DEV -t $FST $MP -o remount,$PARSEDOPTS,commit=$MAX_AGE$NOATIME_OPT - ;; - "xfs") - mount $DEV -t $FST $MP -o remount,$OPTS$NOATIME_OPT - ;; - esac - if [ -b $DEV ] ; then - blockdev --setra $(($READAHEAD * 2)) $DEV - fi - done - fi - if [ $DO_HD -eq 1 ] ; then - for THISHD in $HD ; do - /sbin/hdparm -S $BATT_HD $THISHD > /dev/null 2>&1 - /sbin/hdparm -B 1 $THISHD > /dev/null 2>&1 - done - fi - if [ $DO_CPU -eq 1 -a -e /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq ]; then - if [ $CPU_MAXFREQ = 'slowest' ]; then - CPU_MAXFREQ=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq` - fi - echo $CPU_MAXFREQ > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq - fi - echo "." - ;; - stop) - U_AGE=$((100*$DEF_UPDATE)) - B_AGE=$((100*$DEF_AGE)) - echo -n "Stopping laptop_mode" - echo 0 > /proc/sys/vm/laptop_mode - if [ -f /proc/sys/fs/xfs/age_buffer -a ! -f /proc/sys/fs/xfs/lm_age_buffer ] ; then - # These need to be restored, if there are no lm_*. - echo $(($XFS_HZ*$DEF_XFS_AGE_BUFFER)) > /proc/sys/fs/xfs/age_buffer - echo $(($XFS_HZ*$DEF_XFS_SYNC_INTERVAL)) > /proc/sys/fs/xfs/sync_interval - elif [ -f /proc/sys/fs/xfs/age_buffer_centisecs ] ; then - # These need to be restored as well. - echo $((100*$DEF_XFS_AGE_BUFFER)) > /proc/sys/fs/xfs/age_buffer_centisecs - echo $((100*$DEF_XFS_SYNC_INTERVAL)) > /proc/sys/fs/xfs/xfssyncd_centisecs - echo $((100*$DEF_XFS_BUFD_INTERVAL)) > /proc/sys/fs/xfs/xfsbufd_centisecs - fi - case "$KLEVEL" in - "2.4") - echo "30 500 0 0 $U_AGE $B_AGE 60 20 0" > /proc/sys/vm/bdflush - ;; - "2.6") - echo "$U_AGE" > /proc/sys/vm/dirty_writeback_centisecs - echo "$B_AGE" > /proc/sys/vm/dirty_expire_centisecs - echo "$DEF_DIRTY_RATIO" > /proc/sys/vm/dirty_ratio - echo "$DEF_DIRTY_BACKGROUND_RATIO" > /proc/sys/vm/dirty_background_ratio - ;; - esac - if [ $DO_REMOUNTS -eq 1 ] ; then - cat /etc/mtab | while read DEV MP FST OPTS DUMP PASS ; do - # Reset commit and atime options to defaults. - if [ "$FST" = 'unknown' ]; then - FST=$(deduce_fstype $MP) - fi - case "$FST" in - "ext3"|"reiserfs") - PARSEDOPTS="$(parse_mount_opts_wfstab $DEV commit $OPTS)" - PARSEDOPTS="$(parse_yesno_opts_wfstab $DEV atime atime $PARSEDOPTS)" - mount $DEV -t $FST $MP -o remount,$PARSEDOPTS - ;; - "xfs") - PARSEDOPTS="$(parse_yesno_opts_wfstab $DEV atime atime $OPTS)" - mount $DEV -t $FST $MP -o remount,$PARSEDOPTS - ;; - esac - if [ -b $DEV ] ; then - blockdev --setra 256 $DEV - fi - done - fi - if [ $DO_HD -eq 1 ] ; then - for THISHD in $HD ; do - /sbin/hdparm -S $AC_HD $THISHD > /dev/null 2>&1 - /sbin/hdparm -B 255 $THISHD > /dev/null 2>&1 - done - fi - if [ $DO_CPU -eq 1 -a -e /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq ]; then - echo `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq` > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq - fi - echo "." - ;; - *) - echo "Usage: $0 {start|stop}" 2>&1 - exit 1 - ;; - -esac - -exit 0 ---------------------CONTROL SCRIPT END------------------------------------------ - - -ACPI integration ----------------- - -Dax Kelson submitted this so that the ACPI acpid daemon will -kick off the laptop_mode script and run hdparm. The part that -automatically disables laptop mode when the battery is low was -written by Jan Topinski. - ------------------/etc/acpi/events/ac_adapter BEGIN------------------------------ -event=ac_adapter -action=/etc/acpi/actions/ac.sh %e -----------------/etc/acpi/events/ac_adapter END--------------------------------- - - ------------------/etc/acpi/events/battery BEGIN--------------------------------- -event=battery.* -action=/etc/acpi/actions/battery.sh %e -----------------/etc/acpi/events/battery END------------------------------------ - - -----------------/etc/acpi/actions/ac.sh BEGIN----------------------------------- -#!/bin/bash - -# ac on/offline event handler - -status=`awk '/^state: / { print $2 }' /proc/acpi/ac_adapter/$2/state` - -case $status in - "on-line") - /sbin/laptop_mode stop - exit 0 - ;; - "off-line") - /sbin/laptop_mode start - exit 0 - ;; -esac ----------------------------/etc/acpi/actions/ac.sh END-------------------------- - - ----------------------------/etc/acpi/actions/battery.sh BEGIN------------------- -#! /bin/bash - -# Automatically disable laptop mode when the battery almost runs out. - -BATT_INFO=/proc/acpi/battery/$2/state - -if [[ -f /proc/sys/vm/laptop_mode ]] -then - LM=`cat /proc/sys/vm/laptop_mode` - if [[ $LM -gt 0 ]] - then - if [[ -f $BATT_INFO ]] - then - # Source the config file only now that we know we need - if [ -f /etc/default/laptop-mode ] ; then - # Debian - . /etc/default/laptop-mode - elif [ -f /etc/sysconfig/laptop-mode ] ; then - # Others - . /etc/sysconfig/laptop-mode - fi - MINIMUM_BATTERY_MINUTES=${MINIMUM_BATTERY_MINUTES:-'10'} - - ACTION="`cat $BATT_INFO | grep charging | cut -c 26-`" - if [[ ACTION -eq "discharging" ]] - then - PRESENT_RATE=`cat $BATT_INFO | grep "present rate:" | sed "s/.* \([0-9][0-9]* \).*/\1/" ` - REMAINING=`cat $BATT_INFO | grep "remaining capacity:" | sed "s/.* \([0-9][0-9]* \).*/\1/" ` - fi - if (($REMAINING * 60 / $PRESENT_RATE < $MINIMUM_BATTERY_MINUTES)) - then - /sbin/laptop_mode stop - fi - else - logger -p daemon.warning "You are using laptop mode and your battery interface $BATT_INFO is missing. This may lead to loss of data when the battery runs out. Check kernel ACPI support and /proc/acpi/battery folder, and edit /etc/acpi/battery.sh to set BATT_INFO to the correct path." - fi - fi -fi ----------------------------/etc/acpi/actions/battery.sh END-------------------- - - -Monitoring tool ---------------- - -Bartek Kania submitted this, it can be used to measure how much time your disk -spends spun up/down. See tools/laptop/dslm/dslm.c diff --git a/Documentation/laptops/sony-laptop.rst b/Documentation/laptops/sony-laptop.rst new file mode 100644 index 000000000000..9edcc7f6612f --- /dev/null +++ b/Documentation/laptops/sony-laptop.rst @@ -0,0 +1,174 @@ +========================================= +Sony Notebook Control Driver (SNC) Readme +========================================= + + - Copyright (C) 2004- 2005 Stelian Pop + - Copyright (C) 2007 Mattia Dongili + +This mini-driver drives the SNC and SPIC device present in the ACPI BIOS of the +Sony Vaio laptops. This driver mixes both devices functions under the same +(hopefully consistent) interface. This also means that the sonypi driver is +obsoleted by sony-laptop now. + +Fn keys (hotkeys): +------------------ + +Some models report hotkeys through the SNC or SPIC devices, such events are +reported both through the ACPI subsystem as acpi events and through the INPUT +subsystem. See the logs of /proc/bus/input/devices to find out what those +events are and which input devices are created by the driver. +Additionally, loading the driver with the debug option will report all events +in the kernel log. + +The "scancodes" passed to the input system (that can be remapped with udev) +are indexes to the table "sony_laptop_input_keycode_map" in the sony-laptop.c +module. For example the "FN/E" key combination (EJECTCD on some models) +generates the scancode 20 (0x14). + +Backlight control: +------------------ +If your laptop model supports it, you will find sysfs files in the +/sys/class/backlight/sony/ +directory. You will be able to query and set the current screen +brightness: + + ====================== ========================================= + brightness get/set screen brightness (an integer + between 0 and 7) + actual_brightness reading from this file will query the HW + to get real brightness value + max_brightness the maximum brightness value + ====================== ========================================= + + +Platform specific: +------------------ +Loading the sony-laptop module will create a +/sys/devices/platform/sony-laptop/ +directory populated with some files. + +You then read/write integer values from/to those files by using +standard UNIX tools. + +The files are: + + ====================== ========================================== + brightness_default screen brightness which will be set + when the laptop will be rebooted + cdpower power on/off the internal CD drive + audiopower power on/off the internal sound card + lanpower power on/off the internal ethernet card + (only in debug mode) + bluetoothpower power on/off the internal bluetooth device + fanspeed get/set the fan speed + ====================== ========================================== + +Note that some files may be missing if they are not supported +by your particular laptop model. + +Example usage:: + + # echo "1" > /sys/devices/platform/sony-laptop/brightness_default + +sets the lowest screen brightness for the next and later reboots + +:: + + # echo "8" > /sys/devices/platform/sony-laptop/brightness_default + +sets the highest screen brightness for the next and later reboots + +:: + + # cat /sys/devices/platform/sony-laptop/brightness_default + +retrieves the value + +:: + + # echo "0" > /sys/devices/platform/sony-laptop/audiopower + +powers off the sound card + +:: + + # echo "1" > /sys/devices/platform/sony-laptop/audiopower + +powers on the sound card. + + +RFkill control: +--------------- +More recent Vaio models expose a consistent set of ACPI methods to +control radio frequency emitting devices. If you are a lucky owner of +such a laptop you will find the necessary rfkill devices under +/sys/class/rfkill. Check those starting with sony-* in:: + + # grep . /sys/class/rfkill/*/{state,name} + + +Development: +------------ + +If you want to help with the development of this driver (and +you are not afraid of any side effects doing strange things with +your ACPI BIOS could have on your laptop), load the driver and +pass the option 'debug=1'. + +REPEAT: + **DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS.** + +In your kernel logs you will find the list of all ACPI methods +the SNC device has on your laptop. + +* For new models you will see a long list of meaningless method names, + reading the DSDT table source should reveal that: + +(1) the SNC device uses an internal capability lookup table +(2) SN00 is used to find values in the lookup table +(3) SN06 and SN07 are used to call into the real methods based on + offsets you can obtain iterating the table using SN00 +(4) SN02 used to enable events. + +Some values in the capability lookup table are more or less known, see +the code for all sony_call_snc_handle calls, others are more obscure. + +* For old models you can see the GCDP/GCDP methods used to pwer on/off + the CD drive, but there are others and they are usually different from + model to model. + +**I HAVE NO IDEA WHAT THOSE METHODS DO.** + +The sony-laptop driver creates, for some of those methods (the most +current ones found on several Vaio models), an entry under +/sys/devices/platform/sony-laptop, just like the 'cdpower' one. +You can create other entries corresponding to your own laptop methods by +further editing the source (see the 'sony_nc_values' table, and add a new +entry to this table with your get/set method names using the +SNC_HANDLE_NAMES macro). + +Your mission, should you accept it, is to try finding out what +those entries are for, by reading/writing random values from/to those +files and find out what is the impact on your laptop. + +Should you find anything interesting, please report it back to me, +I will not disavow all knowledge of your actions :) + +See also http://www.linux.it/~malattia/wiki/index.php/Sony_drivers for other +useful info. + +Bugs/Limitations: +----------------- + +* This driver is not based on official documentation from Sony + (because there is none), so there is no guarantee this driver + will work at all, or do the right thing. Although this hasn't + happened to me, this driver could do very bad things to your + laptop, including permanent damage. + +* The sony-laptop and sonypi drivers do not interact at all. In the + future, sonypi will be removed and replaced by sony-laptop. + +* spicctrl, which is the userspace tool used to communicate with the + sonypi driver (through /dev/sonypi) is deprecated as well since all + its features are now available under the sysfs tree via sony-laptop. diff --git a/Documentation/laptops/sony-laptop.txt b/Documentation/laptops/sony-laptop.txt deleted file mode 100644 index 978b1e615155..000000000000 --- a/Documentation/laptops/sony-laptop.txt +++ /dev/null @@ -1,144 +0,0 @@ -Sony Notebook Control Driver (SNC) Readme ------------------------------------------ - Copyright (C) 2004- 2005 Stelian Pop - Copyright (C) 2007 Mattia Dongili - -This mini-driver drives the SNC and SPIC device present in the ACPI BIOS of the -Sony Vaio laptops. This driver mixes both devices functions under the same -(hopefully consistent) interface. This also means that the sonypi driver is -obsoleted by sony-laptop now. - -Fn keys (hotkeys): ------------------- -Some models report hotkeys through the SNC or SPIC devices, such events are -reported both through the ACPI subsystem as acpi events and through the INPUT -subsystem. See the logs of /proc/bus/input/devices to find out what those -events are and which input devices are created by the driver. -Additionally, loading the driver with the debug option will report all events -in the kernel log. - -The "scancodes" passed to the input system (that can be remapped with udev) -are indexes to the table "sony_laptop_input_keycode_map" in the sony-laptop.c -module. For example the "FN/E" key combination (EJECTCD on some models) -generates the scancode 20 (0x14). - -Backlight control: ------------------- -If your laptop model supports it, you will find sysfs files in the -/sys/class/backlight/sony/ -directory. You will be able to query and set the current screen -brightness: - brightness get/set screen brightness (an integer - between 0 and 7) - actual_brightness reading from this file will query the HW - to get real brightness value - max_brightness the maximum brightness value - - -Platform specific: ------------------- -Loading the sony-laptop module will create a -/sys/devices/platform/sony-laptop/ -directory populated with some files. - -You then read/write integer values from/to those files by using -standard UNIX tools. - -The files are: - brightness_default screen brightness which will be set - when the laptop will be rebooted - cdpower power on/off the internal CD drive - audiopower power on/off the internal sound card - lanpower power on/off the internal ethernet card - (only in debug mode) - bluetoothpower power on/off the internal bluetooth device - fanspeed get/set the fan speed - -Note that some files may be missing if they are not supported -by your particular laptop model. - -Example usage: - # echo "1" > /sys/devices/platform/sony-laptop/brightness_default -sets the lowest screen brightness for the next and later reboots, - # echo "8" > /sys/devices/platform/sony-laptop/brightness_default -sets the highest screen brightness for the next and later reboots, - # cat /sys/devices/platform/sony-laptop/brightness_default -retrieves the value. - - # echo "0" > /sys/devices/platform/sony-laptop/audiopower -powers off the sound card, - # echo "1" > /sys/devices/platform/sony-laptop/audiopower -powers on the sound card. - - -RFkill control: ---------------- -More recent Vaio models expose a consistent set of ACPI methods to -control radio frequency emitting devices. If you are a lucky owner of -such a laptop you will find the necessary rfkill devices under -/sys/class/rfkill. Check those starting with sony-* in - # grep . /sys/class/rfkill/*/{state,name} - - -Development: ------------- - -If you want to help with the development of this driver (and -you are not afraid of any side effects doing strange things with -your ACPI BIOS could have on your laptop), load the driver and -pass the option 'debug=1'. - -REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS. - -In your kernel logs you will find the list of all ACPI methods -the SNC device has on your laptop. - -* For new models you will see a long list of meaningless method names, -reading the DSDT table source should reveal that: -(1) the SNC device uses an internal capability lookup table -(2) SN00 is used to find values in the lookup table -(3) SN06 and SN07 are used to call into the real methods based on - offsets you can obtain iterating the table using SN00 -(4) SN02 used to enable events. -Some values in the capability lookup table are more or less known, see -the code for all sony_call_snc_handle calls, others are more obscure. - -* For old models you can see the GCDP/GCDP methods used to pwer on/off -the CD drive, but there are others and they are usually different from -model to model. - -I HAVE NO IDEA WHAT THOSE METHODS DO. - -The sony-laptop driver creates, for some of those methods (the most -current ones found on several Vaio models), an entry under -/sys/devices/platform/sony-laptop, just like the 'cdpower' one. -You can create other entries corresponding to your own laptop methods by -further editing the source (see the 'sony_nc_values' table, and add a new -entry to this table with your get/set method names using the -SNC_HANDLE_NAMES macro). - -Your mission, should you accept it, is to try finding out what -those entries are for, by reading/writing random values from/to those -files and find out what is the impact on your laptop. - -Should you find anything interesting, please report it back to me, -I will not disavow all knowledge of your actions :) - -See also http://www.linux.it/~malattia/wiki/index.php/Sony_drivers for other -useful info. - -Bugs/Limitations: ------------------ - -* This driver is not based on official documentation from Sony - (because there is none), so there is no guarantee this driver - will work at all, or do the right thing. Although this hasn't - happened to me, this driver could do very bad things to your - laptop, including permanent damage. - -* The sony-laptop and sonypi drivers do not interact at all. In the - future, sonypi will be removed and replaced by sony-laptop. - -* spicctrl, which is the userspace tool used to communicate with the - sonypi driver (through /dev/sonypi) is deprecated as well since all - its features are now available under the sysfs tree via sony-laptop. diff --git a/Documentation/laptops/sonypi.rst b/Documentation/laptops/sonypi.rst new file mode 100644 index 000000000000..2a1975ed7ee4 --- /dev/null +++ b/Documentation/laptops/sonypi.rst @@ -0,0 +1,160 @@ +================================================== +Sony Programmable I/O Control Device Driver Readme +================================================== + + - Copyright (C) 2001-2004 Stelian Pop + - Copyright (C) 2001-2002 Alcôve + - Copyright (C) 2001 Michael Ashley + - Copyright (C) 2001 Junichi Morita + - Copyright (C) 2000 Takaya Kinjo + - Copyright (C) 2000 Andrew Tridgell + +This driver enables access to the Sony Programmable I/O Control Device which +can be found in many Sony Vaio laptops. Some newer Sony laptops (seems to be +limited to new FX series laptops, at least the FX501 and the FX702) lack a +sonypi device and are not supported at all by this driver. + +It will give access (through a user space utility) to some events those laptops +generate, like: + + - jogdial events (the small wheel on the side of Vaios) + - capture button events (only on Vaio Picturebook series) + - Fn keys + - bluetooth button (only on C1VR model) + - programmable keys, back, help, zoom, thumbphrase buttons, etc. + (when available) + +Those events (see linux/sonypi.h) can be polled using the character device node +/dev/sonypi (major 10, minor auto allocated or specified as a option). +A simple daemon which translates the jogdial movements into mouse wheel events +can be downloaded at: + +Another option to intercept the events is to get them directly through the +input layer. + +This driver supports also some ioctl commands for setting the LCD screen +brightness and querying the batteries charge information (some more +commands may be added in the future). + +This driver can also be used to set the camera controls on Picturebook series +(brightness, contrast etc), and is used by the video4linux driver for the +Motion Eye camera. + +Please note that this driver was created by reverse engineering the Windows +driver and the ACPI BIOS, because Sony doesn't agree to release any programming +specs for its laptops. If someone convinces them to do so, drop me a note. + +Driver options: +--------------- + +Several options can be passed to the sonypi driver using the standard +module argument syntax (= when passing the option to the +module or sonypi.= on the kernel boot line when sonypi is +statically linked into the kernel). Those options are: + + =============== ======================================================= + minor: minor number of the misc device /dev/sonypi, + default is -1 (automatic allocation, see /proc/misc + or kernel logs) + + camera: if you have a PictureBook series Vaio (with the + integrated MotionEye camera), set this parameter to 1 + in order to let the driver access to the camera + + fnkeyinit: on some Vaios (C1VE, C1VR etc), the Fn key events don't + get enabled unless you set this parameter to 1. + Do not use this option unless it's actually necessary, + some Vaio models don't deal well with this option. + This option is available only if the kernel is + compiled without ACPI support (since it conflicts + with it and it shouldn't be required anyway if + ACPI is already enabled). + + verbose: set to 1 to print unknown events received from the + sonypi device. + set to 2 to print all events received from the + sonypi device. + + compat: uses some compatibility code for enabling the sonypi + events. If the driver worked for you in the past + (prior to version 1.5) and does not work anymore, + add this option and report to the author. + + mask: event mask telling the driver what events will be + reported to the user. This parameter is required for + some Vaio models where the hardware reuses values + used in other Vaio models (like the FX series who does + not have a jogdial but reuses the jogdial events for + programmable keys events). The default event mask is + set to 0xffffffff, meaning that all possible events + will be tried. You can use the following bits to + construct your own event mask (from + drivers/char/sonypi.h): + + ======================== ====== + SONYPI_JOGGER_MASK 0x0001 + SONYPI_CAPTURE_MASK 0x0002 + SONYPI_FNKEY_MASK 0x0004 + SONYPI_BLUETOOTH_MASK 0x0008 + SONYPI_PKEY_MASK 0x0010 + SONYPI_BACK_MASK 0x0020 + SONYPI_HELP_MASK 0x0040 + SONYPI_LID_MASK 0x0080 + SONYPI_ZOOM_MASK 0x0100 + SONYPI_THUMBPHRASE_MASK 0x0200 + SONYPI_MEYE_MASK 0x0400 + SONYPI_MEMORYSTICK_MASK 0x0800 + SONYPI_BATTERY_MASK 0x1000 + SONYPI_WIRELESS_MASK 0x2000 + ======================== ====== + + useinput: if set (which is the default) two input devices are + created, one which interprets the jogdial events as + mouse events, the other one which acts like a + keyboard reporting the pressing of the special keys. + =============== ======================================================= + +Module use: +----------- + +In order to automatically load the sonypi module on use, you can put those +lines a configuration file in /etc/modprobe.d/:: + + alias char-major-10-250 sonypi + options sonypi minor=250 + +This supposes the use of minor 250 for the sonypi device:: + + # mknod /dev/sonypi c 10 250 + +Bugs: +----- + + - several users reported that this driver disables the BIOS-managed + Fn-keys which put the laptop in sleeping state, or switch the + external monitor on/off. There is no workaround yet, since this + driver disables all APM management for those keys, by enabling the + ACPI management (and the ACPI core stuff is not complete yet). If + you have one of those laptops with working Fn keys and want to + continue to use them, don't use this driver. + + - some users reported that the laptop speed is lower (dhrystone + tested) when using the driver with the fnkeyinit parameter. I cannot + reproduce it on my laptop and not all users have this problem. + This happens because the fnkeyinit parameter enables the ACPI + mode (but without additional ACPI control, like processor + speed handling etc). Use ACPI instead of APM if it works on your + laptop. + + - sonypi lacks the ability to distinguish between certain key + events on some models. + + - some models with the nvidia card (geforce go 6200 tc) uses a + different way to adjust the backlighting of the screen. There + is a userspace utility to adjust the brightness on those models, + which can be downloaded from + http://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2 + + - since all development was done by reverse engineering, there is + *absolutely no guarantee* that this driver will not crash your + laptop. Permanently. diff --git a/Documentation/laptops/sonypi.txt b/Documentation/laptops/sonypi.txt deleted file mode 100644 index 606bdb9ce036..000000000000 --- a/Documentation/laptops/sonypi.txt +++ /dev/null @@ -1,152 +0,0 @@ -Sony Programmable I/O Control Device Driver Readme --------------------------------------------------- - Copyright (C) 2001-2004 Stelian Pop - Copyright (C) 2001-2002 Alcôve - Copyright (C) 2001 Michael Ashley - Copyright (C) 2001 Junichi Morita - Copyright (C) 2000 Takaya Kinjo - Copyright (C) 2000 Andrew Tridgell - -This driver enables access to the Sony Programmable I/O Control Device which -can be found in many Sony Vaio laptops. Some newer Sony laptops (seems to be -limited to new FX series laptops, at least the FX501 and the FX702) lack a -sonypi device and are not supported at all by this driver. - -It will give access (through a user space utility) to some events those laptops -generate, like: - - jogdial events (the small wheel on the side of Vaios) - - capture button events (only on Vaio Picturebook series) - - Fn keys - - bluetooth button (only on C1VR model) - - programmable keys, back, help, zoom, thumbphrase buttons, etc. - (when available) - -Those events (see linux/sonypi.h) can be polled using the character device node -/dev/sonypi (major 10, minor auto allocated or specified as a option). -A simple daemon which translates the jogdial movements into mouse wheel events -can be downloaded at: - -Another option to intercept the events is to get them directly through the -input layer. - -This driver supports also some ioctl commands for setting the LCD screen -brightness and querying the batteries charge information (some more -commands may be added in the future). - -This driver can also be used to set the camera controls on Picturebook series -(brightness, contrast etc), and is used by the video4linux driver for the -Motion Eye camera. - -Please note that this driver was created by reverse engineering the Windows -driver and the ACPI BIOS, because Sony doesn't agree to release any programming -specs for its laptops. If someone convinces them to do so, drop me a note. - -Driver options: ---------------- - -Several options can be passed to the sonypi driver using the standard -module argument syntax (= when passing the option to the -module or sonypi.= on the kernel boot line when sonypi is -statically linked into the kernel). Those options are: - - minor: minor number of the misc device /dev/sonypi, - default is -1 (automatic allocation, see /proc/misc - or kernel logs) - - camera: if you have a PictureBook series Vaio (with the - integrated MotionEye camera), set this parameter to 1 - in order to let the driver access to the camera - - fnkeyinit: on some Vaios (C1VE, C1VR etc), the Fn key events don't - get enabled unless you set this parameter to 1. - Do not use this option unless it's actually necessary, - some Vaio models don't deal well with this option. - This option is available only if the kernel is - compiled without ACPI support (since it conflicts - with it and it shouldn't be required anyway if - ACPI is already enabled). - - verbose: set to 1 to print unknown events received from the - sonypi device. - set to 2 to print all events received from the - sonypi device. - - compat: uses some compatibility code for enabling the sonypi - events. If the driver worked for you in the past - (prior to version 1.5) and does not work anymore, - add this option and report to the author. - - mask: event mask telling the driver what events will be - reported to the user. This parameter is required for - some Vaio models where the hardware reuses values - used in other Vaio models (like the FX series who does - not have a jogdial but reuses the jogdial events for - programmable keys events). The default event mask is - set to 0xffffffff, meaning that all possible events - will be tried. You can use the following bits to - construct your own event mask (from - drivers/char/sonypi.h): - SONYPI_JOGGER_MASK 0x0001 - SONYPI_CAPTURE_MASK 0x0002 - SONYPI_FNKEY_MASK 0x0004 - SONYPI_BLUETOOTH_MASK 0x0008 - SONYPI_PKEY_MASK 0x0010 - SONYPI_BACK_MASK 0x0020 - SONYPI_HELP_MASK 0x0040 - SONYPI_LID_MASK 0x0080 - SONYPI_ZOOM_MASK 0x0100 - SONYPI_THUMBPHRASE_MASK 0x0200 - SONYPI_MEYE_MASK 0x0400 - SONYPI_MEMORYSTICK_MASK 0x0800 - SONYPI_BATTERY_MASK 0x1000 - SONYPI_WIRELESS_MASK 0x2000 - - useinput: if set (which is the default) two input devices are - created, one which interprets the jogdial events as - mouse events, the other one which acts like a - keyboard reporting the pressing of the special keys. - -Module use: ------------ - -In order to automatically load the sonypi module on use, you can put those -lines a configuration file in /etc/modprobe.d/: - - alias char-major-10-250 sonypi - options sonypi minor=250 - -This supposes the use of minor 250 for the sonypi device: - - # mknod /dev/sonypi c 10 250 - -Bugs: ------ - - - several users reported that this driver disables the BIOS-managed - Fn-keys which put the laptop in sleeping state, or switch the - external monitor on/off. There is no workaround yet, since this - driver disables all APM management for those keys, by enabling the - ACPI management (and the ACPI core stuff is not complete yet). If - you have one of those laptops with working Fn keys and want to - continue to use them, don't use this driver. - - - some users reported that the laptop speed is lower (dhrystone - tested) when using the driver with the fnkeyinit parameter. I cannot - reproduce it on my laptop and not all users have this problem. - This happens because the fnkeyinit parameter enables the ACPI - mode (but without additional ACPI control, like processor - speed handling etc). Use ACPI instead of APM if it works on your - laptop. - - - sonypi lacks the ability to distinguish between certain key - events on some models. - - - some models with the nvidia card (geforce go 6200 tc) uses a - different way to adjust the backlighting of the screen. There - is a userspace utility to adjust the brightness on those models, - which can be downloaded from - http://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2 - - - since all development was done by reverse engineering, there is - _absolutely no guarantee_ that this driver will not crash your - laptop. Permanently. diff --git a/Documentation/laptops/thinkpad-acpi.rst b/Documentation/laptops/thinkpad-acpi.rst new file mode 100644 index 000000000000..19d52fc3c5e9 --- /dev/null +++ b/Documentation/laptops/thinkpad-acpi.rst @@ -0,0 +1,1562 @@ +=========================== +ThinkPad ACPI Extras Driver +=========================== + +Version 0.25 + +October 16th, 2013 + +- Borislav Deianov +- Henrique de Moraes Holschuh + +http://ibm-acpi.sf.net/ + +This is a Linux driver for the IBM and Lenovo ThinkPad laptops. It +supports various features of these laptops which are accessible +through the ACPI and ACPI EC framework, but not otherwise fully +supported by the generic Linux ACPI drivers. + +This driver used to be named ibm-acpi until kernel 2.6.21 and release +0.13-20070314. It used to be in the drivers/acpi tree, but it was +moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel +2.6.22, and release 0.14. It was moved to drivers/platform/x86 for +kernel 2.6.29 and release 0.22. + +The driver is named "thinkpad-acpi". In some places, like module +names and log messages, "thinkpad_acpi" is used because of userspace +issues. + +"tpacpi" is used as a shorthand where "thinkpad-acpi" would be too +long due to length limitations on some Linux kernel versions. + +Status +------ + +The features currently supported are the following (see below for +detailed description): + + - Fn key combinations + - Bluetooth enable and disable + - video output switching, expansion control + - ThinkLight on and off + - CMOS/UCMS control + - LED control + - ACPI sounds + - temperature sensors + - Experimental: embedded controller register dump + - LCD brightness control + - Volume control + - Fan control and monitoring: fan speed, fan enable/disable + - WAN enable and disable + - UWB enable and disable + +A compatibility table by model and feature is maintained on the web +site, http://ibm-acpi.sf.net/. I appreciate any success or failure +reports, especially if they add to or correct the compatibility table. +Please include the following information in your report: + + - ThinkPad model name + - a copy of your ACPI tables, using the "acpidump" utility + - a copy of the output of dmidecode, with serial numbers + and UUIDs masked off + - which driver features work and which don't + - the observed behavior of non-working features + +Any other comments or patches are also more than welcome. + + +Installation +------------ + +If you are compiling this driver as included in the Linux kernel +sources, look for the CONFIG_THINKPAD_ACPI Kconfig option. +It is located on the menu path: "Device Drivers" -> "X86 Platform +Specific Device Drivers" -> "ThinkPad ACPI Laptop Extras". + + +Features +-------- + +The driver exports two different interfaces to userspace, which can be +used to access the features it provides. One is a legacy procfs-based +interface, which will be removed at some time in the future. The other +is a new sysfs-based interface which is not complete yet. + +The procfs interface creates the /proc/acpi/ibm directory. There is a +file under that directory for each feature it supports. The procfs +interface is mostly frozen, and will change very little if at all: it +will not be extended to add any new functionality in the driver, instead +all new functionality will be implemented on the sysfs interface. + +The sysfs interface tries to blend in the generic Linux sysfs subsystems +and classes as much as possible. Since some of these subsystems are not +yet ready or stabilized, it is expected that this interface will change, +and any and all userspace programs must deal with it. + + +Notes about the sysfs interface +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Unlike what was done with the procfs interface, correctness when talking +to the sysfs interfaces will be enforced, as will correctness in the +thinkpad-acpi's implementation of sysfs interfaces. + +Also, any bugs in the thinkpad-acpi sysfs driver code or in the +thinkpad-acpi's implementation of the sysfs interfaces will be fixed for +maximum correctness, even if that means changing an interface in +non-compatible ways. As these interfaces mature both in the kernel and +in thinkpad-acpi, such changes should become quite rare. + +Applications interfacing to the thinkpad-acpi sysfs interfaces must +follow all sysfs guidelines and correctly process all errors (the sysfs +interface makes extensive use of errors). File descriptors and open / +close operations to the sysfs inodes must also be properly implemented. + +The version of thinkpad-acpi's sysfs interface is exported by the driver +as a driver attribute (see below). + +Sysfs driver attributes are on the driver's sysfs attribute space, +for 2.6.23+ this is /sys/bus/platform/drivers/thinkpad_acpi/ and +/sys/bus/platform/drivers/thinkpad_hwmon/ + +Sysfs device attributes are on the thinkpad_acpi device sysfs attribute +space, for 2.6.23+ this is /sys/devices/platform/thinkpad_acpi/. + +Sysfs device attributes for the sensors and fan are on the +thinkpad_hwmon device's sysfs attribute space, but you should locate it +looking for a hwmon device with the name attribute of "thinkpad", or +better yet, through libsensors. For 4.14+ sysfs attributes were moved to the +hwmon device (/sys/bus/platform/devices/thinkpad_hwmon/hwmon/hwmon? or +/sys/class/hwmon/hwmon?). + +Driver version +-------------- + +procfs: /proc/acpi/ibm/driver + +sysfs driver attribute: version + +The driver name and version. No commands can be written to this file. + + +Sysfs interface version +----------------------- + +sysfs driver attribute: interface_version + +Version of the thinkpad-acpi sysfs interface, as an unsigned long +(output in hex format: 0xAAAABBCC), where: + + AAAA + - major revision + BB + - minor revision + CC + - bugfix revision + +The sysfs interface version changelog for the driver can be found at the +end of this document. Changes to the sysfs interface done by the kernel +subsystems are not documented here, nor are they tracked by this +attribute. + +Changes to the thinkpad-acpi sysfs interface are only considered +non-experimental when they are submitted to Linux mainline, at which +point the changes in this interface are documented and interface_version +may be updated. If you are using any thinkpad-acpi features not yet +sent to mainline for merging, you do so on your own risk: these features +may disappear, or be implemented in a different and incompatible way by +the time they are merged in Linux mainline. + +Changes that are backwards-compatible by nature (e.g. the addition of +attributes that do not change the way the other attributes work) do not +always warrant an update of interface_version. Therefore, one must +expect that an attribute might not be there, and deal with it properly +(an attribute not being there *is* a valid way to make it clear that a +feature is not available in sysfs). + + +Hot keys +-------- + +procfs: /proc/acpi/ibm/hotkey + +sysfs device attribute: hotkey_* + +In a ThinkPad, the ACPI HKEY handler is responsible for communicating +some important events and also keyboard hot key presses to the operating +system. Enabling the hotkey functionality of thinkpad-acpi signals the +firmware that such a driver is present, and modifies how the ThinkPad +firmware will behave in many situations. + +The driver enables the HKEY ("hot key") event reporting automatically +when loaded, and disables it when it is removed. + +The driver will report HKEY events in the following format:: + + ibm/hotkey HKEY 00000080 0000xxxx + +Some of these events refer to hot key presses, but not all of them. + +The driver will generate events over the input layer for hot keys and +radio switches, and over the ACPI netlink layer for other events. The +input layer support accepts the standard IOCTLs to remap the keycodes +assigned to each hot key. + +The hot key bit mask allows some control over which hot keys generate +events. If a key is "masked" (bit set to 0 in the mask), the firmware +will handle it. If it is "unmasked", it signals the firmware that +thinkpad-acpi would prefer to handle it, if the firmware would be so +kind to allow it (and it often doesn't!). + +Not all bits in the mask can be modified. Not all bits that can be +modified do anything. Not all hot keys can be individually controlled +by the mask. Some models do not support the mask at all. The behaviour +of the mask is, therefore, highly dependent on the ThinkPad model. + +The driver will filter out any unmasked hotkeys, so even if the firmware +doesn't allow disabling an specific hotkey, the driver will not report +events for unmasked hotkeys. + +Note that unmasking some keys prevents their default behavior. For +example, if Fn+F5 is unmasked, that key will no longer enable/disable +Bluetooth by itself in firmware. + +Note also that not all Fn key combinations are supported through ACPI +depending on the ThinkPad model and firmware version. On those +ThinkPads, it is still possible to support some extra hotkeys by +polling the "CMOS NVRAM" at least 10 times per second. The driver +attempts to enables this functionality automatically when required. + +procfs notes +^^^^^^^^^^^^ + +The following commands can be written to the /proc/acpi/ibm/hotkey file:: + + echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys + echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys + ... any other 8-hex-digit mask ... + echo reset > /proc/acpi/ibm/hotkey -- restore the recommended mask + +The following commands have been deprecated and will cause the kernel +to log a warning:: + + echo enable > /proc/acpi/ibm/hotkey -- does nothing + echo disable > /proc/acpi/ibm/hotkey -- returns an error + +The procfs interface does not support NVRAM polling control. So as to +maintain maximum bug-to-bug compatibility, it does not report any masks, +nor does it allow one to manipulate the hot key mask when the firmware +does not support masks at all, even if NVRAM polling is in use. + +sysfs notes +^^^^^^^^^^^ + + hotkey_bios_enabled: + DEPRECATED, WILL BE REMOVED SOON. + + Returns 0. + + hotkey_bios_mask: + DEPRECATED, DON'T USE, WILL BE REMOVED IN THE FUTURE. + + Returns the hot keys mask when thinkpad-acpi was loaded. + Upon module unload, the hot keys mask will be restored + to this value. This is always 0x80c, because those are + the hotkeys that were supported by ancient firmware + without mask support. + + hotkey_enable: + DEPRECATED, WILL BE REMOVED SOON. + + 0: returns -EPERM + 1: does nothing + + hotkey_mask: + bit mask to enable reporting (and depending on + the firmware, ACPI event generation) for each hot key + (see above). Returns the current status of the hot keys + mask, and allows one to modify it. + + hotkey_all_mask: + bit mask that should enable event reporting for all + supported hot keys, when echoed to hotkey_mask above. + Unless you know which events need to be handled + passively (because the firmware *will* handle them + anyway), do *not* use hotkey_all_mask. Use + hotkey_recommended_mask, instead. You have been warned. + + hotkey_recommended_mask: + bit mask that should enable event reporting for all + supported hot keys, except those which are always + handled by the firmware anyway. Echo it to + hotkey_mask above, to use. This is the default mask + used by the driver. + + hotkey_source_mask: + bit mask that selects which hot keys will the driver + poll the NVRAM for. This is auto-detected by the driver + based on the capabilities reported by the ACPI firmware, + but it can be overridden at runtime. + + Hot keys whose bits are set in hotkey_source_mask are + polled for in NVRAM, and reported as hotkey events if + enabled in hotkey_mask. Only a few hot keys are + available through CMOS NVRAM polling. + + Warning: when in NVRAM mode, the volume up/down/mute + keys are synthesized according to changes in the mixer, + which uses a single volume up or volume down hotkey + press to unmute, as per the ThinkPad volume mixer user + interface. When in ACPI event mode, volume up/down/mute + events are reported by the firmware and can behave + differently (and that behaviour changes with firmware + version -- not just with firmware models -- as well as + OSI(Linux) state). + + hotkey_poll_freq: + frequency in Hz for hot key polling. It must be between + 0 and 25 Hz. Polling is only carried out when strictly + needed. + + Setting hotkey_poll_freq to zero disables polling, and + will cause hot key presses that require NVRAM polling + to never be reported. + + Setting hotkey_poll_freq too low may cause repeated + pressings of the same hot key to be misreported as a + single key press, or to not even be detected at all. + The recommended polling frequency is 10Hz. + + hotkey_radio_sw: + If the ThinkPad has a hardware radio switch, this + attribute will read 0 if the switch is in the "radios + disabled" position, and 1 if the switch is in the + "radios enabled" position. + + This attribute has poll()/select() support. + + hotkey_tablet_mode: + If the ThinkPad has tablet capabilities, this attribute + will read 0 if the ThinkPad is in normal mode, and + 1 if the ThinkPad is in tablet mode. + + This attribute has poll()/select() support. + + wakeup_reason: + Set to 1 if the system is waking up because the user + requested a bay ejection. Set to 2 if the system is + waking up because the user requested the system to + undock. Set to zero for normal wake-ups or wake-ups + due to unknown reasons. + + This attribute has poll()/select() support. + + wakeup_hotunplug_complete: + Set to 1 if the system was waken up because of an + undock or bay ejection request, and that request + was successfully completed. At this point, it might + be useful to send the system back to sleep, at the + user's choice. Refer to HKEY events 0x4003 and + 0x3003, below. + + This attribute has poll()/select() support. + +input layer notes +^^^^^^^^^^^^^^^^^ + +A Hot key is mapped to a single input layer EV_KEY event, possibly +followed by an EV_MSC MSC_SCAN event that shall contain that key's scan +code. An EV_SYN event will always be generated to mark the end of the +event block. + +Do not use the EV_MSC MSC_SCAN events to process keys. They are to be +used as a helper to remap keys, only. They are particularly useful when +remapping KEY_UNKNOWN keys. + +The events are available in an input device, with the following id: + + ============== ============================== + Bus BUS_HOST + vendor 0x1014 (PCI_VENDOR_ID_IBM) or + 0x17aa (PCI_VENDOR_ID_LENOVO) + product 0x5054 ("TP") + version 0x4101 + ============== ============================== + +The version will have its LSB incremented if the keymap changes in a +backwards-compatible way. The MSB shall always be 0x41 for this input +device. If the MSB is not 0x41, do not use the device as described in +this section, as it is either something else (e.g. another input device +exported by a thinkpad driver, such as HDAPS) or its functionality has +been changed in a non-backwards compatible way. + +Adding other event types for other functionalities shall be considered a +backwards-compatible change for this input device. + +Thinkpad-acpi Hot Key event map (version 0x4101): + +======= ======= ============== ============================================== +ACPI Scan +event code Key Notes +======= ======= ============== ============================================== +0x1001 0x00 FN+F1 - + +0x1002 0x01 FN+F2 IBM: battery (rare) + Lenovo: Screen lock + +0x1003 0x02 FN+F3 Many IBM models always report + this hot key, even with hot keys + disabled or with Fn+F3 masked + off + IBM: screen lock, often turns + off the ThinkLight as side-effect + Lenovo: battery + +0x1004 0x03 FN+F4 Sleep button (ACPI sleep button + semantics, i.e. sleep-to-RAM). + It always generates some kind + of event, either the hot key + event or an ACPI sleep button + event. The firmware may + refuse to generate further FN+F4 + key presses until a S3 or S4 ACPI + sleep cycle is performed or some + time passes. + +0x1005 0x04 FN+F5 Radio. Enables/disables + the internal Bluetooth hardware + and W-WAN card if left in control + of the firmware. Does not affect + the WLAN card. + Should be used to turn on/off all + radios (Bluetooth+W-WAN+WLAN), + really. + +0x1006 0x05 FN+F6 - + +0x1007 0x06 FN+F7 Video output cycle. + Do you feel lucky today? + +0x1008 0x07 FN+F8 IBM: toggle screen expand + Lenovo: configure UltraNav, + or toggle screen expand + +0x1009 0x08 FN+F9 - + +... ... ... ... + +0x100B 0x0A FN+F11 - + +0x100C 0x0B FN+F12 Sleep to disk. You are always + supposed to handle it yourself, + either through the ACPI event, + or through a hotkey event. + The firmware may refuse to + generate further FN+F12 key + press events until a S3 or S4 + ACPI sleep cycle is performed, + or some time passes. + +0x100D 0x0C FN+BACKSPACE - +0x100E 0x0D FN+INSERT - +0x100F 0x0E FN+DELETE - + +0x1010 0x0F FN+HOME Brightness up. This key is + always handled by the firmware + in IBM ThinkPads, even when + unmasked. Just leave it alone. + For Lenovo ThinkPads with a new + BIOS, it has to be handled either + by the ACPI OSI, or by userspace. + The driver does the right thing, + never mess with this. +0x1011 0x10 FN+END Brightness down. See brightness + up for details. + +0x1012 0x11 FN+PGUP ThinkLight toggle. This key is + always handled by the firmware, + even when unmasked. + +0x1013 0x12 FN+PGDOWN - + +0x1014 0x13 FN+SPACE Zoom key + +0x1015 0x14 VOLUME UP Internal mixer volume up. This + key is always handled by the + firmware, even when unmasked. + NOTE: Lenovo seems to be changing + this. +0x1016 0x15 VOLUME DOWN Internal mixer volume up. This + key is always handled by the + firmware, even when unmasked. + NOTE: Lenovo seems to be changing + this. +0x1017 0x16 MUTE Mute internal mixer. This + key is always handled by the + firmware, even when unmasked. + +0x1018 0x17 THINKPAD ThinkPad/Access IBM/Lenovo key + +0x1019 0x18 unknown + +... ... ... + +0x1020 0x1F unknown +======= ======= ============== ============================================== + +The ThinkPad firmware does not allow one to differentiate when most hot +keys are pressed or released (either that, or we don't know how to, yet). +For these keys, the driver generates a set of events for a key press and +immediately issues the same set of events for a key release. It is +unknown by the driver if the ThinkPad firmware triggered these events on +hot key press or release, but the firmware will do it for either one, not +both. + +If a key is mapped to KEY_RESERVED, it generates no input events at all. +If a key is mapped to KEY_UNKNOWN, it generates an input event that +includes an scan code. If a key is mapped to anything else, it will +generate input device EV_KEY events. + +In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW +events for switches: + +============== ============================================== +SW_RFKILL_ALL T60 and later hardware rfkill rocker switch +SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A +============== ============================================== + +Non hotkey ACPI HKEY event map +------------------------------ + +Events that are never propagated by the driver: + +====== ================================================== +0x2304 System is waking up from suspend to undock +0x2305 System is waking up from suspend to eject bay +0x2404 System is waking up from hibernation to undock +0x2405 System is waking up from hibernation to eject bay +0x5001 Lid closed +0x5002 Lid opened +0x5009 Tablet swivel: switched to tablet mode +0x500A Tablet swivel: switched to normal mode +0x5010 Brightness level changed/control event +0x6000 KEYBOARD: Numlock key pressed +0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) +0x7000 Radio Switch may have changed state +====== ================================================== + + +Events that are propagated by the driver to userspace: + +====== ===================================================== +0x2313 ALARM: System is waking up from suspend because + the battery is nearly empty +0x2413 ALARM: System is waking up from hibernation because + the battery is nearly empty +0x3003 Bay ejection (see 0x2x05) complete, can sleep again +0x3006 Bay hotplug request (hint to power up SATA link when + the optical drive tray is ejected) +0x4003 Undocked (see 0x2x04), can sleep again +0x4010 Docked into hotplug port replicator (non-ACPI dock) +0x4011 Undocked from hotplug port replicator (non-ACPI dock) +0x500B Tablet pen inserted into its storage bay +0x500C Tablet pen removed from its storage bay +0x6011 ALARM: battery is too hot +0x6012 ALARM: battery is extremely hot +0x6021 ALARM: a sensor is too hot +0x6022 ALARM: a sensor is extremely hot +0x6030 System thermal table changed +0x6032 Thermal Control command set completion (DYTC, Windows) +0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED) +0x60C0 X1 Yoga 2016, Tablet mode status changed +0x60F0 Thermal Transformation changed (GMTS, Windows) +====== ===================================================== + +Battery nearly empty alarms are a last resort attempt to get the +operating system to hibernate or shutdown cleanly (0x2313), or shutdown +cleanly (0x2413) before power is lost. They must be acted upon, as the +wake up caused by the firmware will have negated most safety nets... + +When any of the "too hot" alarms happen, according to Lenovo the user +should suspend or hibernate the laptop (and in the case of battery +alarms, unplug the AC adapter) to let it cool down. These alarms do +signal that something is wrong, they should never happen on normal +operating conditions. + +The "extremely hot" alarms are emergencies. According to Lenovo, the +operating system is to force either an immediate suspend or hibernate +cycle, or a system shutdown. Obviously, something is very wrong if this +happens. + + +Brightness hotkey notes +^^^^^^^^^^^^^^^^^^^^^^^ + +Don't mess with the brightness hotkeys in a Thinkpad. If you want +notifications for OSD, use the sysfs backlight class event support. + +The driver will issue KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN events +automatically for the cases were userspace has to do something to +implement brightness changes. When you override these events, you will +either fail to handle properly the ThinkPads that require explicit +action to change backlight brightness, or the ThinkPads that require +that no action be taken to work properly. + + +Bluetooth +--------- + +procfs: /proc/acpi/ibm/bluetooth + +sysfs device attribute: bluetooth_enable (deprecated) + +sysfs rfkill class: switch "tpacpi_bluetooth_sw" + +This feature shows the presence and current state of a ThinkPad +Bluetooth device in the internal ThinkPad CDC slot. + +If the ThinkPad supports it, the Bluetooth state is stored in NVRAM, +so it is kept across reboots and power-off. + +Procfs notes +^^^^^^^^^^^^ + +If Bluetooth is installed, the following commands can be used:: + + echo enable > /proc/acpi/ibm/bluetooth + echo disable > /proc/acpi/ibm/bluetooth + +Sysfs notes +^^^^^^^^^^^ + + If the Bluetooth CDC card is installed, it can be enabled / + disabled through the "bluetooth_enable" thinkpad-acpi device + attribute, and its current status can also be queried. + + enable: + + - 0: disables Bluetooth / Bluetooth is disabled + - 1: enables Bluetooth / Bluetooth is enabled. + + Note: this interface has been superseded by the generic rfkill + class. It has been deprecated, and it will be removed in year + 2010. + + rfkill controller switch "tpacpi_bluetooth_sw": refer to + Documentation/rfkill.txt for details. + + +Video output control -- /proc/acpi/ibm/video +-------------------------------------------- + +This feature allows control over the devices used for video output - +LCD, CRT or DVI (if available). The following commands are available:: + + echo lcd_enable > /proc/acpi/ibm/video + echo lcd_disable > /proc/acpi/ibm/video + echo crt_enable > /proc/acpi/ibm/video + echo crt_disable > /proc/acpi/ibm/video + echo dvi_enable > /proc/acpi/ibm/video + echo dvi_disable > /proc/acpi/ibm/video + echo auto_enable > /proc/acpi/ibm/video + echo auto_disable > /proc/acpi/ibm/video + echo expand_toggle > /proc/acpi/ibm/video + echo video_switch > /proc/acpi/ibm/video + +NOTE: + Access to this feature is restricted to processes owning the + CAP_SYS_ADMIN capability for safety reasons, as it can interact badly + enough with some versions of X.org to crash it. + +Each video output device can be enabled or disabled individually. +Reading /proc/acpi/ibm/video shows the status of each device. + +Automatic video switching can be enabled or disabled. When automatic +video switching is enabled, certain events (e.g. opening the lid, +docking or undocking) cause the video output device to change +automatically. While this can be useful, it also causes flickering +and, on the X40, video corruption. By disabling automatic switching, +the flickering or video corruption can be avoided. + +The video_switch command cycles through the available video outputs +(it simulates the behavior of Fn-F7). + +Video expansion can be toggled through this feature. This controls +whether the display is expanded to fill the entire LCD screen when a +mode with less than full resolution is used. Note that the current +video expansion status cannot be determined through this feature. + +Note that on many models (particularly those using Radeon graphics +chips) the X driver configures the video card in a way which prevents +Fn-F7 from working. This also disables the video output switching +features of this driver, as it uses the same ACPI methods as +Fn-F7. Video switching on the console should still work. + +UPDATE: refer to https://bugs.freedesktop.org/show_bug.cgi?id=2000 + + +ThinkLight control +------------------ + +procfs: /proc/acpi/ibm/light + +sysfs attributes: as per LED class, for the "tpacpi::thinklight" LED + +procfs notes +^^^^^^^^^^^^ + +The ThinkLight status can be read and set through the procfs interface. A +few models which do not make the status available will show the ThinkLight +status as "unknown". The available commands are:: + + echo on > /proc/acpi/ibm/light + echo off > /proc/acpi/ibm/light + +sysfs notes +^^^^^^^^^^^ + +The ThinkLight sysfs interface is documented by the LED class +documentation, in Documentation/leds/leds-class.rst. The ThinkLight LED name +is "tpacpi::thinklight". + +Due to limitations in the sysfs LED class, if the status of the ThinkLight +cannot be read or if it is unknown, thinkpad-acpi will report it as "off". +It is impossible to know if the status returned through sysfs is valid. + + +CMOS/UCMS control +----------------- + +procfs: /proc/acpi/ibm/cmos + +sysfs device attribute: cmos_command + +This feature is mostly used internally by the ACPI firmware to keep the legacy +CMOS NVRAM bits in sync with the current machine state, and to record this +state so that the ThinkPad will retain such settings across reboots. + +Some of these commands actually perform actions in some ThinkPad models, but +this is expected to disappear more and more in newer models. As an example, in +a T43 and in a X40, commands 12 and 13 still control the ThinkLight state for +real, but commands 0 to 2 don't control the mixer anymore (they have been +phased out) and just update the NVRAM. + +The range of valid cmos command numbers is 0 to 21, but not all have an +effect and the behavior varies from model to model. Here is the behavior +on the X40 (tpb is the ThinkPad Buttons utility): + + - 0 - Related to "Volume down" key press + - 1 - Related to "Volume up" key press + - 2 - Related to "Mute on" key press + - 3 - Related to "Access IBM" key press + - 4 - Related to "LCD brightness up" key press + - 5 - Related to "LCD brightness down" key press + - 11 - Related to "toggle screen expansion" key press/function + - 12 - Related to "ThinkLight on" + - 13 - Related to "ThinkLight off" + - 14 - Related to "ThinkLight" key press (toggle ThinkLight) + +The cmos command interface is prone to firmware split-brain problems, as +in newer ThinkPads it is just a compatibility layer. Do not use it, it is +exported just as a debug tool. + + +LED control +----------- + +procfs: /proc/acpi/ibm/led +sysfs attributes: as per LED class, see below for names + +Some of the LED indicators can be controlled through this feature. On +some older ThinkPad models, it is possible to query the status of the +LED indicators as well. Newer ThinkPads cannot query the real status +of the LED indicators. + +Because misuse of the LEDs could induce an unaware user to perform +dangerous actions (like undocking or ejecting a bay device while the +buses are still active), or mask an important alarm (such as a nearly +empty battery, or a broken battery), access to most LEDs is +restricted. + +Unrestricted access to all LEDs requires that thinkpad-acpi be +compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled. +Distributions must never enable this option. Individual users that +are aware of the consequences are welcome to enabling it. + +Audio mute and microphone mute LEDs are supported, but currently not +visible to userspace. They are used by the snd-hda-intel audio driver. + +procfs notes +^^^^^^^^^^^^ + +The available commands are:: + + echo ' on' >/proc/acpi/ibm/led + echo ' off' >/proc/acpi/ibm/led + echo ' blink' >/proc/acpi/ibm/led + +The range is 0 to 15. The set of LEDs that can be +controlled varies from model to model. Here is the common ThinkPad +mapping: + + - 0 - power + - 1 - battery (orange) + - 2 - battery (green) + - 3 - UltraBase/dock + - 4 - UltraBay + - 5 - UltraBase battery slot + - 6 - (unknown) + - 7 - standby + - 8 - dock status 1 + - 9 - dock status 2 + - 10, 11 - (unknown) + - 12 - thinkvantage + - 13, 14, 15 - (unknown) + +All of the above can be turned on and off and can be made to blink. + +sysfs notes +^^^^^^^^^^^ + +The ThinkPad LED sysfs interface is described in detail by the LED class +documentation, in Documentation/leds/leds-class.rst. + +The LEDs are named (in LED ID order, from 0 to 12): +"tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt", +"tpacpi::dock_active", "tpacpi::bay_active", "tpacpi::dock_batt", +"tpacpi::unknown_led", "tpacpi::standby", "tpacpi::dock_status1", +"tpacpi::dock_status2", "tpacpi::unknown_led2", "tpacpi::unknown_led3", +"tpacpi::thinkvantage". + +Due to limitations in the sysfs LED class, if the status of the LED +indicators cannot be read due to an error, thinkpad-acpi will report it as +a brightness of zero (same as LED off). + +If the thinkpad firmware doesn't support reading the current status, +trying to read the current LED brightness will just return whatever +brightness was last written to that attribute. + +These LEDs can blink using hardware acceleration. To request that a +ThinkPad indicator LED should blink in hardware accelerated mode, use the +"timer" trigger, and leave the delay_on and delay_off parameters set to +zero (to request hardware acceleration autodetection). + +LEDs that are known not to exist in a given ThinkPad model are not +made available through the sysfs interface. If you have a dock and you +notice there are LEDs listed for your ThinkPad that do not exist (and +are not in the dock), or if you notice that there are missing LEDs, +a report to ibm-acpi-devel@lists.sourceforge.net is appreciated. + + +ACPI sounds -- /proc/acpi/ibm/beep +---------------------------------- + +The BEEP method is used internally by the ACPI firmware to provide +audible alerts in various situations. This feature allows the same +sounds to be triggered manually. + +The commands are non-negative integer numbers:: + + echo >/proc/acpi/ibm/beep + +The valid range is 0 to 17. Not all numbers trigger sounds +and the sounds vary from model to model. Here is the behavior on the +X40: + + - 0 - stop a sound in progress (but use 17 to stop 16) + - 2 - two beeps, pause, third beep ("low battery") + - 3 - single beep + - 4 - high, followed by low-pitched beep ("unable") + - 5 - single beep + - 6 - very high, followed by high-pitched beep ("AC/DC") + - 7 - high-pitched beep + - 9 - three short beeps + - 10 - very long beep + - 12 - low-pitched beep + - 15 - three high-pitched beeps repeating constantly, stop with 0 + - 16 - one medium-pitched beep repeating constantly, stop with 17 + - 17 - stop 16 + + +Temperature sensors +------------------- + +procfs: /proc/acpi/ibm/thermal + +sysfs device attributes: (hwmon "thinkpad") temp*_input + +Most ThinkPads include six or more separate temperature sensors but only +expose the CPU temperature through the standard ACPI methods. This +feature shows readings from up to eight different sensors on older +ThinkPads, and up to sixteen different sensors on newer ThinkPads. + +For example, on the X40, a typical output may be: + +temperatures: + 42 42 45 41 36 -128 33 -128 + +On the T43/p, a typical output may be: + +temperatures: + 48 48 36 52 38 -128 31 -128 48 52 48 -128 -128 -128 -128 -128 + +The mapping of thermal sensors to physical locations varies depending on +system-board model (and thus, on ThinkPad model). + +http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that +tries to track down these locations for various models. + +Most (newer?) models seem to follow this pattern: + +- 1: CPU +- 2: (depends on model) +- 3: (depends on model) +- 4: GPU +- 5: Main battery: main sensor +- 6: Bay battery: main sensor +- 7: Main battery: secondary sensor +- 8: Bay battery: secondary sensor +- 9-15: (depends on model) + +For the R51 (source: Thomas Gruber): + +- 2: Mini-PCI +- 3: Internal HDD + +For the T43, T43/p (source: Shmidoax/Thinkwiki.org) +http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p + +- 2: System board, left side (near PCMCIA slot), reported as HDAPS temp +- 3: PCMCIA slot +- 9: MCH (northbridge) to DRAM Bus +- 10: Clock-generator, mini-pci card and ICH (southbridge), under Mini-PCI + card, under touchpad +- 11: Power regulator, underside of system board, below F2 key + +The A31 has a very atypical layout for the thermal sensors +(source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31) + +- 1: CPU +- 2: Main Battery: main sensor +- 3: Power Converter +- 4: Bay Battery: main sensor +- 5: MCH (northbridge) +- 6: PCMCIA/ambient +- 7: Main Battery: secondary sensor +- 8: Bay Battery: secondary sensor + + +Procfs notes +^^^^^^^^^^^^ + + Readings from sensors that are not available return -128. + No commands can be written to this file. + +Sysfs notes +^^^^^^^^^^^ + + Sensors that are not available return the ENXIO error. This + status may change at runtime, as there are hotplug thermal + sensors, like those inside the batteries and docks. + + thinkpad-acpi thermal sensors are reported through the hwmon + subsystem, and follow all of the hwmon guidelines at + Documentation/hwmon. + +EXPERIMENTAL: Embedded controller register dump +----------------------------------------------- + +This feature is not included in the thinkpad driver anymore. +Instead the EC can be accessed through /sys/kernel/debug/ec with +a userspace tool which can be found here: +ftp://ftp.suse.com/pub/people/trenn/sources/ec + +Use it to determine the register holding the fan +speed on some models. To do that, do the following: + + - make sure the battery is fully charged + - make sure the fan is running + - use above mentioned tool to read out the EC + +Often fan and temperature values vary between +readings. Since temperatures don't change vary fast, you can take +several quick dumps to eliminate them. + +You can use a similar method to figure out the meaning of other +embedded controller registers - e.g. make sure nothing else changes +except the charging or discharging battery to determine which +registers contain the current battery capacity, etc. If you experiment +with this, do send me your results (including some complete dumps with +a description of the conditions when they were taken.) + + +LCD brightness control +---------------------- + +procfs: /proc/acpi/ibm/brightness + +sysfs backlight device "thinkpad_screen" + +This feature allows software control of the LCD brightness on ThinkPad +models which don't have a hardware brightness slider. + +It has some limitations: the LCD backlight cannot be actually turned +on or off by this interface, it just controls the backlight brightness +level. + +On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control +has eight brightness levels, ranging from 0 to 7. Some of the levels +may not be distinct. Later Lenovo models that implement the ACPI +display backlight brightness control methods have 16 levels, ranging +from 0 to 15. + +For IBM ThinkPads, there are two interfaces to the firmware for direct +brightness control, EC and UCMS (or CMOS). To select which one should be +used, use the brightness_mode module parameter: brightness_mode=1 selects +EC mode, brightness_mode=2 selects UCMS mode, brightness_mode=3 selects EC +mode with NVRAM backing (so that brightness changes are remembered across +shutdown/reboot). + +The driver tries to select which interface to use from a table of +defaults for each ThinkPad model. If it makes a wrong choice, please +report this as a bug, so that we can fix it. + +Lenovo ThinkPads only support brightness_mode=2 (UCMS). + +When display backlight brightness controls are available through the +standard ACPI interface, it is best to use it instead of this direct +ThinkPad-specific interface. The driver will disable its native +backlight brightness control interface if it detects that the standard +ACPI interface is available in the ThinkPad. + +If you want to use the thinkpad-acpi backlight brightness control +instead of the generic ACPI video backlight brightness control for some +reason, you should use the acpi_backlight=vendor kernel parameter. + +The brightness_enable module parameter can be used to control whether +the LCD brightness control feature will be enabled when available. +brightness_enable=0 forces it to be disabled. brightness_enable=1 +forces it to be enabled when available, even if the standard ACPI +interface is also available. + +Procfs notes +^^^^^^^^^^^^ + +The available commands are:: + + echo up >/proc/acpi/ibm/brightness + echo down >/proc/acpi/ibm/brightness + echo 'level ' >/proc/acpi/ibm/brightness + +Sysfs notes +^^^^^^^^^^^ + +The interface is implemented through the backlight sysfs class, which is +poorly documented at this time. + +Locate the thinkpad_screen device under /sys/class/backlight, and inside +it there will be the following attributes: + + max_brightness: + Reads the maximum brightness the hardware can be set to. + The minimum is always zero. + + actual_brightness: + Reads what brightness the screen is set to at this instant. + + brightness: + Writes request the driver to change brightness to the + given value. Reads will tell you what brightness the + driver is trying to set the display to when "power" is set + to zero and the display has not been dimmed by a kernel + power management event. + + power: + power management mode, where 0 is "display on", and 1 to 3 + will dim the display backlight to brightness level 0 + because thinkpad-acpi cannot really turn the backlight + off. Kernel power management events can temporarily + increase the current power management level, i.e. they can + dim the display. + + +WARNING: + + Whatever you do, do NOT ever call thinkpad-acpi backlight-level change + interface and the ACPI-based backlight level change interface + (available on newer BIOSes, and driven by the Linux ACPI video driver) + at the same time. The two will interact in bad ways, do funny things, + and maybe reduce the life of the backlight lamps by needlessly kicking + its level up and down at every change. + + +Volume control (Console Audio control) +-------------------------------------- + +procfs: /proc/acpi/ibm/volume + +ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC" + +NOTE: by default, the volume control interface operates in read-only +mode, as it is supposed to be used for on-screen-display purposes. +The read/write mode can be enabled through the use of the +"volume_control=1" module parameter. + +NOTE: distros are urged to not enable volume_control by default, this +should be done by the local admin only. The ThinkPad UI is for the +console audio control to be done through the volume keys only, and for +the desktop environment to just provide on-screen-display feedback. +Software volume control should be done only in the main AC97/HDA +mixer. + + +About the ThinkPad Console Audio control +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ThinkPads have a built-in amplifier and muting circuit that drives the +console headphone and speakers. This circuit is after the main AC97 +or HDA mixer in the audio path, and under exclusive control of the +firmware. + +ThinkPads have three special hotkeys to interact with the console +audio control: volume up, volume down and mute. + +It is worth noting that the normal way the mute function works (on +ThinkPads that do not have a "mute LED") is: + +1. Press mute to mute. It will *always* mute, you can press it as + many times as you want, and the sound will remain mute. + +2. Press either volume key to unmute the ThinkPad (it will _not_ + change the volume, it will just unmute). + +This is a very superior design when compared to the cheap software-only +mute-toggle solution found on normal consumer laptops: you can be +absolutely sure the ThinkPad will not make noise if you press the mute +button, no matter the previous state. + +The IBM ThinkPads, and the earlier Lenovo ThinkPads have variable-gain +amplifiers driving the speakers and headphone output, and the firmware +also handles volume control for the headphone and speakers on these +ThinkPads without any help from the operating system (this volume +control stage exists after the main AC97 or HDA mixer in the audio +path). + +The newer Lenovo models only have firmware mute control, and depend on +the main HDA mixer to do volume control (which is done by the operating +system). In this case, the volume keys are filtered out for unmute +key press (there are some firmware bugs in this area) and delivered as +normal key presses to the operating system (thinkpad-acpi is not +involved). + + +The ThinkPad-ACPI volume control +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The preferred way to interact with the Console Audio control is the +ALSA interface. + +The legacy procfs interface allows one to read the current state, +and if volume control is enabled, accepts the following commands:: + + echo up >/proc/acpi/ibm/volume + echo down >/proc/acpi/ibm/volume + echo mute >/proc/acpi/ibm/volume + echo unmute >/proc/acpi/ibm/volume + echo 'level ' >/proc/acpi/ibm/volume + +The number range is 0 to 14 although not all of them may be +distinct. To unmute the volume after the mute command, use either the +up or down command (the level command will not unmute the volume), or +the unmute command. + +You can use the volume_capabilities parameter to tell the driver +whether your thinkpad has volume control or mute-only control: +volume_capabilities=1 for mixers with mute and volume control, +volume_capabilities=2 for mixers with only mute control. + +If the driver misdetects the capabilities for your ThinkPad model, +please report this to ibm-acpi-devel@lists.sourceforge.net, so that we +can update the driver. + +There are two strategies for volume control. To select which one +should be used, use the volume_mode module parameter: volume_mode=1 +selects EC mode, and volume_mode=3 selects EC mode with NVRAM backing +(so that volume/mute changes are remembered across shutdown/reboot). + +The driver will operate in volume_mode=3 by default. If that does not +work well on your ThinkPad model, please report this to +ibm-acpi-devel@lists.sourceforge.net. + +The driver supports the standard ALSA module parameters. If the ALSA +mixer is disabled, the driver will disable all volume functionality. + + +Fan control and monitoring: fan speed, fan enable/disable +--------------------------------------------------------- + +procfs: /proc/acpi/ibm/fan + +sysfs device attributes: (hwmon "thinkpad") fan1_input, pwm1, pwm1_enable, fan2_input + +sysfs hwmon driver attributes: fan_watchdog + +NOTE NOTE NOTE: + fan control operations are disabled by default for + safety reasons. To enable them, the module parameter "fan_control=1" + must be given to thinkpad-acpi. + +This feature attempts to show the current fan speed, control mode and +other fan data that might be available. The speed is read directly +from the hardware registers of the embedded controller. This is known +to work on later R, T, X and Z series ThinkPads but may show a bogus +value on other models. + +Some Lenovo ThinkPads support a secondary fan. This fan cannot be +controlled separately, it shares the main fan control. + +Fan levels +^^^^^^^^^^ + +Most ThinkPad fans work in "levels" at the firmware interface. Level 0 +stops the fan. The higher the level, the higher the fan speed, although +adjacent levels often map to the same fan speed. 7 is the highest +level, where the fan reaches the maximum recommended speed. + +Level "auto" means the EC changes the fan level according to some +internal algorithm, usually based on readings from the thermal sensors. + +There is also a "full-speed" level, also known as "disengaged" level. +In this level, the EC disables the speed-locked closed-loop fan control, +and drives the fan as fast as it can go, which might exceed hardware +limits, so use this level with caution. + +The fan usually ramps up or down slowly from one speed to another, and +it is normal for the EC to take several seconds to react to fan +commands. The full-speed level may take up to two minutes to ramp up to +maximum speed, and in some ThinkPads, the tachometer readings go stale +while the EC is transitioning to the full-speed level. + +WARNING WARNING WARNING: do not leave the fan disabled unless you are +monitoring all of the temperature sensor readings and you are ready to +enable it if necessary to avoid overheating. + +An enabled fan in level "auto" may stop spinning if the EC decides the +ThinkPad is cool enough and doesn't need the extra airflow. This is +normal, and the EC will spin the fan up if the various thermal readings +rise too much. + +On the X40, this seems to depend on the CPU and HDD temperatures. +Specifically, the fan is turned on when either the CPU temperature +climbs to 56 degrees or the HDD temperature climbs to 46 degrees. The +fan is turned off when the CPU temperature drops to 49 degrees and the +HDD temperature drops to 41 degrees. These thresholds cannot +currently be controlled. + +The ThinkPad's ACPI DSDT code will reprogram the fan on its own when +certain conditions are met. It will override any fan programming done +through thinkpad-acpi. + +The thinkpad-acpi kernel driver can be programmed to revert the fan +level to a safe setting if userspace does not issue one of the procfs +fan commands: "enable", "disable", "level" or "watchdog", or if there +are no writes to pwm1_enable (or to pwm1 *if and only if* pwm1_enable is +set to 1, manual mode) within a configurable amount of time of up to +120 seconds. This functionality is called fan safety watchdog. + +Note that the watchdog timer stops after it enables the fan. It will be +rearmed again automatically (using the same interval) when one of the +above mentioned fan commands is received. The fan watchdog is, +therefore, not suitable to protect against fan mode changes made through +means other than the "enable", "disable", and "level" procfs fan +commands, or the hwmon fan control sysfs interface. + +Procfs notes +^^^^^^^^^^^^ + +The fan may be enabled or disabled with the following commands:: + + echo enable >/proc/acpi/ibm/fan + echo disable >/proc/acpi/ibm/fan + +Placing a fan on level 0 is the same as disabling it. Enabling a fan +will try to place it in a safe level if it is too slow or disabled. + +The fan level can be controlled with the command:: + + echo 'level ' > /proc/acpi/ibm/fan + +Where is an integer from 0 to 7, or one of the words "auto" or +"full-speed" (without the quotes). Not all ThinkPads support the "auto" +and "full-speed" levels. The driver accepts "disengaged" as an alias for +"full-speed", and reports it as "disengaged" for backwards +compatibility. + +On the X31 and X40 (and ONLY on those models), the fan speed can be +controlled to a certain degree. Once the fan is running, it can be +forced to run faster or slower with the following command:: + + echo 'speed ' > /proc/acpi/ibm/fan + +The sustainable range of fan speeds on the X40 appears to be from about +3700 to about 7350. Values outside this range either do not have any +effect or the fan speed eventually settles somewhere in that range. The +fan cannot be stopped or started with this command. This functionality +is incomplete, and not available through the sysfs interface. + +To program the safety watchdog, use the "watchdog" command:: + + echo 'watchdog ' > /proc/acpi/ibm/fan + +If you want to disable the watchdog, use 0 as the interval. + +Sysfs notes +^^^^^^^^^^^ + +The sysfs interface follows the hwmon subsystem guidelines for the most +part, and the exception is the fan safety watchdog. + +Writes to any of the sysfs attributes may return the EINVAL error if +that operation is not supported in a given ThinkPad or if the parameter +is out-of-bounds, and EPERM if it is forbidden. They may also return +EINTR (interrupted system call), and EIO (I/O error while trying to talk +to the firmware). + +Features not yet implemented by the driver return ENOSYS. + +hwmon device attribute pwm1_enable: + - 0: PWM offline (fan is set to full-speed mode) + - 1: Manual PWM control (use pwm1 to set fan level) + - 2: Hardware PWM control (EC "auto" mode) + - 3: reserved (Software PWM control, not implemented yet) + + Modes 0 and 2 are not supported by all ThinkPads, and the + driver is not always able to detect this. If it does know a + mode is unsupported, it will return -EINVAL. + +hwmon device attribute pwm1: + Fan level, scaled from the firmware values of 0-7 to the hwmon + scale of 0-255. 0 means fan stopped, 255 means highest normal + speed (level 7). + + This attribute only commands the fan if pmw1_enable is set to 1 + (manual PWM control). + +hwmon device attribute fan1_input: + Fan tachometer reading, in RPM. May go stale on certain + ThinkPads while the EC transitions the PWM to offline mode, + which can take up to two minutes. May return rubbish on older + ThinkPads. + +hwmon device attribute fan2_input: + Fan tachometer reading, in RPM, for the secondary fan. + Available only on some ThinkPads. If the secondary fan is + not installed, will always read 0. + +hwmon driver attribute fan_watchdog: + Fan safety watchdog timer interval, in seconds. Minimum is + 1 second, maximum is 120 seconds. 0 disables the watchdog. + +To stop the fan: set pwm1 to zero, and pwm1_enable to 1. + +To start the fan in a safe mode: set pwm1_enable to 2. If that fails +with EINVAL, try to set pwm1_enable to 1 and pwm1 to at least 128 (255 +would be the safest choice, though). + + +WAN +--- + +procfs: /proc/acpi/ibm/wan + +sysfs device attribute: wwan_enable (deprecated) + +sysfs rfkill class: switch "tpacpi_wwan_sw" + +This feature shows the presence and current state of the built-in +Wireless WAN device. + +If the ThinkPad supports it, the WWAN state is stored in NVRAM, +so it is kept across reboots and power-off. + +It was tested on a Lenovo ThinkPad X60. It should probably work on other +ThinkPad models which come with this module installed. + +Procfs notes +^^^^^^^^^^^^ + +If the W-WAN card is installed, the following commands can be used:: + + echo enable > /proc/acpi/ibm/wan + echo disable > /proc/acpi/ibm/wan + +Sysfs notes +^^^^^^^^^^^ + + If the W-WAN card is installed, it can be enabled / + disabled through the "wwan_enable" thinkpad-acpi device + attribute, and its current status can also be queried. + + enable: + - 0: disables WWAN card / WWAN card is disabled + - 1: enables WWAN card / WWAN card is enabled. + + Note: this interface has been superseded by the generic rfkill + class. It has been deprecated, and it will be removed in year + 2010. + + rfkill controller switch "tpacpi_wwan_sw": refer to + Documentation/rfkill.txt for details. + + +EXPERIMENTAL: UWB +----------------- + +This feature is considered EXPERIMENTAL because it has not been extensively +tested and validated in various ThinkPad models yet. The feature may not +work as expected. USE WITH CAUTION! To use this feature, you need to supply +the experimental=1 parameter when loading the module. + +sysfs rfkill class: switch "tpacpi_uwb_sw" + +This feature exports an rfkill controller for the UWB device, if one is +present and enabled in the BIOS. + +Sysfs notes +^^^^^^^^^^^ + + rfkill controller switch "tpacpi_uwb_sw": refer to + Documentation/rfkill.txt for details. + +Adaptive keyboard +----------------- + +sysfs device attribute: adaptive_kbd_mode + +This sysfs attribute controls the keyboard "face" that will be shown on the +Lenovo X1 Carbon 2nd gen (2014)'s adaptive keyboard. The value can be read +and set. + +- 1 = Home mode +- 2 = Web-browser mode +- 3 = Web-conference mode +- 4 = Function mode +- 5 = Layflat mode + +For more details about which buttons will appear depending on the mode, please +review the laptop's user guide: +http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf + +Multiple Commands, Module Parameters +------------------------------------ + +Multiple commands can be written to the proc files in one shot by +separating them with commas, for example:: + + echo enable,0xffff > /proc/acpi/ibm/hotkey + echo lcd_disable,crt_enable > /proc/acpi/ibm/video + +Commands can also be specified when loading the thinkpad-acpi module, +for example:: + + modprobe thinkpad_acpi hotkey=enable,0xffff video=auto_disable + + +Enabling debugging output +------------------------- + +The module takes a debug parameter which can be used to selectively +enable various classes of debugging output, for example:: + + modprobe thinkpad_acpi debug=0xffff + +will enable all debugging output classes. It takes a bitmask, so +to enable more than one output class, just add their values. + + ============= ====================================== + Debug bitmask Description + ============= ====================================== + 0x8000 Disclose PID of userspace programs + accessing some functions of the driver + 0x0001 Initialization and probing + 0x0002 Removal + 0x0004 RF Transmitter control (RFKILL) + (bluetooth, WWAN, UWB...) + 0x0008 HKEY event interface, hotkeys + 0x0010 Fan control + 0x0020 Backlight brightness + 0x0040 Audio mixer/volume control + ============= ====================================== + +There is also a kernel build option to enable more debugging +information, which may be necessary to debug driver problems. + +The level of debugging information output by the driver can be changed +at runtime through sysfs, using the driver attribute debug_level. The +attribute takes the same bitmask as the debug module parameter above. + + +Force loading of module +----------------------- + +If thinkpad-acpi refuses to detect your ThinkPad, you can try to specify +the module parameter force_load=1. Regardless of whether this works or +not, please contact ibm-acpi-devel@lists.sourceforge.net with a report. + + +Sysfs interface changelog +^^^^^^^^^^^^^^^^^^^^^^^^^ + +========= =============================================================== +0x000100: Initial sysfs support, as a single platform driver and + device. +0x000200: Hot key support for 32 hot keys, and radio slider switch + support. +0x010000: Hot keys are now handled by default over the input + layer, the radio switch generates input event EV_RADIO, + and the driver enables hot key handling by default in + the firmware. + +0x020000: ABI fix: added a separate hwmon platform device and + driver, which must be located by name (thinkpad) + and the hwmon class for libsensors4 (lm-sensors 3) + compatibility. Moved all hwmon attributes to this + new platform device. + +0x020100: Marker for thinkpad-acpi with hot key NVRAM polling + support. If you must, use it to know you should not + start a userspace NVRAM poller (allows to detect when + NVRAM is compiled out by the user because it is + unneeded/undesired in the first place). +0x020101: Marker for thinkpad-acpi with hot key NVRAM polling + and proper hotkey_mask semantics (version 8 of the + NVRAM polling patch). Some development snapshots of + 0.18 had an earlier version that did strange things + to hotkey_mask. + +0x020200: Add poll()/select() support to the following attributes: + hotkey_radio_sw, wakeup_hotunplug_complete, wakeup_reason + +0x020300: hotkey enable/disable support removed, attributes + hotkey_bios_enabled and hotkey_enable deprecated and + marked for removal. + +0x020400: Marker for 16 LEDs support. Also, LEDs that are known + to not exist in a given model are not registered with + the LED sysfs class anymore. + +0x020500: Updated hotkey driver, hotkey_mask is always available + and it is always able to disable hot keys. Very old + thinkpads are properly supported. hotkey_bios_mask + is deprecated and marked for removal. + +0x020600: Marker for backlight change event support. + +0x020700: Support for mute-only mixers. + Volume control in read-only mode by default. + Marker for ALSA mixer support. + +0x030000: Thermal and fan sysfs attributes were moved to the hwmon + device instead of being attached to the backing platform + device. +========= =============================================================== diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt deleted file mode 100644 index 75ef063622d2..000000000000 --- a/Documentation/laptops/thinkpad-acpi.txt +++ /dev/null @@ -1,1487 +0,0 @@ - ThinkPad ACPI Extras Driver - - Version 0.25 - October 16th, 2013 - - Borislav Deianov - Henrique de Moraes Holschuh - http://ibm-acpi.sf.net/ - - -This is a Linux driver for the IBM and Lenovo ThinkPad laptops. It -supports various features of these laptops which are accessible -through the ACPI and ACPI EC framework, but not otherwise fully -supported by the generic Linux ACPI drivers. - -This driver used to be named ibm-acpi until kernel 2.6.21 and release -0.13-20070314. It used to be in the drivers/acpi tree, but it was -moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel -2.6.22, and release 0.14. It was moved to drivers/platform/x86 for -kernel 2.6.29 and release 0.22. - -The driver is named "thinkpad-acpi". In some places, like module -names and log messages, "thinkpad_acpi" is used because of userspace -issues. - -"tpacpi" is used as a shorthand where "thinkpad-acpi" would be too -long due to length limitations on some Linux kernel versions. - -Status ------- - -The features currently supported are the following (see below for -detailed description): - - - Fn key combinations - - Bluetooth enable and disable - - video output switching, expansion control - - ThinkLight on and off - - CMOS/UCMS control - - LED control - - ACPI sounds - - temperature sensors - - Experimental: embedded controller register dump - - LCD brightness control - - Volume control - - Fan control and monitoring: fan speed, fan enable/disable - - WAN enable and disable - - UWB enable and disable - -A compatibility table by model and feature is maintained on the web -site, http://ibm-acpi.sf.net/. I appreciate any success or failure -reports, especially if they add to or correct the compatibility table. -Please include the following information in your report: - - - ThinkPad model name - - a copy of your ACPI tables, using the "acpidump" utility - - a copy of the output of dmidecode, with serial numbers - and UUIDs masked off - - which driver features work and which don't - - the observed behavior of non-working features - -Any other comments or patches are also more than welcome. - - -Installation ------------- - -If you are compiling this driver as included in the Linux kernel -sources, look for the CONFIG_THINKPAD_ACPI Kconfig option. -It is located on the menu path: "Device Drivers" -> "X86 Platform -Specific Device Drivers" -> "ThinkPad ACPI Laptop Extras". - - -Features --------- - -The driver exports two different interfaces to userspace, which can be -used to access the features it provides. One is a legacy procfs-based -interface, which will be removed at some time in the future. The other -is a new sysfs-based interface which is not complete yet. - -The procfs interface creates the /proc/acpi/ibm directory. There is a -file under that directory for each feature it supports. The procfs -interface is mostly frozen, and will change very little if at all: it -will not be extended to add any new functionality in the driver, instead -all new functionality will be implemented on the sysfs interface. - -The sysfs interface tries to blend in the generic Linux sysfs subsystems -and classes as much as possible. Since some of these subsystems are not -yet ready or stabilized, it is expected that this interface will change, -and any and all userspace programs must deal with it. - - -Notes about the sysfs interface: - -Unlike what was done with the procfs interface, correctness when talking -to the sysfs interfaces will be enforced, as will correctness in the -thinkpad-acpi's implementation of sysfs interfaces. - -Also, any bugs in the thinkpad-acpi sysfs driver code or in the -thinkpad-acpi's implementation of the sysfs interfaces will be fixed for -maximum correctness, even if that means changing an interface in -non-compatible ways. As these interfaces mature both in the kernel and -in thinkpad-acpi, such changes should become quite rare. - -Applications interfacing to the thinkpad-acpi sysfs interfaces must -follow all sysfs guidelines and correctly process all errors (the sysfs -interface makes extensive use of errors). File descriptors and open / -close operations to the sysfs inodes must also be properly implemented. - -The version of thinkpad-acpi's sysfs interface is exported by the driver -as a driver attribute (see below). - -Sysfs driver attributes are on the driver's sysfs attribute space, -for 2.6.23+ this is /sys/bus/platform/drivers/thinkpad_acpi/ and -/sys/bus/platform/drivers/thinkpad_hwmon/ - -Sysfs device attributes are on the thinkpad_acpi device sysfs attribute -space, for 2.6.23+ this is /sys/devices/platform/thinkpad_acpi/. - -Sysfs device attributes for the sensors and fan are on the -thinkpad_hwmon device's sysfs attribute space, but you should locate it -looking for a hwmon device with the name attribute of "thinkpad", or -better yet, through libsensors. For 4.14+ sysfs attributes were moved to the -hwmon device (/sys/bus/platform/devices/thinkpad_hwmon/hwmon/hwmon? or -/sys/class/hwmon/hwmon?). - -Driver version --------------- - -procfs: /proc/acpi/ibm/driver -sysfs driver attribute: version - -The driver name and version. No commands can be written to this file. - - -Sysfs interface version ------------------------ - -sysfs driver attribute: interface_version - -Version of the thinkpad-acpi sysfs interface, as an unsigned long -(output in hex format: 0xAAAABBCC), where: - AAAA - major revision - BB - minor revision - CC - bugfix revision - -The sysfs interface version changelog for the driver can be found at the -end of this document. Changes to the sysfs interface done by the kernel -subsystems are not documented here, nor are they tracked by this -attribute. - -Changes to the thinkpad-acpi sysfs interface are only considered -non-experimental when they are submitted to Linux mainline, at which -point the changes in this interface are documented and interface_version -may be updated. If you are using any thinkpad-acpi features not yet -sent to mainline for merging, you do so on your own risk: these features -may disappear, or be implemented in a different and incompatible way by -the time they are merged in Linux mainline. - -Changes that are backwards-compatible by nature (e.g. the addition of -attributes that do not change the way the other attributes work) do not -always warrant an update of interface_version. Therefore, one must -expect that an attribute might not be there, and deal with it properly -(an attribute not being there *is* a valid way to make it clear that a -feature is not available in sysfs). - - -Hot keys --------- - -procfs: /proc/acpi/ibm/hotkey -sysfs device attribute: hotkey_* - -In a ThinkPad, the ACPI HKEY handler is responsible for communicating -some important events and also keyboard hot key presses to the operating -system. Enabling the hotkey functionality of thinkpad-acpi signals the -firmware that such a driver is present, and modifies how the ThinkPad -firmware will behave in many situations. - -The driver enables the HKEY ("hot key") event reporting automatically -when loaded, and disables it when it is removed. - -The driver will report HKEY events in the following format: - - ibm/hotkey HKEY 00000080 0000xxxx - -Some of these events refer to hot key presses, but not all of them. - -The driver will generate events over the input layer for hot keys and -radio switches, and over the ACPI netlink layer for other events. The -input layer support accepts the standard IOCTLs to remap the keycodes -assigned to each hot key. - -The hot key bit mask allows some control over which hot keys generate -events. If a key is "masked" (bit set to 0 in the mask), the firmware -will handle it. If it is "unmasked", it signals the firmware that -thinkpad-acpi would prefer to handle it, if the firmware would be so -kind to allow it (and it often doesn't!). - -Not all bits in the mask can be modified. Not all bits that can be -modified do anything. Not all hot keys can be individually controlled -by the mask. Some models do not support the mask at all. The behaviour -of the mask is, therefore, highly dependent on the ThinkPad model. - -The driver will filter out any unmasked hotkeys, so even if the firmware -doesn't allow disabling an specific hotkey, the driver will not report -events for unmasked hotkeys. - -Note that unmasking some keys prevents their default behavior. For -example, if Fn+F5 is unmasked, that key will no longer enable/disable -Bluetooth by itself in firmware. - -Note also that not all Fn key combinations are supported through ACPI -depending on the ThinkPad model and firmware version. On those -ThinkPads, it is still possible to support some extra hotkeys by -polling the "CMOS NVRAM" at least 10 times per second. The driver -attempts to enables this functionality automatically when required. - -procfs notes: - -The following commands can be written to the /proc/acpi/ibm/hotkey file: - - echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys - echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys - ... any other 8-hex-digit mask ... - echo reset > /proc/acpi/ibm/hotkey -- restore the recommended mask - -The following commands have been deprecated and will cause the kernel -to log a warning: - - echo enable > /proc/acpi/ibm/hotkey -- does nothing - echo disable > /proc/acpi/ibm/hotkey -- returns an error - -The procfs interface does not support NVRAM polling control. So as to -maintain maximum bug-to-bug compatibility, it does not report any masks, -nor does it allow one to manipulate the hot key mask when the firmware -does not support masks at all, even if NVRAM polling is in use. - -sysfs notes: - - hotkey_bios_enabled: - DEPRECATED, WILL BE REMOVED SOON. - - Returns 0. - - hotkey_bios_mask: - DEPRECATED, DON'T USE, WILL BE REMOVED IN THE FUTURE. - - Returns the hot keys mask when thinkpad-acpi was loaded. - Upon module unload, the hot keys mask will be restored - to this value. This is always 0x80c, because those are - the hotkeys that were supported by ancient firmware - without mask support. - - hotkey_enable: - DEPRECATED, WILL BE REMOVED SOON. - - 0: returns -EPERM - 1: does nothing - - hotkey_mask: - bit mask to enable reporting (and depending on - the firmware, ACPI event generation) for each hot key - (see above). Returns the current status of the hot keys - mask, and allows one to modify it. - - hotkey_all_mask: - bit mask that should enable event reporting for all - supported hot keys, when echoed to hotkey_mask above. - Unless you know which events need to be handled - passively (because the firmware *will* handle them - anyway), do *not* use hotkey_all_mask. Use - hotkey_recommended_mask, instead. You have been warned. - - hotkey_recommended_mask: - bit mask that should enable event reporting for all - supported hot keys, except those which are always - handled by the firmware anyway. Echo it to - hotkey_mask above, to use. This is the default mask - used by the driver. - - hotkey_source_mask: - bit mask that selects which hot keys will the driver - poll the NVRAM for. This is auto-detected by the driver - based on the capabilities reported by the ACPI firmware, - but it can be overridden at runtime. - - Hot keys whose bits are set in hotkey_source_mask are - polled for in NVRAM, and reported as hotkey events if - enabled in hotkey_mask. Only a few hot keys are - available through CMOS NVRAM polling. - - Warning: when in NVRAM mode, the volume up/down/mute - keys are synthesized according to changes in the mixer, - which uses a single volume up or volume down hotkey - press to unmute, as per the ThinkPad volume mixer user - interface. When in ACPI event mode, volume up/down/mute - events are reported by the firmware and can behave - differently (and that behaviour changes with firmware - version -- not just with firmware models -- as well as - OSI(Linux) state). - - hotkey_poll_freq: - frequency in Hz for hot key polling. It must be between - 0 and 25 Hz. Polling is only carried out when strictly - needed. - - Setting hotkey_poll_freq to zero disables polling, and - will cause hot key presses that require NVRAM polling - to never be reported. - - Setting hotkey_poll_freq too low may cause repeated - pressings of the same hot key to be misreported as a - single key press, or to not even be detected at all. - The recommended polling frequency is 10Hz. - - hotkey_radio_sw: - If the ThinkPad has a hardware radio switch, this - attribute will read 0 if the switch is in the "radios - disabled" position, and 1 if the switch is in the - "radios enabled" position. - - This attribute has poll()/select() support. - - hotkey_tablet_mode: - If the ThinkPad has tablet capabilities, this attribute - will read 0 if the ThinkPad is in normal mode, and - 1 if the ThinkPad is in tablet mode. - - This attribute has poll()/select() support. - - wakeup_reason: - Set to 1 if the system is waking up because the user - requested a bay ejection. Set to 2 if the system is - waking up because the user requested the system to - undock. Set to zero for normal wake-ups or wake-ups - due to unknown reasons. - - This attribute has poll()/select() support. - - wakeup_hotunplug_complete: - Set to 1 if the system was waken up because of an - undock or bay ejection request, and that request - was successfully completed. At this point, it might - be useful to send the system back to sleep, at the - user's choice. Refer to HKEY events 0x4003 and - 0x3003, below. - - This attribute has poll()/select() support. - -input layer notes: - -A Hot key is mapped to a single input layer EV_KEY event, possibly -followed by an EV_MSC MSC_SCAN event that shall contain that key's scan -code. An EV_SYN event will always be generated to mark the end of the -event block. - -Do not use the EV_MSC MSC_SCAN events to process keys. They are to be -used as a helper to remap keys, only. They are particularly useful when -remapping KEY_UNKNOWN keys. - -The events are available in an input device, with the following id: - - Bus: BUS_HOST - vendor: 0x1014 (PCI_VENDOR_ID_IBM) or - 0x17aa (PCI_VENDOR_ID_LENOVO) - product: 0x5054 ("TP") - version: 0x4101 - -The version will have its LSB incremented if the keymap changes in a -backwards-compatible way. The MSB shall always be 0x41 for this input -device. If the MSB is not 0x41, do not use the device as described in -this section, as it is either something else (e.g. another input device -exported by a thinkpad driver, such as HDAPS) or its functionality has -been changed in a non-backwards compatible way. - -Adding other event types for other functionalities shall be considered a -backwards-compatible change for this input device. - -Thinkpad-acpi Hot Key event map (version 0x4101): - -ACPI Scan -event code Key Notes - -0x1001 0x00 FN+F1 - - -0x1002 0x01 FN+F2 IBM: battery (rare) - Lenovo: Screen lock - -0x1003 0x02 FN+F3 Many IBM models always report - this hot key, even with hot keys - disabled or with Fn+F3 masked - off - IBM: screen lock, often turns - off the ThinkLight as side-effect - Lenovo: battery - -0x1004 0x03 FN+F4 Sleep button (ACPI sleep button - semantics, i.e. sleep-to-RAM). - It always generates some kind - of event, either the hot key - event or an ACPI sleep button - event. The firmware may - refuse to generate further FN+F4 - key presses until a S3 or S4 ACPI - sleep cycle is performed or some - time passes. - -0x1005 0x04 FN+F5 Radio. Enables/disables - the internal Bluetooth hardware - and W-WAN card if left in control - of the firmware. Does not affect - the WLAN card. - Should be used to turn on/off all - radios (Bluetooth+W-WAN+WLAN), - really. - -0x1006 0x05 FN+F6 - - -0x1007 0x06 FN+F7 Video output cycle. - Do you feel lucky today? - -0x1008 0x07 FN+F8 IBM: toggle screen expand - Lenovo: configure UltraNav, - or toggle screen expand - -0x1009 0x08 FN+F9 - - .. .. .. -0x100B 0x0A FN+F11 - - -0x100C 0x0B FN+F12 Sleep to disk. You are always - supposed to handle it yourself, - either through the ACPI event, - or through a hotkey event. - The firmware may refuse to - generate further FN+F12 key - press events until a S3 or S4 - ACPI sleep cycle is performed, - or some time passes. - -0x100D 0x0C FN+BACKSPACE - -0x100E 0x0D FN+INSERT - -0x100F 0x0E FN+DELETE - - -0x1010 0x0F FN+HOME Brightness up. This key is - always handled by the firmware - in IBM ThinkPads, even when - unmasked. Just leave it alone. - For Lenovo ThinkPads with a new - BIOS, it has to be handled either - by the ACPI OSI, or by userspace. - The driver does the right thing, - never mess with this. -0x1011 0x10 FN+END Brightness down. See brightness - up for details. - -0x1012 0x11 FN+PGUP ThinkLight toggle. This key is - always handled by the firmware, - even when unmasked. - -0x1013 0x12 FN+PGDOWN - - -0x1014 0x13 FN+SPACE Zoom key - -0x1015 0x14 VOLUME UP Internal mixer volume up. This - key is always handled by the - firmware, even when unmasked. - NOTE: Lenovo seems to be changing - this. -0x1016 0x15 VOLUME DOWN Internal mixer volume up. This - key is always handled by the - firmware, even when unmasked. - NOTE: Lenovo seems to be changing - this. -0x1017 0x16 MUTE Mute internal mixer. This - key is always handled by the - firmware, even when unmasked. - -0x1018 0x17 THINKPAD ThinkPad/Access IBM/Lenovo key - -0x1019 0x18 unknown -.. .. .. -0x1020 0x1F unknown - -The ThinkPad firmware does not allow one to differentiate when most hot -keys are pressed or released (either that, or we don't know how to, yet). -For these keys, the driver generates a set of events for a key press and -immediately issues the same set of events for a key release. It is -unknown by the driver if the ThinkPad firmware triggered these events on -hot key press or release, but the firmware will do it for either one, not -both. - -If a key is mapped to KEY_RESERVED, it generates no input events at all. -If a key is mapped to KEY_UNKNOWN, it generates an input event that -includes an scan code. If a key is mapped to anything else, it will -generate input device EV_KEY events. - -In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW -events for switches: - -SW_RFKILL_ALL T60 and later hardware rfkill rocker switch -SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A - -Non hotkey ACPI HKEY event map: -------------------------------- - -Events that are never propagated by the driver: - -0x2304 System is waking up from suspend to undock -0x2305 System is waking up from suspend to eject bay -0x2404 System is waking up from hibernation to undock -0x2405 System is waking up from hibernation to eject bay -0x5001 Lid closed -0x5002 Lid opened -0x5009 Tablet swivel: switched to tablet mode -0x500A Tablet swivel: switched to normal mode -0x5010 Brightness level changed/control event -0x6000 KEYBOARD: Numlock key pressed -0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) -0x7000 Radio Switch may have changed state - - -Events that are propagated by the driver to userspace: - -0x2313 ALARM: System is waking up from suspend because - the battery is nearly empty -0x2413 ALARM: System is waking up from hibernation because - the battery is nearly empty -0x3003 Bay ejection (see 0x2x05) complete, can sleep again -0x3006 Bay hotplug request (hint to power up SATA link when - the optical drive tray is ejected) -0x4003 Undocked (see 0x2x04), can sleep again -0x4010 Docked into hotplug port replicator (non-ACPI dock) -0x4011 Undocked from hotplug port replicator (non-ACPI dock) -0x500B Tablet pen inserted into its storage bay -0x500C Tablet pen removed from its storage bay -0x6011 ALARM: battery is too hot -0x6012 ALARM: battery is extremely hot -0x6021 ALARM: a sensor is too hot -0x6022 ALARM: a sensor is extremely hot -0x6030 System thermal table changed -0x6032 Thermal Control command set completion (DYTC, Windows) -0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED) -0x60C0 X1 Yoga 2016, Tablet mode status changed -0x60F0 Thermal Transformation changed (GMTS, Windows) - -Battery nearly empty alarms are a last resort attempt to get the -operating system to hibernate or shutdown cleanly (0x2313), or shutdown -cleanly (0x2413) before power is lost. They must be acted upon, as the -wake up caused by the firmware will have negated most safety nets... - -When any of the "too hot" alarms happen, according to Lenovo the user -should suspend or hibernate the laptop (and in the case of battery -alarms, unplug the AC adapter) to let it cool down. These alarms do -signal that something is wrong, they should never happen on normal -operating conditions. - -The "extremely hot" alarms are emergencies. According to Lenovo, the -operating system is to force either an immediate suspend or hibernate -cycle, or a system shutdown. Obviously, something is very wrong if this -happens. - - -Brightness hotkey notes: - -Don't mess with the brightness hotkeys in a Thinkpad. If you want -notifications for OSD, use the sysfs backlight class event support. - -The driver will issue KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN events -automatically for the cases were userspace has to do something to -implement brightness changes. When you override these events, you will -either fail to handle properly the ThinkPads that require explicit -action to change backlight brightness, or the ThinkPads that require -that no action be taken to work properly. - - -Bluetooth ---------- - -procfs: /proc/acpi/ibm/bluetooth -sysfs device attribute: bluetooth_enable (deprecated) -sysfs rfkill class: switch "tpacpi_bluetooth_sw" - -This feature shows the presence and current state of a ThinkPad -Bluetooth device in the internal ThinkPad CDC slot. - -If the ThinkPad supports it, the Bluetooth state is stored in NVRAM, -so it is kept across reboots and power-off. - -Procfs notes: - -If Bluetooth is installed, the following commands can be used: - - echo enable > /proc/acpi/ibm/bluetooth - echo disable > /proc/acpi/ibm/bluetooth - -Sysfs notes: - - If the Bluetooth CDC card is installed, it can be enabled / - disabled through the "bluetooth_enable" thinkpad-acpi device - attribute, and its current status can also be queried. - - enable: - 0: disables Bluetooth / Bluetooth is disabled - 1: enables Bluetooth / Bluetooth is enabled. - - Note: this interface has been superseded by the generic rfkill - class. It has been deprecated, and it will be removed in year - 2010. - - rfkill controller switch "tpacpi_bluetooth_sw": refer to - Documentation/rfkill.txt for details. - - -Video output control -- /proc/acpi/ibm/video --------------------------------------------- - -This feature allows control over the devices used for video output - -LCD, CRT or DVI (if available). The following commands are available: - - echo lcd_enable > /proc/acpi/ibm/video - echo lcd_disable > /proc/acpi/ibm/video - echo crt_enable > /proc/acpi/ibm/video - echo crt_disable > /proc/acpi/ibm/video - echo dvi_enable > /proc/acpi/ibm/video - echo dvi_disable > /proc/acpi/ibm/video - echo auto_enable > /proc/acpi/ibm/video - echo auto_disable > /proc/acpi/ibm/video - echo expand_toggle > /proc/acpi/ibm/video - echo video_switch > /proc/acpi/ibm/video - -NOTE: Access to this feature is restricted to processes owning the -CAP_SYS_ADMIN capability for safety reasons, as it can interact badly -enough with some versions of X.org to crash it. - -Each video output device can be enabled or disabled individually. -Reading /proc/acpi/ibm/video shows the status of each device. - -Automatic video switching can be enabled or disabled. When automatic -video switching is enabled, certain events (e.g. opening the lid, -docking or undocking) cause the video output device to change -automatically. While this can be useful, it also causes flickering -and, on the X40, video corruption. By disabling automatic switching, -the flickering or video corruption can be avoided. - -The video_switch command cycles through the available video outputs -(it simulates the behavior of Fn-F7). - -Video expansion can be toggled through this feature. This controls -whether the display is expanded to fill the entire LCD screen when a -mode with less than full resolution is used. Note that the current -video expansion status cannot be determined through this feature. - -Note that on many models (particularly those using Radeon graphics -chips) the X driver configures the video card in a way which prevents -Fn-F7 from working. This also disables the video output switching -features of this driver, as it uses the same ACPI methods as -Fn-F7. Video switching on the console should still work. - -UPDATE: refer to https://bugs.freedesktop.org/show_bug.cgi?id=2000 - - -ThinkLight control ------------------- - -procfs: /proc/acpi/ibm/light -sysfs attributes: as per LED class, for the "tpacpi::thinklight" LED - -procfs notes: - -The ThinkLight status can be read and set through the procfs interface. A -few models which do not make the status available will show the ThinkLight -status as "unknown". The available commands are: - - echo on > /proc/acpi/ibm/light - echo off > /proc/acpi/ibm/light - -sysfs notes: - -The ThinkLight sysfs interface is documented by the LED class -documentation, in Documentation/leds/leds-class.rst. The ThinkLight LED name -is "tpacpi::thinklight". - -Due to limitations in the sysfs LED class, if the status of the ThinkLight -cannot be read or if it is unknown, thinkpad-acpi will report it as "off". -It is impossible to know if the status returned through sysfs is valid. - - -CMOS/UCMS control ------------------ - -procfs: /proc/acpi/ibm/cmos -sysfs device attribute: cmos_command - -This feature is mostly used internally by the ACPI firmware to keep the legacy -CMOS NVRAM bits in sync with the current machine state, and to record this -state so that the ThinkPad will retain such settings across reboots. - -Some of these commands actually perform actions in some ThinkPad models, but -this is expected to disappear more and more in newer models. As an example, in -a T43 and in a X40, commands 12 and 13 still control the ThinkLight state for -real, but commands 0 to 2 don't control the mixer anymore (they have been -phased out) and just update the NVRAM. - -The range of valid cmos command numbers is 0 to 21, but not all have an -effect and the behavior varies from model to model. Here is the behavior -on the X40 (tpb is the ThinkPad Buttons utility): - - 0 - Related to "Volume down" key press - 1 - Related to "Volume up" key press - 2 - Related to "Mute on" key press - 3 - Related to "Access IBM" key press - 4 - Related to "LCD brightness up" key press - 5 - Related to "LCD brightness down" key press - 11 - Related to "toggle screen expansion" key press/function - 12 - Related to "ThinkLight on" - 13 - Related to "ThinkLight off" - 14 - Related to "ThinkLight" key press (toggle ThinkLight) - -The cmos command interface is prone to firmware split-brain problems, as -in newer ThinkPads it is just a compatibility layer. Do not use it, it is -exported just as a debug tool. - - -LED control ------------ - -procfs: /proc/acpi/ibm/led -sysfs attributes: as per LED class, see below for names - -Some of the LED indicators can be controlled through this feature. On -some older ThinkPad models, it is possible to query the status of the -LED indicators as well. Newer ThinkPads cannot query the real status -of the LED indicators. - -Because misuse of the LEDs could induce an unaware user to perform -dangerous actions (like undocking or ejecting a bay device while the -buses are still active), or mask an important alarm (such as a nearly -empty battery, or a broken battery), access to most LEDs is -restricted. - -Unrestricted access to all LEDs requires that thinkpad-acpi be -compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled. -Distributions must never enable this option. Individual users that -are aware of the consequences are welcome to enabling it. - -Audio mute and microphone mute LEDs are supported, but currently not -visible to userspace. They are used by the snd-hda-intel audio driver. - -procfs notes: - -The available commands are: - - echo ' on' >/proc/acpi/ibm/led - echo ' off' >/proc/acpi/ibm/led - echo ' blink' >/proc/acpi/ibm/led - -The range is 0 to 15. The set of LEDs that can be -controlled varies from model to model. Here is the common ThinkPad -mapping: - - 0 - power - 1 - battery (orange) - 2 - battery (green) - 3 - UltraBase/dock - 4 - UltraBay - 5 - UltraBase battery slot - 6 - (unknown) - 7 - standby - 8 - dock status 1 - 9 - dock status 2 - 10, 11 - (unknown) - 12 - thinkvantage - 13, 14, 15 - (unknown) - -All of the above can be turned on and off and can be made to blink. - -sysfs notes: - -The ThinkPad LED sysfs interface is described in detail by the LED class -documentation, in Documentation/leds/leds-class.rst. - -The LEDs are named (in LED ID order, from 0 to 12): -"tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt", -"tpacpi::dock_active", "tpacpi::bay_active", "tpacpi::dock_batt", -"tpacpi::unknown_led", "tpacpi::standby", "tpacpi::dock_status1", -"tpacpi::dock_status2", "tpacpi::unknown_led2", "tpacpi::unknown_led3", -"tpacpi::thinkvantage". - -Due to limitations in the sysfs LED class, if the status of the LED -indicators cannot be read due to an error, thinkpad-acpi will report it as -a brightness of zero (same as LED off). - -If the thinkpad firmware doesn't support reading the current status, -trying to read the current LED brightness will just return whatever -brightness was last written to that attribute. - -These LEDs can blink using hardware acceleration. To request that a -ThinkPad indicator LED should blink in hardware accelerated mode, use the -"timer" trigger, and leave the delay_on and delay_off parameters set to -zero (to request hardware acceleration autodetection). - -LEDs that are known not to exist in a given ThinkPad model are not -made available through the sysfs interface. If you have a dock and you -notice there are LEDs listed for your ThinkPad that do not exist (and -are not in the dock), or if you notice that there are missing LEDs, -a report to ibm-acpi-devel@lists.sourceforge.net is appreciated. - - -ACPI sounds -- /proc/acpi/ibm/beep ----------------------------------- - -The BEEP method is used internally by the ACPI firmware to provide -audible alerts in various situations. This feature allows the same -sounds to be triggered manually. - -The commands are non-negative integer numbers: - - echo >/proc/acpi/ibm/beep - -The valid range is 0 to 17. Not all numbers trigger sounds -and the sounds vary from model to model. Here is the behavior on the -X40: - - 0 - stop a sound in progress (but use 17 to stop 16) - 2 - two beeps, pause, third beep ("low battery") - 3 - single beep - 4 - high, followed by low-pitched beep ("unable") - 5 - single beep - 6 - very high, followed by high-pitched beep ("AC/DC") - 7 - high-pitched beep - 9 - three short beeps - 10 - very long beep - 12 - low-pitched beep - 15 - three high-pitched beeps repeating constantly, stop with 0 - 16 - one medium-pitched beep repeating constantly, stop with 17 - 17 - stop 16 - - -Temperature sensors -------------------- - -procfs: /proc/acpi/ibm/thermal -sysfs device attributes: (hwmon "thinkpad") temp*_input - -Most ThinkPads include six or more separate temperature sensors but only -expose the CPU temperature through the standard ACPI methods. This -feature shows readings from up to eight different sensors on older -ThinkPads, and up to sixteen different sensors on newer ThinkPads. - -For example, on the X40, a typical output may be: -temperatures: 42 42 45 41 36 -128 33 -128 - -On the T43/p, a typical output may be: -temperatures: 48 48 36 52 38 -128 31 -128 48 52 48 -128 -128 -128 -128 -128 - -The mapping of thermal sensors to physical locations varies depending on -system-board model (and thus, on ThinkPad model). - -http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that -tries to track down these locations for various models. - -Most (newer?) models seem to follow this pattern: - -1: CPU -2: (depends on model) -3: (depends on model) -4: GPU -5: Main battery: main sensor -6: Bay battery: main sensor -7: Main battery: secondary sensor -8: Bay battery: secondary sensor -9-15: (depends on model) - -For the R51 (source: Thomas Gruber): -2: Mini-PCI -3: Internal HDD - -For the T43, T43/p (source: Shmidoax/Thinkwiki.org) -http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p -2: System board, left side (near PCMCIA slot), reported as HDAPS temp -3: PCMCIA slot -9: MCH (northbridge) to DRAM Bus -10: Clock-generator, mini-pci card and ICH (southbridge), under Mini-PCI - card, under touchpad -11: Power regulator, underside of system board, below F2 key - -The A31 has a very atypical layout for the thermal sensors -(source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31) -1: CPU -2: Main Battery: main sensor -3: Power Converter -4: Bay Battery: main sensor -5: MCH (northbridge) -6: PCMCIA/ambient -7: Main Battery: secondary sensor -8: Bay Battery: secondary sensor - - -Procfs notes: - Readings from sensors that are not available return -128. - No commands can be written to this file. - -Sysfs notes: - Sensors that are not available return the ENXIO error. This - status may change at runtime, as there are hotplug thermal - sensors, like those inside the batteries and docks. - - thinkpad-acpi thermal sensors are reported through the hwmon - subsystem, and follow all of the hwmon guidelines at - Documentation/hwmon. - -EXPERIMENTAL: Embedded controller register dump ------------------------------------------------ - -This feature is not included in the thinkpad driver anymore. -Instead the EC can be accessed through /sys/kernel/debug/ec with -a userspace tool which can be found here: -ftp://ftp.suse.com/pub/people/trenn/sources/ec - -Use it to determine the register holding the fan -speed on some models. To do that, do the following: - - make sure the battery is fully charged - - make sure the fan is running - - use above mentioned tool to read out the EC - -Often fan and temperature values vary between -readings. Since temperatures don't change vary fast, you can take -several quick dumps to eliminate them. - -You can use a similar method to figure out the meaning of other -embedded controller registers - e.g. make sure nothing else changes -except the charging or discharging battery to determine which -registers contain the current battery capacity, etc. If you experiment -with this, do send me your results (including some complete dumps with -a description of the conditions when they were taken.) - - -LCD brightness control ----------------------- - -procfs: /proc/acpi/ibm/brightness -sysfs backlight device "thinkpad_screen" - -This feature allows software control of the LCD brightness on ThinkPad -models which don't have a hardware brightness slider. - -It has some limitations: the LCD backlight cannot be actually turned -on or off by this interface, it just controls the backlight brightness -level. - -On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control -has eight brightness levels, ranging from 0 to 7. Some of the levels -may not be distinct. Later Lenovo models that implement the ACPI -display backlight brightness control methods have 16 levels, ranging -from 0 to 15. - -For IBM ThinkPads, there are two interfaces to the firmware for direct -brightness control, EC and UCMS (or CMOS). To select which one should be -used, use the brightness_mode module parameter: brightness_mode=1 selects -EC mode, brightness_mode=2 selects UCMS mode, brightness_mode=3 selects EC -mode with NVRAM backing (so that brightness changes are remembered across -shutdown/reboot). - -The driver tries to select which interface to use from a table of -defaults for each ThinkPad model. If it makes a wrong choice, please -report this as a bug, so that we can fix it. - -Lenovo ThinkPads only support brightness_mode=2 (UCMS). - -When display backlight brightness controls are available through the -standard ACPI interface, it is best to use it instead of this direct -ThinkPad-specific interface. The driver will disable its native -backlight brightness control interface if it detects that the standard -ACPI interface is available in the ThinkPad. - -If you want to use the thinkpad-acpi backlight brightness control -instead of the generic ACPI video backlight brightness control for some -reason, you should use the acpi_backlight=vendor kernel parameter. - -The brightness_enable module parameter can be used to control whether -the LCD brightness control feature will be enabled when available. -brightness_enable=0 forces it to be disabled. brightness_enable=1 -forces it to be enabled when available, even if the standard ACPI -interface is also available. - -Procfs notes: - - The available commands are: - - echo up >/proc/acpi/ibm/brightness - echo down >/proc/acpi/ibm/brightness - echo 'level ' >/proc/acpi/ibm/brightness - -Sysfs notes: - -The interface is implemented through the backlight sysfs class, which is -poorly documented at this time. - -Locate the thinkpad_screen device under /sys/class/backlight, and inside -it there will be the following attributes: - - max_brightness: - Reads the maximum brightness the hardware can be set to. - The minimum is always zero. - - actual_brightness: - Reads what brightness the screen is set to at this instant. - - brightness: - Writes request the driver to change brightness to the - given value. Reads will tell you what brightness the - driver is trying to set the display to when "power" is set - to zero and the display has not been dimmed by a kernel - power management event. - - power: - power management mode, where 0 is "display on", and 1 to 3 - will dim the display backlight to brightness level 0 - because thinkpad-acpi cannot really turn the backlight - off. Kernel power management events can temporarily - increase the current power management level, i.e. they can - dim the display. - - -WARNING: - - Whatever you do, do NOT ever call thinkpad-acpi backlight-level change - interface and the ACPI-based backlight level change interface - (available on newer BIOSes, and driven by the Linux ACPI video driver) - at the same time. The two will interact in bad ways, do funny things, - and maybe reduce the life of the backlight lamps by needlessly kicking - its level up and down at every change. - - -Volume control (Console Audio control) --------------------------------------- - -procfs: /proc/acpi/ibm/volume -ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC" - -NOTE: by default, the volume control interface operates in read-only -mode, as it is supposed to be used for on-screen-display purposes. -The read/write mode can be enabled through the use of the -"volume_control=1" module parameter. - -NOTE: distros are urged to not enable volume_control by default, this -should be done by the local admin only. The ThinkPad UI is for the -console audio control to be done through the volume keys only, and for -the desktop environment to just provide on-screen-display feedback. -Software volume control should be done only in the main AC97/HDA -mixer. - - -About the ThinkPad Console Audio control: - -ThinkPads have a built-in amplifier and muting circuit that drives the -console headphone and speakers. This circuit is after the main AC97 -or HDA mixer in the audio path, and under exclusive control of the -firmware. - -ThinkPads have three special hotkeys to interact with the console -audio control: volume up, volume down and mute. - -It is worth noting that the normal way the mute function works (on -ThinkPads that do not have a "mute LED") is: - -1. Press mute to mute. It will *always* mute, you can press it as - many times as you want, and the sound will remain mute. - -2. Press either volume key to unmute the ThinkPad (it will _not_ - change the volume, it will just unmute). - -This is a very superior design when compared to the cheap software-only -mute-toggle solution found on normal consumer laptops: you can be -absolutely sure the ThinkPad will not make noise if you press the mute -button, no matter the previous state. - -The IBM ThinkPads, and the earlier Lenovo ThinkPads have variable-gain -amplifiers driving the speakers and headphone output, and the firmware -also handles volume control for the headphone and speakers on these -ThinkPads without any help from the operating system (this volume -control stage exists after the main AC97 or HDA mixer in the audio -path). - -The newer Lenovo models only have firmware mute control, and depend on -the main HDA mixer to do volume control (which is done by the operating -system). In this case, the volume keys are filtered out for unmute -key press (there are some firmware bugs in this area) and delivered as -normal key presses to the operating system (thinkpad-acpi is not -involved). - - -The ThinkPad-ACPI volume control: - -The preferred way to interact with the Console Audio control is the -ALSA interface. - -The legacy procfs interface allows one to read the current state, -and if volume control is enabled, accepts the following commands: - - echo up >/proc/acpi/ibm/volume - echo down >/proc/acpi/ibm/volume - echo mute >/proc/acpi/ibm/volume - echo unmute >/proc/acpi/ibm/volume - echo 'level ' >/proc/acpi/ibm/volume - -The number range is 0 to 14 although not all of them may be -distinct. To unmute the volume after the mute command, use either the -up or down command (the level command will not unmute the volume), or -the unmute command. - -You can use the volume_capabilities parameter to tell the driver -whether your thinkpad has volume control or mute-only control: -volume_capabilities=1 for mixers with mute and volume control, -volume_capabilities=2 for mixers with only mute control. - -If the driver misdetects the capabilities for your ThinkPad model, -please report this to ibm-acpi-devel@lists.sourceforge.net, so that we -can update the driver. - -There are two strategies for volume control. To select which one -should be used, use the volume_mode module parameter: volume_mode=1 -selects EC mode, and volume_mode=3 selects EC mode with NVRAM backing -(so that volume/mute changes are remembered across shutdown/reboot). - -The driver will operate in volume_mode=3 by default. If that does not -work well on your ThinkPad model, please report this to -ibm-acpi-devel@lists.sourceforge.net. - -The driver supports the standard ALSA module parameters. If the ALSA -mixer is disabled, the driver will disable all volume functionality. - - -Fan control and monitoring: fan speed, fan enable/disable ---------------------------------------------------------- - -procfs: /proc/acpi/ibm/fan -sysfs device attributes: (hwmon "thinkpad") fan1_input, pwm1, - pwm1_enable, fan2_input -sysfs hwmon driver attributes: fan_watchdog - -NOTE NOTE NOTE: fan control operations are disabled by default for -safety reasons. To enable them, the module parameter "fan_control=1" -must be given to thinkpad-acpi. - -This feature attempts to show the current fan speed, control mode and -other fan data that might be available. The speed is read directly -from the hardware registers of the embedded controller. This is known -to work on later R, T, X and Z series ThinkPads but may show a bogus -value on other models. - -Some Lenovo ThinkPads support a secondary fan. This fan cannot be -controlled separately, it shares the main fan control. - -Fan levels: - -Most ThinkPad fans work in "levels" at the firmware interface. Level 0 -stops the fan. The higher the level, the higher the fan speed, although -adjacent levels often map to the same fan speed. 7 is the highest -level, where the fan reaches the maximum recommended speed. - -Level "auto" means the EC changes the fan level according to some -internal algorithm, usually based on readings from the thermal sensors. - -There is also a "full-speed" level, also known as "disengaged" level. -In this level, the EC disables the speed-locked closed-loop fan control, -and drives the fan as fast as it can go, which might exceed hardware -limits, so use this level with caution. - -The fan usually ramps up or down slowly from one speed to another, and -it is normal for the EC to take several seconds to react to fan -commands. The full-speed level may take up to two minutes to ramp up to -maximum speed, and in some ThinkPads, the tachometer readings go stale -while the EC is transitioning to the full-speed level. - -WARNING WARNING WARNING: do not leave the fan disabled unless you are -monitoring all of the temperature sensor readings and you are ready to -enable it if necessary to avoid overheating. - -An enabled fan in level "auto" may stop spinning if the EC decides the -ThinkPad is cool enough and doesn't need the extra airflow. This is -normal, and the EC will spin the fan up if the various thermal readings -rise too much. - -On the X40, this seems to depend on the CPU and HDD temperatures. -Specifically, the fan is turned on when either the CPU temperature -climbs to 56 degrees or the HDD temperature climbs to 46 degrees. The -fan is turned off when the CPU temperature drops to 49 degrees and the -HDD temperature drops to 41 degrees. These thresholds cannot -currently be controlled. - -The ThinkPad's ACPI DSDT code will reprogram the fan on its own when -certain conditions are met. It will override any fan programming done -through thinkpad-acpi. - -The thinkpad-acpi kernel driver can be programmed to revert the fan -level to a safe setting if userspace does not issue one of the procfs -fan commands: "enable", "disable", "level" or "watchdog", or if there -are no writes to pwm1_enable (or to pwm1 *if and only if* pwm1_enable is -set to 1, manual mode) within a configurable amount of time of up to -120 seconds. This functionality is called fan safety watchdog. - -Note that the watchdog timer stops after it enables the fan. It will be -rearmed again automatically (using the same interval) when one of the -above mentioned fan commands is received. The fan watchdog is, -therefore, not suitable to protect against fan mode changes made through -means other than the "enable", "disable", and "level" procfs fan -commands, or the hwmon fan control sysfs interface. - -Procfs notes: - -The fan may be enabled or disabled with the following commands: - - echo enable >/proc/acpi/ibm/fan - echo disable >/proc/acpi/ibm/fan - -Placing a fan on level 0 is the same as disabling it. Enabling a fan -will try to place it in a safe level if it is too slow or disabled. - -The fan level can be controlled with the command: - - echo 'level ' > /proc/acpi/ibm/fan - -Where is an integer from 0 to 7, or one of the words "auto" or -"full-speed" (without the quotes). Not all ThinkPads support the "auto" -and "full-speed" levels. The driver accepts "disengaged" as an alias for -"full-speed", and reports it as "disengaged" for backwards -compatibility. - -On the X31 and X40 (and ONLY on those models), the fan speed can be -controlled to a certain degree. Once the fan is running, it can be -forced to run faster or slower with the following command: - - echo 'speed ' > /proc/acpi/ibm/fan - -The sustainable range of fan speeds on the X40 appears to be from about -3700 to about 7350. Values outside this range either do not have any -effect or the fan speed eventually settles somewhere in that range. The -fan cannot be stopped or started with this command. This functionality -is incomplete, and not available through the sysfs interface. - -To program the safety watchdog, use the "watchdog" command. - - echo 'watchdog ' > /proc/acpi/ibm/fan - -If you want to disable the watchdog, use 0 as the interval. - -Sysfs notes: - -The sysfs interface follows the hwmon subsystem guidelines for the most -part, and the exception is the fan safety watchdog. - -Writes to any of the sysfs attributes may return the EINVAL error if -that operation is not supported in a given ThinkPad or if the parameter -is out-of-bounds, and EPERM if it is forbidden. They may also return -EINTR (interrupted system call), and EIO (I/O error while trying to talk -to the firmware). - -Features not yet implemented by the driver return ENOSYS. - -hwmon device attribute pwm1_enable: - 0: PWM offline (fan is set to full-speed mode) - 1: Manual PWM control (use pwm1 to set fan level) - 2: Hardware PWM control (EC "auto" mode) - 3: reserved (Software PWM control, not implemented yet) - - Modes 0 and 2 are not supported by all ThinkPads, and the - driver is not always able to detect this. If it does know a - mode is unsupported, it will return -EINVAL. - -hwmon device attribute pwm1: - Fan level, scaled from the firmware values of 0-7 to the hwmon - scale of 0-255. 0 means fan stopped, 255 means highest normal - speed (level 7). - - This attribute only commands the fan if pmw1_enable is set to 1 - (manual PWM control). - -hwmon device attribute fan1_input: - Fan tachometer reading, in RPM. May go stale on certain - ThinkPads while the EC transitions the PWM to offline mode, - which can take up to two minutes. May return rubbish on older - ThinkPads. - -hwmon device attribute fan2_input: - Fan tachometer reading, in RPM, for the secondary fan. - Available only on some ThinkPads. If the secondary fan is - not installed, will always read 0. - -hwmon driver attribute fan_watchdog: - Fan safety watchdog timer interval, in seconds. Minimum is - 1 second, maximum is 120 seconds. 0 disables the watchdog. - -To stop the fan: set pwm1 to zero, and pwm1_enable to 1. - -To start the fan in a safe mode: set pwm1_enable to 2. If that fails -with EINVAL, try to set pwm1_enable to 1 and pwm1 to at least 128 (255 -would be the safest choice, though). - - -WAN ---- - -procfs: /proc/acpi/ibm/wan -sysfs device attribute: wwan_enable (deprecated) -sysfs rfkill class: switch "tpacpi_wwan_sw" - -This feature shows the presence and current state of the built-in -Wireless WAN device. - -If the ThinkPad supports it, the WWAN state is stored in NVRAM, -so it is kept across reboots and power-off. - -It was tested on a Lenovo ThinkPad X60. It should probably work on other -ThinkPad models which come with this module installed. - -Procfs notes: - -If the W-WAN card is installed, the following commands can be used: - - echo enable > /proc/acpi/ibm/wan - echo disable > /proc/acpi/ibm/wan - -Sysfs notes: - - If the W-WAN card is installed, it can be enabled / - disabled through the "wwan_enable" thinkpad-acpi device - attribute, and its current status can also be queried. - - enable: - 0: disables WWAN card / WWAN card is disabled - 1: enables WWAN card / WWAN card is enabled. - - Note: this interface has been superseded by the generic rfkill - class. It has been deprecated, and it will be removed in year - 2010. - - rfkill controller switch "tpacpi_wwan_sw": refer to - Documentation/rfkill.txt for details. - - -EXPERIMENTAL: UWB ------------------ - -This feature is considered EXPERIMENTAL because it has not been extensively -tested and validated in various ThinkPad models yet. The feature may not -work as expected. USE WITH CAUTION! To use this feature, you need to supply -the experimental=1 parameter when loading the module. - -sysfs rfkill class: switch "tpacpi_uwb_sw" - -This feature exports an rfkill controller for the UWB device, if one is -present and enabled in the BIOS. - -Sysfs notes: - - rfkill controller switch "tpacpi_uwb_sw": refer to - Documentation/rfkill.txt for details. - -Adaptive keyboard ------------------ - -sysfs device attribute: adaptive_kbd_mode - -This sysfs attribute controls the keyboard "face" that will be shown on the -Lenovo X1 Carbon 2nd gen (2014)'s adaptive keyboard. The value can be read -and set. - -1 = Home mode -2 = Web-browser mode -3 = Web-conference mode -4 = Function mode -5 = Layflat mode - -For more details about which buttons will appear depending on the mode, please -review the laptop's user guide: -http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf - -Multiple Commands, Module Parameters ------------------------------------- - -Multiple commands can be written to the proc files in one shot by -separating them with commas, for example: - - echo enable,0xffff > /proc/acpi/ibm/hotkey - echo lcd_disable,crt_enable > /proc/acpi/ibm/video - -Commands can also be specified when loading the thinkpad-acpi module, -for example: - - modprobe thinkpad_acpi hotkey=enable,0xffff video=auto_disable - - -Enabling debugging output -------------------------- - -The module takes a debug parameter which can be used to selectively -enable various classes of debugging output, for example: - - modprobe thinkpad_acpi debug=0xffff - -will enable all debugging output classes. It takes a bitmask, so -to enable more than one output class, just add their values. - - Debug bitmask Description - 0x8000 Disclose PID of userspace programs - accessing some functions of the driver - 0x0001 Initialization and probing - 0x0002 Removal - 0x0004 RF Transmitter control (RFKILL) - (bluetooth, WWAN, UWB...) - 0x0008 HKEY event interface, hotkeys - 0x0010 Fan control - 0x0020 Backlight brightness - 0x0040 Audio mixer/volume control - -There is also a kernel build option to enable more debugging -information, which may be necessary to debug driver problems. - -The level of debugging information output by the driver can be changed -at runtime through sysfs, using the driver attribute debug_level. The -attribute takes the same bitmask as the debug module parameter above. - - -Force loading of module ------------------------ - -If thinkpad-acpi refuses to detect your ThinkPad, you can try to specify -the module parameter force_load=1. Regardless of whether this works or -not, please contact ibm-acpi-devel@lists.sourceforge.net with a report. - - -Sysfs interface changelog: - -0x000100: Initial sysfs support, as a single platform driver and - device. -0x000200: Hot key support for 32 hot keys, and radio slider switch - support. -0x010000: Hot keys are now handled by default over the input - layer, the radio switch generates input event EV_RADIO, - and the driver enables hot key handling by default in - the firmware. - -0x020000: ABI fix: added a separate hwmon platform device and - driver, which must be located by name (thinkpad) - and the hwmon class for libsensors4 (lm-sensors 3) - compatibility. Moved all hwmon attributes to this - new platform device. - -0x020100: Marker for thinkpad-acpi with hot key NVRAM polling - support. If you must, use it to know you should not - start a userspace NVRAM poller (allows to detect when - NVRAM is compiled out by the user because it is - unneeded/undesired in the first place). -0x020101: Marker for thinkpad-acpi with hot key NVRAM polling - and proper hotkey_mask semantics (version 8 of the - NVRAM polling patch). Some development snapshots of - 0.18 had an earlier version that did strange things - to hotkey_mask. - -0x020200: Add poll()/select() support to the following attributes: - hotkey_radio_sw, wakeup_hotunplug_complete, wakeup_reason - -0x020300: hotkey enable/disable support removed, attributes - hotkey_bios_enabled and hotkey_enable deprecated and - marked for removal. - -0x020400: Marker for 16 LEDs support. Also, LEDs that are known - to not exist in a given model are not registered with - the LED sysfs class anymore. - -0x020500: Updated hotkey driver, hotkey_mask is always available - and it is always able to disable hot keys. Very old - thinkpads are properly supported. hotkey_bios_mask - is deprecated and marked for removal. - -0x020600: Marker for backlight change event support. - -0x020700: Support for mute-only mixers. - Volume control in read-only mode by default. - Marker for ALSA mixer support. - -0x030000: Thermal and fan sysfs attributes were moved to the hwmon - device instead of being attached to the backing platform - device. diff --git a/Documentation/laptops/toshiba_haps.rst b/Documentation/laptops/toshiba_haps.rst new file mode 100644 index 000000000000..11dfc428c080 --- /dev/null +++ b/Documentation/laptops/toshiba_haps.rst @@ -0,0 +1,87 @@ +==================================== +Toshiba HDD Active Protection Sensor +==================================== + +Kernel driver: toshiba_haps + +Author: Azael Avalos + + +.. 0. Contents + + 1. Description + 2. Interface + 3. Accelerometer axes + 4. Supported devices + 5. Usage + + +1. Description +-------------- + +This driver provides support for the accelerometer found in various Toshiba +laptops, being called "Toshiba HDD Protection - Shock Sensor" officially, +and detects laptops automatically with this device. +On Windows, Toshiba provided software monitors this device and provides +automatic HDD protection (head unload) on sudden moves or harsh vibrations, +however, this driver only provides a notification via a sysfs file to let +userspace tools or daemons act accordingly, as well as providing a sysfs +file to set the desired protection level or sensor sensibility. + + +2. Interface +------------ + +This device comes with 3 methods: + +==== ===================================================================== +_STA Checks existence of the device, returning Zero if the device does not + exists or is not supported. +PTLV Sets the desired protection level. +RSSS Shuts down the HDD protection interface for a few seconds, + then restores normal operation. +==== ===================================================================== + +Note: + The presence of Solid State Drives (SSD) can make this driver to fail loading, + given the fact that such drives have no movable parts, and thus, not requiring + any "protection" as well as failing during the evaluation of the _STA method + found under this device. + + +3. Accelerometer axes +--------------------- + +This device does not report any axes, however, to query the sensor position +a couple HCI (Hardware Configuration Interface) calls (0x6D and 0xA6) are +provided to query such information, handled by the kernel module toshiba_acpi +since kernel version 3.15. + + +4. Supported devices +-------------------- + +This driver binds itself to the ACPI device TOS620A, and any Toshiba laptop +with this device is supported, given the fact that they have the presence of +conventional HDD and not only SSD, or a combination of both HDD and SSD. + + +5. Usage +-------- + +The sysfs files under /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/ are: + +================ ============================================================ +protection_level The protection_level is readable and writeable, and + provides a way to let userspace query the current protection + level, as well as set the desired protection level, the + available protection levels are: + + ============ ======= ========== ======== + 0 - Disabled 1 - Low 2 - Medium 3 - High + ============ ======= ========== ======== + +reset_protection The reset_protection entry is writeable only, being "1" + the only parameter it accepts, it is used to trigger + a reset of the protection interface. +================ ============================================================ diff --git a/Documentation/laptops/toshiba_haps.txt b/Documentation/laptops/toshiba_haps.txt deleted file mode 100644 index 0c1d88dedbde..000000000000 --- a/Documentation/laptops/toshiba_haps.txt +++ /dev/null @@ -1,76 +0,0 @@ -Kernel driver toshiba_haps -Toshiba HDD Active Protection Sensor -==================================== - -Author: Azael Avalos - - -0. Contents ------------ - -1. Description -2. Interface -3. Accelerometer axes -4. Supported devices -5. Usage - - -1. Description --------------- - -This driver provides support for the accelerometer found in various Toshiba -laptops, being called "Toshiba HDD Protection - Shock Sensor" officially, -and detects laptops automatically with this device. -On Windows, Toshiba provided software monitors this device and provides -automatic HDD protection (head unload) on sudden moves or harsh vibrations, -however, this driver only provides a notification via a sysfs file to let -userspace tools or daemons act accordingly, as well as providing a sysfs -file to set the desired protection level or sensor sensibility. - - -2. Interface ------------- - -This device comes with 3 methods: -_STA - Checks existence of the device, returning Zero if the device does not - exists or is not supported. -PTLV - Sets the desired protection level. -RSSS - Shuts down the HDD protection interface for a few seconds, - then restores normal operation. - -Note: -The presence of Solid State Drives (SSD) can make this driver to fail loading, -given the fact that such drives have no movable parts, and thus, not requiring -any "protection" as well as failing during the evaluation of the _STA method -found under this device. - - -3. Accelerometer axes ---------------------- - -This device does not report any axes, however, to query the sensor position -a couple HCI (Hardware Configuration Interface) calls (0x6D and 0xA6) are -provided to query such information, handled by the kernel module toshiba_acpi -since kernel version 3.15. - - -4. Supported devices --------------------- - -This driver binds itself to the ACPI device TOS620A, and any Toshiba laptop -with this device is supported, given the fact that they have the presence of -conventional HDD and not only SSD, or a combination of both HDD and SSD. - - -5. Usage --------- - -The sysfs files under /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/ are: -protection_level - The protection_level is readable and writeable, and - provides a way to let userspace query the current protection - level, as well as set the desired protection level, the - available protection levels are: - 0 - Disabled | 1 - Low | 2 - Medium | 3 - High -reset_protection - The reset_protection entry is writeable only, being "1" - the only parameter it accepts, it is used to trigger - a reset of the protection interface. diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 749322060f10..c5f0d44433a2 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -102,7 +102,7 @@ Changing this takes effect whenever an application requests memory. block_dump block_dump enables block I/O debugging when set to a nonzero value. More -information on block I/O debugging is in Documentation/laptops/laptop-mode.txt. +information on block I/O debugging is in Documentation/laptops/laptop-mode.rst. ============================================================== @@ -286,7 +286,7 @@ shared memory segment using hugetlb page. laptop_mode laptop_mode is a knob that controls "laptop mode". All the things that are -controlled by this knob are discussed in Documentation/laptops/laptop-mode.txt. +controlled by this knob are discussed in Documentation/laptops/laptop-mode.rst. ============================================================== diff --git a/MAINTAINERS b/MAINTAINERS index c30b52c9049a..3ee73751f56c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14888,7 +14888,7 @@ M: Mattia Dongili L: platform-driver-x86@vger.kernel.org W: http://www.linux.it/~malattia/wiki/index.php/Sony_drivers S: Maintained -F: Documentation/laptops/sony-laptop.txt +F: Documentation/laptops/sony-laptop.rst F: drivers/char/sonypi.c F: drivers/platform/x86/sony-laptop.c F: include/linux/sony-laptop.h diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 466ebd84ad17..bb734066075f 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -382,7 +382,7 @@ config SONYPI Device which can be found in many (all ?) Sony Vaio laptops. If you have one of those laptops, read - , and say Y or M here. + , and say Y or M here. To compile this driver as a module, choose M here: the module will be called sonypi. diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index cc29fe79c283..8f91d9ef8a7b 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -448,7 +448,7 @@ config SONY_LAPTOP screen brightness control, Fn keys and allows powering on/off some devices. - Read for more information. + Read for more information. config SONYPI_COMPAT bool "Sonypi compatibility" @@ -500,7 +500,7 @@ config THINKPAD_ACPI support for Fn-Fx key combinations, Bluetooth control, video output switching, ThinkLight control, UltraBay eject and more. For more information about this driver see - and + and . This driver was formerly known as ibm-acpi.