summaryrefslogtreecommitdiffstats
path: root/drivers/platform/x86/thinkpad_acpi.c
Commit message (Collapse)AuthorAgeFilesLines
* drivers/platform/x86/thinkpad_acpi.c: delete double assignmentJulia Lawall2010-11-241-1/+0
| | | | | | | | | | | | | | | | | | | Delete successive assignments to the same location. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression i; @@ *i = ...; i = ...; // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: avoid keymap pitfallHenrique de Moraes Holschuh2010-09-231-2/+3
| | | | | | | | | Change the code so that it will use the correct size for keymap entries. Do it in a way that makes it harder to screw it up in the future. Reported-by: Jaime Velasco Juan <jsagarribay@gmail.com> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: Add KEY_CAMERA (Fn-F6) for Lenovo keyboardsJens Taprogge2010-08-161-1/+1
| | | | | | | | | | On the T410s and most likely other current models, Fn-F6 is labeled as Camera/Headphone key. Report key presses as KEY_CAMERA. Signed-off-by: Jens Taprogge <jens.taprogge@taprogge.org> Acked-by: Jerone Young <jerone.young@canonical.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: add support for model-specific keymapsHenrique de Moraes Holschuh2010-08-161-18/+42
| | | | | | | | | | | Use the quirks engine to select model-specific keymaps, which makes it much easier to extend should we need it. Keycodes are based on the tables at http://www.thinkwiki.org/wiki/Default_meanings_of_special_keys. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: lock down size of hotkey keymapHenrique de Moraes Holschuh2010-08-161-4/+15
| | | | | | | | | Use a safer coding style for the hotkey keymap. This does not fix any problems, as the current code is correct. But it might help avoid mistakes in the future. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: untangle ACPI/vendor backlight selectionHenrique de Moraes Holschuh2010-08-161-22/+20
| | | | | | | | | | | | acpi_video_backlight_support() already tells us if ACPI is handling backlight control through the generic ACPI handle. It is better to just trust it. While at it, adjust down a printk priority, and test earlier for brightness_enable=0. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: find ACPI video device by synthetic HIDHenrique de Moraes Holschuh2010-08-161-40/+12
| | | | | | | | | | | | | | | | | | | The Linux ACPI core locates the ACPI video devices for us and marks them with ACPI_VIDEO_HID. Use that information to locate the video device instead of a half-baked hunt for _BCL. This uncouples the detection of the number of backlight brightness levels on ThinkPads from the ACPI paths in vid_handle. With this change, the driver should be able to always detect whether the ThinkPad uses a 8-level or 16-level brightness scale even on newer models for which the vid_handle paths have not been updated yet. It will skip deactivated devices in the ACPI device tree, which is a change in behaviour. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Matthew Garrett <mjg@redhat.com>
* X86 platform drivers: Remove EC dump from thinkpad_acpiThomas Renninger2010-08-031-73/+0
| | | | | | | | | | | | | | | | | There is a general interface for that now (provided by other patches in this patch series): /sys/kernel/debug/ec/*/io Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: platform-driver-x86@vger.kernel.org CC: Henrique de Moraes Holschuh <hmh@hmh.eng.br> CC: ibm-acpi-devel@lists.sourceforge.net Signed-off-by: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: document backlight level writeback at driver initHenrique de Moraes Holschuh2010-05-161-0/+4
| | | | | | | Document this, it is no fun to try to second guess why this sort of stuff is in place years after it was added... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: clean up ACPI handles handlingHenrique de Moraes Holschuh2010-05-161-9/+8
| | | | | | | | | | | 1. Remove <handle>_path, as its only user was already removed in a previous commit 2. Move all handle initialization, as well as <handle>_parent and <handle>_paths to __init.* sections. This reduces the driver's runtime footprint nicely. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: don't depend on led_path for led firmware type (v2)Henrique de Moraes Holschuh2010-05-161-19/+28
| | | | | | | | | | Don't depend on the contents of led_path to know which LED interface the firmware wants. This removes the only user of *_path for the thinkpad-acpi ACPI handlers, which will simplify future code. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: explain errors from acpi_install_notify_handlerHenrique de Moraes Holschuh2010-05-161-2/+2
| | | | | | | Log more human-friendly errors instead of numeric values when setup_acpi_notify() fails to install a notification handler. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: acpi_evalf fixesHenrique de Moraes Holschuh2010-05-161-4/+5
| | | | | | | | | | | Use acpi_format_exception() in acpi_evalf() instead of logging numeric errors. Also, when ACPICA returns an error, we should not be touching the return object, as it is invalid. In debug mode, acpi_evalf() callers would printk the returned crap (but fortunately, not use it). Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: detect EC node using its HID (v2)Henrique de Moraes Holschuh2010-05-161-12/+41
| | | | | | | | | Use the EC HID (PNP0C09) to locate its main node, instead of a static list. Suggested-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Matthew Garrett <mjg@redhat.com>
* thinkpad-acpi: disclose usertask for ALSA callbacksHenrique de Moraes Holschuh2010-05-161-0/+5
| | | | | | | Disclose the user task doing ALSA access when requested by the debug bitmask. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: fix brightness hotkey poll handlingHenrique de Moraes Holschuh2010-05-161-12/+24
| | | | | | Handle multiple brightness hotkey presses between two polling cycles. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: let other subdrivers know backlight level rangeHenrique de Moraes Holschuh2010-05-161-111/+140
| | | | | | | | | | | | | | | | Extract the backlight level range size detection from the brightness subdriver, and allow the other subdrivers access to that information. This also allows us to relocate some code to a more convenient place. The moved code was largerly unmodified, except for the return type of tpacpi_check_std_acpi_brightness_support(), which now is correctly marked as returning "unsigned int", and and two cosmetic fixes to make checkpatch.pl happy. Fixes for the NVRAM polling mode for the brightness hotkeys will need this. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: move greeting messages out of the first subdriver (v2)Henrique de Moraes Holschuh2010-05-161-29/+27
| | | | | | | | | | | Move the driver initial greetings out of the first subdriver, as we do a lot of other initialization before that point, and the initial greetings should go as soon as the driver decides that it should load. These greetings are not cosmetic, they make my life easier when users report bugs. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: fix volume/mute hotkey poll handlingHenrique de Moraes Holschuh2010-05-161-14/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | The hotkey polling code is supposed to generate hotkey messages as close to the way the IBM event-based volume hotkey firmware does as possible, i.e: * Pressing MUTE issues a mute hotkey event, even if already mute; * Pressing Volume up/down issues a volume up/down hotkey event, even if already at maximum or minumum volume; * The act of unmuting issues a volume up/down event, depending on which hotkey was used to unmute. Fix the code to do just that (mute handling was incorrect), and handle multiple hotkey presses between two polling cycles. The new code uses the volume_toggle bit in NVRAM only to detect repeated presses of the mute key and multiple presses of the volume keys trying to go past the end of the volume scale. This will work around a bug in recent Lenovo firmware (e.g. T400), which causes the firmware to not update the volume_toggle bit in certain situations. Reported-by: Yang Zhe <yangzhe1990@gmail.com> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: X100e quick fixesHenrique de Moraes Holschuh2010-05-161-0/+2
| | | | | | | | The X100e needs some quick fixes to work semi-right with this driver. There are much better ways to do this, but we can start with a quick update and do it properly later. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* thinkpad-acpi: constrain IBM-era support to IBM boxesHenrique de Moraes Holschuh2010-05-161-18/+39
| | | | | | | | | | | | | | Lenovo is playing around with its ACPI BIOS, and will end up reusing method names. Their memory is not nearly as long as thinkpad-acpi's... Secure most of the old IBM codepaths against running in a non-IBM box. This would happen on the Lenovo X100e in video_init(), for example. We would misdetect it as an ancient model 570 firmware. Also, refuse to load the driver if we cannot identify the vendor. No ACPI ThinkPad in existence lacks this information, AFAIK. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* backlight: Allow properties to be passed at registrationMatthew Garrett2010-03-161-5/+7
| | | | | | | | | | Values such as max_brightness should be set before backlights are registered, but the current API doesn't allow that. Add a parameter to backlight_device_register and update drivers to ensure that they set this correctly. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* Merge branch 'for-next' into for-linusJiri Kosina2010-03-081-2/+2
|\ | | | | | | | | | | | | | | | | Conflicts: Documentation/filesystems/proc.txt arch/arm/mach-u300/include/mach/debug-macro.S drivers/net/qlge/qlge_ethtool.c drivers/net/qlge/qlge_main.c drivers/net/typhoon.c
| * tree-wide: fix typos "ammount" -> "amount"Uwe Kleine-König2010-02-051-2/+2
| | | | | | | | | | Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | thinkpad-acpi: fix ALSA callback return statusHenrique de Moraes Holschuh2010-02-271-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clemens Ladisch reports that thinkpad-acpi improperly implements the ALSA API, and always returns 0 for success for the "put" callbacks while the API requires it to return "1" when the control value has been changed in the hardware/firmware. Rework the volume subdriver to be able to properly implement the ALSA API. Based on a patch by Clemens Ladisch <clemens@ladisch.de>. This fix is also needed on 2.6.33. Reported-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
* | thinkpad-acpi: lock down video output state accessHenrique de Moraes Holschuh2010-02-251-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the right combination of ThinkPad and X.org, just reading the video output control state is enough to hard-crash X.org. Until the day I somehow find out a model or BIOS cut date to not provide this feature to ThinkPads that can do video switching through X RandR, change permissions so that only processes with CAP_SYS_ADMIN can access any sort of video output control state. This bug could be considered a local DoS I suppose, as it allows any non-privledged local user to cause some versions of X.org to hard-crash some ThinkPads. Reported-by: Jidanni <jidanni@jidanni.org> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
* | thinkpad-acpi: fix bluetooth/wwan resumeHenrique de Moraes Holschuh2010-02-251-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Studying the DSDTs of various thinkpads, it looks like bit 3 of the argument to SBDC and SWAN is not "set radio to last state on resume". Rather, it seems to be "if this bit is set, enable radio on resume, otherwise disable it on resume". So, the proper way to prepare the radios for S3 suspend is: disable radio and clear bit 3 on the SBDC/SWAN call to to resume with radio disabled, and enable radio and set bit 3 on the SBDC/SWAN call to resume with the radio enabled. Also, for persistent devices, the rfkill core does not restore state, so we really need to get the firmware to do the right thing. We don't sync the radio state on suspend, instead we trust the BIOS to not do anything weird if we never touched the radio state since boot. Time will tell if that's a wise way of doing things... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
* | thinkpad-acpi: make driver events work in NVRAM poll modeHenrique de Moraes Holschuh2010-02-251-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thadeu Lima de Souza Cascardo reports this: Brightness notification does not work until the user writes to hotkey_mask attribute. That's because the polling thread will only run if hotkey_user_mask is set and someone is reading the input device or if hotkey_driver_mask is set. In this second case, this condition is not tested after the mask is changed, because the brightness and volume drivers are started after the hotkey drivers. Fix tpacpi_hotkey_driver_mask_set() to call hotkey_poll_setup(), so that the poller kthread will be started when needed. Reported-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Tested-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: stable@kernel.org
* | thinkpad-acpi: fix poll thread auto-startHenrique de Moraes Holschuh2010-02-251-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | The driver was not starting the NVRAM polling thread if the input device was bound immediately after registration. This fixes: http://bugzilla.kernel.org/show_bug.cgi?id=15118 Reported-by: Florian Zumbiehl <florz@florz.de> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
* | thinkpad-acpi: R52 brightness_mode has been confirmedHenrique de Moraes Holschuh2010-02-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | We can stop pestering users for confirmation of the brightness_mode default for firmware TP-76. While at it, add a few missing comments in that quirk table. Reported-by: Whoopie <whoopie79@gmx.net> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
* | thinkpad-acpi: document HKEY event 3006Henrique de Moraes Holschuh2010-02-251-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Event 0x3006 is used to help power management of the ODD in the UltraBay. The EC generates this event when the ODD eject button is pressed (even if the bay is powered down). Normally, Linux doesn't need this as we keep the SATA link powered up (which wastes power). The EC powers up the bay by itself when the ODD eject button is pressed, and the SATA PHY reports the hotplug. However, we could also power that SATA link down (and for that matter, also power down the Ultrabay) if the ODD is left idle for a while with no disk inside, and use event 0x3006 to know when we need that SATA link powered back up. For now, just stop asking for more information when event 0x3006 is seen, there is no point in pestering users about it anymore. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org
* | thinkpad-acpi: wrong thermal attribute_group removed in thermal_exit()Roel Kluin2010-02-161-1/+1
|/ | | | | | | | | | sysfs_remove_group() removed the wrong attribute_group for thermal_read_mode TPEC_8, ACPI_TMP07 and ACPI_UPDT Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* thinkpad-acpi: make volume subdriver optionalHenrique de Moraes Holschuh2009-12-261-0/+26
| | | | | | | | | | | | | | | | | | | | Allow the user to choose through Kconfig if the Console Audio Control interface (aka "volume subdriver") should be available or not. This not only saves some memory, but also allows the thinkpad-acpi driver to be built-in even if ALSA is modular when the console audio control interface is not wanted. This change fixes a build problem that is causing some annoyances, in a way that doesn't disable the entire driver on kernels without ALSA support. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ingo Molnar <mingo@elte.hu> Cc: Amerigo Wang <amwang@redhat.com> Cc: Helight Xu <helight.xu@gmail.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
* thinkpad-acpi: don't fail to load the entire module due to ALSA problemsHenrique de Moraes Holschuh2009-12-261-13/+18
| | | | | | | | | | | | | If we cannot create the ALSA mixer, it is a good reason to fail to load the volume subdriver, and not to fail to load the entire module. While at it, add more debugging messages, as the error paths are being used a lot more than I'd expect, and it is failing to set up the ALSA mixer on a number of ThinkPads. Reported-by: Peter Jordan <usernetwork@gmx.info> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* thinkpad-acpi: don't take the first ALSA slot by defaultHenrique de Moraes Holschuh2009-12-261-1/+1
| | | | | | | | | | | | We don't want to be the first soundcard. We don't want to shift other soundcards out of the way either, even if they load much later. Ask ALSA to (by default) load us in one of the last three slots. This can be overriden at will using the "index" parameter. Reported-by: Whoopie <whoopie79@gmx.net> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'thinkpad-2.6.33' into releaseLen Brown2009-12-161-279/+899
|\
| * thinkpad-acpi: bump version to 0.24Henrique de Moraes Holschuh2009-12-161-1/+1
| | | | | | | | | | Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: convert to seq_fileAlexey Dobriyan2009-12-151-153/+132
| | | | | | | | | | | | Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: basic ALSA mixer support (v2)Henrique de Moraes Holschuh2009-12-151-2/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the basic ALSA mixer functionality. The mixer is event-driven, and will work fine on IBM ThinkPads. I expect Lenovo ThinkPads will cause some trouble with the event interface. Heavily based on work by Lorne Applebaum <lorne.applebaum@gmail.com> and ideas from Matthew Garrett <mjg@redhat.com>. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: disable volume controlHenrique de Moraes Holschuh2009-12-151-5/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable volume control by default. It can be enabled at module load time by a module parameter (volume_control=1). The audio control mixer that thinkpad-acpi interacts with is fully functional without any drivers, and operated by hotkeys. The idea behind the console audio control is that the human operator is the only one that can interact with it. The ThinkVantage suite in Windows does not allow any software-based overrides, and only does OSD (on-screen-display) functions. The Linux driver will, with the addition of the ALSA interface, try to follow and enforce the ThinkVantage UI design: The user is supposed to use the keyboard hotkeys to interact with the console audio control. The kernel and the desktop environment is supposed to cooperate to provide proper user feedback through on-screen-display functions. Distros are urged to not to enable volume control by default. Enabling this must be a local admin's decision. This is the reason why there is no Kconfig option. Keep in mind that all ThinkPads have a normal, main mixer (AC97 or HDA) for regular software-based audio control. We are not talking about that mixer here. Advanced users are, of course, free to enable volume control and do as they please. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: support MUTE-only ThinkPadsHenrique de Moraes Holschuh2009-12-151-27/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lenovo removed the extra mixer since the T61 and thereabouts. Newer Lenovo models only have the mute gate function, and leave the volume control to the HDA mixer. Until a way to automatically query the firmware about its audio control capabilities is discovered (there might not be any), use a white/black list. We will likely need to ask T60 (old and new model) and Z60/Z61 users whether they have volume control to populate the black/white list. Meanwhile, provide a volume_capabilities parameter that can be used to override the defaults. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: volume subdriver rewriteHenrique de Moraes Holschuh2009-12-151-58/+282
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't trust the coupled EC writes and SMI calls the current volume control code does very much, although it is exactly what the IBM DSDTs seem to do (they never do more than a single step though). Change the driver to stop issuing SMIs, and just drive the EC directly to the desired level (DSDTs seem to confirm this will work even on very old models like the 570 and 600e/x). We checkpoint directly to NVRAM (this can be turned off) at suspend/shutdown/driver unload, which from what I can see in tbp, should also work on every ThinkPad. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: log initial state of rfkill switchesHenrique de Moraes Holschuh2009-12-151-1/+6
| | | | | | | | | | | | | | | | | | We already log the initial state of the hardware rfkill switch (WLSW), might as well log the state of the softswitches as well. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Josip Rodin <joy+kernel@entuzijast.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: sync input device EV_SW initial stateHenrique de Moraes Holschuh2009-12-151-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before we register the input device, sync the input layer EV_SW state through a call to input_report_switch(), to avoid issuing a gratuitous event for the initial state of these switches. This fixes some annoyances caused by the interaction with rfkill and EV_SW SW_RFKILL_ALL events. Reported-by: Kevin Locke <kevin@kevinlocke.name> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: use input_set_capabilityHenrique de Moraes Holschuh2009-12-091-9/+5
| | | | | | | | | | | | | | | | Use input_set_capability() instead of set_bit. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: log temperatures on termal alarm (v2)Henrique de Moraes Holschuh2009-12-091-12/+45
| | | | | | | | | | | | | | | | | | Log temperatures on any of the EC thermal alarms. It could be useful to help tracking down what is happening... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: expose module parametersHenrique de Moraes Holschuh2009-12-091-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | Export the normal (non-command) module paramenters as mode 0444, so that they will show up in sysfs. These parameters must not be changed at runtime as a rule, with very few exceptions. Reported-by: Ferenc Wagner <wferi@niif.hu> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: adopt input deviceHenrique de Moraes Holschuh2009-12-091-0/+1
| | | | | | | | | | | | | | | | | | Properly init the parent field of the input device. Thanks to Alan Jenkins, who noted this problem in a different driver. Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * thinkpad-acpi: silence bogus complain during rmmodHenrique de Moraes Holschuh2009-12-091-1/+2
| | | | | | | | | | | | | | | | | | | | Fix this bogus warning during module shutdown, when backlight event reporting is enabled: "thinkpad_acpi: required events 0x00018000 not enabled!" Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
OpenPOWER on IntegriCloud