aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* ACPI / hotplug / PCI: Drop handle field from struct acpiphp_bridgeRafael J. Wysocki2013-07-232-4/+2
| | | | | | | | | | The handle field in struct acpiphp_bridge is only used by acpiphp_enumerate_slots(), but in that function the local handle variable can be used instead, so make that happen and drop handle from struct acpiphp_bridge. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Drop handle field from struct acpiphp_funcRafael J. Wysocki2013-07-232-24/+36
| | | | | | | | | | | | | | | The ACPI handle stored in struct acpiphp_func is also stored in the struct acpiphp_context object containing it and it is trivial to get from a struct acpiphp_func pointer to the handle field of the outer struct acpiphp_context. Hence, the handle field of struct acpiphp_func is redundant, so drop it and provide a helper function, func_to_handle(), allowing it users to get the ACPI handle for the given struct acpiphp_func pointer. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Embed function struct into struct acpiphp_contextRafael J. Wysocki2013-07-232-30/+22
| | | | | | | | | | Since there has to be a struct acpiphp_func object for every struct acpiphp_context created by register_slot(), the struct acpiphp_func one can be embedded into the struct acpiphp_context one, which allows some code simplifications to be made. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Drop flags field from struct acpiphp_bridgeRafael J. Wysocki2013-07-232-14/+0
| | | | | | | | | | | | | | | The only bridge flag used by the ACPI-based PCI hotplug (ACPIPHP) code is BRIDGE_HAS_EJ0, but it is only used by the event handling function hotplug_event() and if that flag is set, the corresponding function flag FUNC_HAS_EJ0 is set as well, so that bridge flag is redundant. For this reason, drop BRIDGE_HAS_EJ0 and all code referring to it and since it is the only bridge flag defined, drop the flags field from struct acpiphp_bridge entirely. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Drop sun field from struct acpiphp_slotRafael J. Wysocki2013-07-234-10/+10
| | | | | | | | | | | | | | | If the slot unique number is passed as an additional argument to acpiphp_register_hotplug_slot(), the 'sun' field in struct acpiphp_slot is only used by ibm_[s|g]et_attention_status(), but then it's more efficient to store it in struct slot. Thus move the 'sun' field from struct acpiphp_slot to struct slot changing its data type to unsigned int in the process, and redefine acpiphp_register_hotplug_slot() to take the slot number as separate argument. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Register all devices under the given bridgeRafael J. Wysocki2013-07-232-157/+76
| | | | | | | | | | | | | | | | | | | | | | | | | Rework register_slot() to create a struct acpiphp_func object for every function it is called for and to create acpiphp slots for all of them. Although acpiphp_register_hotplug_slot() is only called for the slots whose functions are identified as "ejectable", so that user space can manipulate them, the ACPIPHP notify handler, handle_hotplug_event(), is now installed for all of the registered functions (that aren't dock stations) and hotplug events may be handled for all of them. As a result, essentially, all PCI bridges represented by objects in the ACPI namespace are now going to be "hotplug" bridges and that may affect resources allocation in general, although it shouldn't lead to problems. This allows the code to be simplified substantially and addresses the problem where bus check or device check notifications for some PCI bridges or devices are not handled, because those devices are not recognized as "ejectable" or there appear to be no "ejectable" devices under those bridges. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Refactor slot allocation code in register_slot()Rafael J. Wysocki2013-07-231-38/+36
| | | | | | | | | | | To make the code in register_slot() a bit easier to follow, change the way the slot allocation part is organized. Drop one local variable that's not used any more after that modification. This code change should not lead to any changes in behavior. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Drop func field from struct acpiphp_bridgeRafael J. Wysocki2013-07-232-4/+1
| | | | | | | | | Since the func pointer in struct acpiphp_context can always be used instead of the func pointer in struct acpiphp_bridge, drop the latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Merge hotplug event handling functionsRafael J. Wysocki2013-07-231-87/+65
| | | | | | | | | | | | | | | There are separate handling event functions for hotplug bridges and for hotplug functions, but they may be combined into one common hotplug event handling function which simplifies the code slightly. That also allows a theoretical bug to be dealt with which in principle may occur if a hotplug bridge is on a dock station, because in that case the bridge-specific notification should be used instead of the function-specific one, but the dock station always uses the latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Pass hotplug context objects to event handlersRafael J. Wysocki2013-07-231-8/+8
| | | | | | | | | | | Modify handle_hotplug_event() to pass the entire context object (instead of its fields individually) to work functions started by it. This change makes the subsequent consolidation of the event handling work functions a bit more straightforward. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Rework acpiphp_handle_to_bridge()Rafael J. Wysocki2013-07-231-9/+11
| | | | | | | | | | Using the hotplug context objects introduced previously rework the ACPI-based PCI hotplug (ACPIPHP) core code to get to acpiphp_bridge objects associated with hotplug bridges from those context objects rather than from the global list of hotplug bridges. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Unified notify handler for hotplug eventsRafael J. Wysocki2013-07-232-80/+53
| | | | | | | | | | | | | | | | | Using the hotplug context objects introduced previously rework the ACPI-based PCI hotplug (ACPIPHP) core code so that all notifications for ACPI device objects corresponding to the hotplug PCI devices are handled by one function, handle_hotplug_event(), which recognizes whether it has to handle a bridge or a function. In addition to code size reduction it allows some ugly pieces of code where notify handlers have to be uninstalled and installed again to go away. Moreover, it fixes a theoretically possible race between handle_hotplug_event() and free_bridge() tearing down data structures for the same handle. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Hotplug context objects for bridges and functionsRafael J. Wysocki2013-07-232-43/+146
| | | | | | | | | | | | | | | | | | | | When either a new hotplug bridge or a new hotplug function is added by the ACPI-based PCI hotplug (ACPIPHP) code, attach a context object to its ACPI handle to store hotplug-related information in it. To start with, put the handle's bridge and function pointers into that object. Count references to the context objects and drop them when they are not needed any more. First of all, this makes it possible to find out if the given bridge has been registered as a function already in a much more straightforward way and acpiphp_bridge_handle_to_function() can be dropped (Yay!). This also will allow some more simplifications to be made going forward. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Always return success after adding a functionRafael J. Wysocki2013-07-231-3/+2
| | | | | | | | | | | | | | | | When a new ACPIPHP function is added by register_slot() and the notify handler cannot be installed for it, register_slot() returns an error status without cleaning up, which causes the entire namespace walk in acpiphp_enumerate_slots() to be aborted, although it still may be possible to successfully install the function notify handler for other device objects under the given brigde. To address this issue make register_slot() return success after a new function has been added, even if the addition of the notify handler for it has failed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / hotplug / PCI: Consolidate acpiphp_enumerate_slots()Rafael J. Wysocki2013-07-231-47/+45
| | | | | | | | | | | | The acpiphp_enumerate_slots() function is now split into two parts, acpiphp_enumerate_slots() proper and init_bridge_misc() which is only called by the former. If these functions are combined, it is possible to make the code easier to follow and to clean up the error handling (to prevent memory leaks on error from happening in particular), so do that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / PCI: Make bus registration and unregistration symmetricRafael J. Wysocki2013-07-233-19/+17
| | | | | | | | | | | | | | | Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get the ACPI device handle they need from bus->bridge, it is not necessary to pass that handle to them as an argument. Drop the second argument of acpi_pci_slot_enumerate() and acpiphp_enumerate_slots(), rework them to obtain the ACPI handle from bus->bridge and make acpi_pci_add_bus() and acpi_pci_remove_bus() entirely symmetrical. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
* Merge branch 'acpi-cleanup'Rafael J. Wysocki2013-07-2315-564/+315
|\ | | | | | | Subsequent commits depend on the 'acpi-cleanup' material.
| * ACPI / dock: Drop unnecessary local variable from dock_add()Rafael J. Wysocki2013-07-151-5/+4
| | | | | | | | | | | | | | | | | | The local variable id in dock_add() is not necessary, so drop it. While we're at it, use an initializer to clear the local variable ds and drop the memset() used for this purpose. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / dock / PCI: Drop ACPI dock notifier chainRafael J. Wysocki2013-07-153-56/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only user of the ACPI dock notifier chain is the ACPI-based PCI hotplug (acpiphp) driver that uses it to carry out post-dock fixups needed by some systems with broken _DCK. However, it is not necessary to use a separate notifier chain for that, as it can be simply replaced with a new callback in struct acpi_dock_ops. For this reason, add a new .fixup() callback to struct acpi_dock_ops and make hotplug_dock_devices() execute it for all dock devices with hotplug operations registered. Accordingly, make acpiphp point that callback to the function carrying out the post-dock fixups and do not register a separate dock notifier for each device registering dock operations. Finally, drop the ACPI dock notifier chain that has no more users. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / dock: Do not leak memory on falilures to add a dock stationRafael J. Wysocki2013-07-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | The function creating and registering dock station objects, dock_add(), leaks memory if there's an error after it's walked the ACPI namespace calling find_dock_devices(), because it doesn't free the list of dependent devices it's just created in those cases. Fix that issue by adding the missing code to free the list of dependent devices on errors. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI: Drop ACPI bus notifier call chainRafael J. Wysocki2013-07-151-16/+0
| | | | | | | | | | | | | | There are no users of the ACPI bus notifier call chain, acpi_bus_notify_list, any more, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / dock: Rework the handling of notificationsRafael J. Wysocki2013-07-151-43/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI dock driver uses register_acpi_bus_notifier() which installs a notifier triggered globally for all system notifications. That first of all is inefficient, because the dock driver is only interested in notifications associated with the devices it handles, but it has to handle all system notifies for all devices. Moreover, it does that even if no docking stations are present in the system (CONFIG_ACPI_DOCK set is sufficient for that to happen). Besides, that is inconvenient, because it requires the driver to do extra work for each notification to find the target dock station object. For these reasons, rework the dock driver to install a notify handler individually for each dock station in the system using acpi_install_notify_handler(). This allows the dock station object to be passed directly to the notify handler and makes it possible to simplify the dock driver quite a bit. It also reduces the overhead related to the handling of all system notifies when CONFIG_ACPI_DOCK is set. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
| * ACPI / dock: Simplify dock_init_hotplug() and dock_release_hotplug()Rafael J. Wysocki2013-07-151-16/+8
| | | | | | | | | | | | | | | | | | Make dock_init_hotplug() and dock_release_hotplug() slightly simpler and move some checks in those functions to the code paths where they are needed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
| * ACPI / dock: Walk list in reverse order during removal of devicesRafael J. Wysocki2013-07-151-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | If there are indirect dependencies between devices in a dock station's dependent devices list, they may be broken if the devices are removed in the same order in which they have been added. For this reason, make the code in handle_eject_request() walk the list of dependent devices in reverse order. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
| * ACPI / dock: Rework and simplify find_dock_devices()Rafael J. Wysocki2013-07-151-18/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since acpi_walk_namespace() calls find_dock_devices() during tree pre-order visit, the latter doesn't need to add devices whose parents have _EJD pointing to the docking station to the list of that station's dependent devices, because those parents are going to be added to that list anyway and the removal of a parent will take care of the removal of its children in those cases. For this reason, rework find_dock_devices() to only call add_dock_dependent_device() for devices whose _EJD point directy to the docking station represented by its context argument and simplify it slightly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
| * ACPI / dock: Drop the hp_lock mutex from struct dock_stationRafael J. Wysocki2013-07-151-5/+0
| | | | | | | | | | | | | | | | | | The only existing user of the hp_lock mutex in struct dock_station, hotplug_dock_devices(), is always called under acpi_scan_lock and cannot race with another instance of itself, so drop the mutex which is not necessary. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI: simplify acpiphp driver with new helper functionsJiang Liu2013-07-151-22/+8
| | | | | | | | | | | | | | | | | | | | Use the new helper functions introduced previously to simplify the ACPI-based PCI hotplug (acpiphp) driver. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI: simplify dock driver with new helper functionsJiang Liu2013-07-151-110/+12
| | | | | | | | | | | | | | | | | | Use helper functions introduced previously to simplify the ACPI dock driver. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI: Export acpi_(bay)|(dock)_match() from scan.cJiang Liu2013-07-151-41/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | Functions acpi_dock_match() and acpi_bay_match() in scan.c can be shared with dock.c to reduce code duplication, so export them as global functions. Also add a new function acpi_ata_match() to check whether an ACPI device object represents an ATA device. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI: introduce two helper functions for _EJ0 and _LCKJiang Liu2013-07-152-25/+49
| | | | | | | | | | | | | | | | | | | | | | Introduce two helper functions, acpi_evaluate_ej0() and acpi_evaluate_lck(), that will execute the _EJ0 and _LCK ACPI control methods, respectively, and use them to simplify the ACPI scan code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI: introduce helper function acpi_execute_simple_method()Jiang Liu2013-07-157-45/+27
| | | | | | | | | | | | | | | | | | Introduce helper function acpi_execute_simple_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI: introduce helper function acpi_has_method()Jiang Liu2013-07-158-136/+77
| | | | | | | | | | | | | | | | | | Introduce helper function acpi_has_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / dock: simplify dock_create_acpi_device()Jiang Liu2013-07-151-6/+1
| | | | | | | | | | | | | | | | | | The return value of dock_create_acpi_device() is not used at all, so change its signature to return void and simplify the implementation of it. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / dock: mark initialization functions with __initJiang Liu2013-07-151-6/+6
| | | | | | | | | | | | | | | | Mark all initialization functions with __init to reduce runtime memory consumption. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / dock: drop redundant spin lock in dock station objectJiang Liu2013-07-151-12/+3
| | | | | | | | | | | | | | | | | | | | All dock station objects are created during initialization and don't change at runtime, so drop the redundant spin lock from struct dock_station. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / dock: avoid initializing acpi_dock_notifier_list multiple timesJiang Liu2013-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Function dock_add() will be called multiple times if there are multiple dock stations, which causes acpi_dock_notifier_list to be initialized multiple times. To avoid that, move the initialization of acpi_dock_notifier_list from dock_add() to acpi_dock_init(). [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge tag 'acpi-video-3.11' of ↵Linus Torvalds2013-07-215-27/+110
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI video support fixes from Rafael Wysocki: "I'm sending a separate pull request for this as it may be somewhat controversial. The breakage addressed here is not really new and the fixes may not satisfy all users of the affected systems, but we've had so much back and forth dance in this area over the last several weeks that I think it's time to actually make some progress. The source of the problem is that about a year ago we started to tell BIOSes that we're compatible with Windows 8, which we really need to do, because some systems shipping with Windows 8 are tested with it and nothing else, so if we tell their BIOSes that we aren't compatible with Windows 8, we expose our users to untested BIOS/AML code paths. However, as it turns out, some Windows 8-specific AML code paths are not tested either, because Windows 8 actually doesn't use the ACPI methods containing them, so if we declare Windows 8 compatibility and attempt to use those ACPI methods, things break. That occurs mostly in the backlight support area where in particular the _BCM and _BQC methods are plain unusable on some systems if the OS declares Windows 8 compatibility. [ The additional twist is that they actually become usable if the OS says it is not compatible with Windows 8, but that may cause problems to show up elsewhere ] Investigation carried out by Matthew Garrett indicates that what Windows 8 does about backlight is to leave backlight control up to individual graphics drivers. At least there's evidence that it does that if the Intel graphics driver is used, so we've decided to follow Windows 8 in that respect and allow i915 to control backlight (Daniel likes that part). The first commit from Aaron Lu makes ACPICA export the variable from which we can infer whether or not the BIOS believes that we are compatible with Windows 8. The second commit from Matthew Garrett prepares the ACPI video driver by making it initialize the ACPI backlight even if it is not going to be used afterward (that is needed for backlight control to work on Thinkpads). The third commit implements the actual workaround making i915 take over backlight control if the firmware thinks it's dealing with Windows 8 and is based on the work of multiple developers, including Matthew Garrett, Chun-Yi Lee, Seth Forshee, and Aaron Lu. The final commit from Aaron Lu makes us follow Windows 8 by informing the firmware through the _DOS method that it should not carry out automatic brightness changes, so that brightness can be controlled by GUI. Hopefully, this approach will allow us to avoid using blacklists of systems that should not declare Windows 8 compatibility just to avoid backlight control problems in the future. - Change from Aaron Lu makes ACPICA export a variable which can be used by driver code to determine whether or not the BIOS believes that we are compatible with Windows 8. - Change from Matthew Garrett makes the ACPI video driver initialize the ACPI backlight even if it is not going to be used afterward (that is needed for backlight control to work on Thinkpads). - Fix from Rafael J Wysocki implements Windows 8 backlight support workaround making i915 take over bakclight control if the firmware thinks it's dealing with Windows 8. Based on the work of multiple developers including Matthew Garrett, Chun-Yi Lee, Seth Forshee, and Aaron Lu. - Fix from Aaron Lu makes the kernel follow Windows 8 by informing the firmware through the _DOS method that it should not carry out automatic brightness changes, so that brightness can be controlled by GUI" * tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / video: no automatic brightness changes by win8-compatible firmware ACPI / video / i915: No ACPI backlight if firmware expects Windows 8 ACPI / video: Always call acpi_video_init_brightness() on init ACPICA: expose OSI version
| * | ACPI / video: no automatic brightness changes by win8-compatible firmwareAaron Lu2013-07-181-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting from win8, MS backlight control driver will set bit 2 of the parameter of control method _DOS, to inform firmware it should not perform any automatic brightness changes. This mostly affects hotkey notification deliver - if we do not set this bit, on hotkey press, firmware may choose to adjust brightness level instead of sending out notification and doing nothing. So this patch sets bit 2 when calling _DOS so that GUIs can show the notification window on hotkey press. This behavior change is only necessary for win8 systems. The MS document on win8 backlight control is here: http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305 References: https://bugzilla.kernel.org/show_bug.cgi?id=52951 References: https://bugzilla.kernel.org/show_bug.cgi?id=56711 Reported-by: Micael Dias <kam1kaz3@gmail.com> Reported-by: Dan Garton <dan.garton@gmail.com> Reported-by: Bob Ziuchkovski <bob.ziuchkovski@gmail.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI / video / i915: No ACPI backlight if firmware expects Windows 8Rafael J. Wysocki2013-07-184-9/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Matthew Garrett, "Windows 8 leaves backlight control up to individual graphics drivers rather than making ACPI calls itself. There's plenty of evidence to suggest that the Intel driver for Windows [8] doesn't use the ACPI interface, including the fact that it's broken on a bunch of machines when the OS claims to support Windows 8. The simplest thing to do appears to be to disable the ACPI backlight interface on these systems". There's a problem with that approach, however, because simply avoiding to register the ACPI backlight interface if the firmware calls _OSI for Windows 8 may not work in the following situations: (1) The ACPI backlight interface actually works on the given system and the i915 driver is not loaded (e.g. another graphics driver is used). (2) The ACPI backlight interface doesn't work on the given system, but there is a vendor platform driver that will register its own, equally broken, backlight interface if not prevented from doing so by the ACPI subsystem. Therefore we need to allow the ACPI backlight interface to be registered until the i915 driver is loaded which then will unregister it if the firmware has called _OSI for Windows 8 (or will register the ACPI video driver without backlight support if not already present). For this reason, introduce an alternative function for registering ACPI video, acpi_video_register_with_quirks(), that will check whether or not the ACPI video driver has already been registered and whether or not the backlight Windows 8 quirk has to be applied. If the quirk has to be applied, it will block the ACPI backlight support and either unregister the backlight interface if the ACPI video driver has already been registered, or register the ACPI video driver without the backlight interface otherwise. Make the i915 driver use acpi_video_register_with_quirks() instead of acpi_video_register() in i915_driver_load(). This change is based on earlier patches from Matthew Garrett, Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's. References: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Tested-by: Aaron Lu <aaron.lu@intel.com> Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Tested-by: Yves-Alexis Perez <corsac@debian.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
| * | ACPI / video: Always call acpi_video_init_brightness() on initMatthew Garrett2013-07-181-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have to call acpi_video_init_brightness() even if we're not going to initialise the backlight - Thinkpads seem to use this as the trigger for enabling ACPI notifications rather than handling it in firmware. [rjw: Drop the brightness object created by acpi_video_init_brightness() if we are not going to use it.] Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPICA: expose OSI versionAaron Lu2013-07-181-13/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Expose acpi_gbl_osi_data so that code outside of ACPICA can check the value of the last successfull _OSI call. The definitions for OSI versions are moved to actypes.h so that other components can access them too. Based on a patch from Matthew Garrett which in turn was based on an earlier patch from Seth Forshee. [rjw: Changelog] Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge tag 'staging-3.11-rc2' of ↵Linus Torvalds2013-07-20154-91615/+20
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging tree fixes from Greg KH: "Here are a few iio driver fixes for 3.11-rc2. They are still spread across drivers/iio and drivers/staging/iio so they are coming in through this tree. I've also removed the drivers/staging/csr/ driver as the developers who originally sent it to me have moved on to other companies, and CSR still will not send us the specs for the device, making the driver pretty much obsolete and impossible to fix up. Deleting it now prevents people from sending in lots of tiny codingsyle fixes that will never go anywhere. It also helps to offset the large lustre filesystem merge that happened in 3.11-rc1 in the overall 3.11.0 diffstat. :)" * tag 'staging-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: csr: remove driver iio: lps331ap: Fix wrong in_pressure_scale output value iio staging: fix lis3l02dq, read error handling staging:iio:ad7291: add missing .driver_module to struct iio_info iio: ti_am335x_adc: add missing .driver_module to struct iio_info iio: mxs-lradc: Remove useless check in read_raw iio: mxs-lradc: Fix misuse of iio->trig iio: inkern: fix iio_convert_raw_to_processed_unlocked iio: Fix iio_channel_has_info iio:trigger: device_unregister->device_del to avoid double free iio: dac: ad7303: fix error return code in ad7303_probe()
| * \ Merge tag 'iio-fixes-for-3.11a' of ↵Greg Kroah-Hartman2013-07-168-16/+20
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: The first round of IIO fixes for the 3.11 cycle. This set is larger than I would like, partly due to my lack of review time in the weeks before the merge window and partly because a couple of large drivers and the subsystem as a whole seem to be getting a lot more exposure and testing recently. 1) A long term bug in trigger handling gave a double free of the device. 2) Wrong return value handling means offsets are ignored in iio_convert_raw_to_processed_unlocked. 3) The iio_channel_has_info utility function was incorrectly updated during the recent info_mask split, this is now fixed. 4) mxs-lradc has a couple of little fixes. 5) A couple of missing .driver_module entries meant that drivers could be removed from underneath their users. 6) Error path fixes for ad7303 and lis3l02dq. 7) The scale value for presure in the lps331ap driver was out by a factor of 100.
| | * | iio: lps331ap: Fix wrong in_pressure_scale output valueJacek Anaszewski2013-07-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes improper in_pressure_scale output that is returned by the lps331ap barometer sensor driver. According to the documentation the pressure after applying the scale has to be expressed in kilopascal units. With erroneous implementation the scale value larger by two orders of magnitude is returned - 2441410 instead of 24414. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio staging: fix lis3l02dq, read error handlingPeter Meerwald2013-07-091-0/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | staging:iio:ad7291: add missing .driver_module to struct iio_infoWei Yongjun2013-07-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing .driver_module of struct iio_info. This prevents the module from being removed from underneath its users. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio: ti_am335x_adc: add missing .driver_module to struct iio_infoWei Yongjun2013-07-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing .driver_module of struct iio_info. This prevents the module from being removed from underneath its users. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio: mxs-lradc: Remove useless check in read_rawMarek Vasut2013-07-061-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The removed check in the read_raw implementation was always true, therefore remove it. This also fixes a bug, by closely inspecting the code, one can notice the iio_validate_scan_mask_onehot() will always return 1 and therefore the subsequent condition will always succeed, therefore making the mxs_lradc_read_raw() function always return -EINVAL; . Signed-off-by: Marek Vasut <marex@denx.de> Tested-by: Otavio Salvador <otavio@ossystems.com.br> Acked-by: Hector Palacios <hector.palacios@digi.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio: mxs-lradc: Fix misuse of iio->trigMarek Vasut2013-07-031-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The struct iio_dev .trig field is to be used only by the IIO core, the driver shall not fill this field. This fixes ugly crash when the driver is compiled as a module and the module is rmmod'd. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| | * | iio: inkern: fix iio_convert_raw_to_processed_unlockedAlexandre Belloni2013-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When reading IIO_CHAN_INFO_OFFSET, the return value of iio_channel_read() for success will be IIO_VAL*, checking for 0 is not correct. Without this fix the offset applied by iio drivers will be ignored when converting a raw value to one in appropriate base units (e.g mV) in a IIO client drivers that use iio_convert_raw_to_processed including iio-hwmon. Cc: <stable@vger.kernel.org> # 3.10.x Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>