summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/device_pm.c
Commit message (Collapse)AuthorAgeFilesLines
...
* | ACPI / PM: Fixed a typo in a commentHuang Rui2014-11-241-1/+1
|/ | | | | Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake upRafael J. Wysocki2014-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As reported by Dmitry, on some Chromebooks there are devices with corresponding ACPI objects and with unusual system wakeup configuration. Namely, they technically are wakeup-capable, but the wakeup is handled via a platform-specific out-of-band mechanism and the ACPI PM layer has no information on the wakeup capability. As a result, device_may_wakeup(dev) called from acpi_dev_suspend_late() returns 'true' for those devices, but the wakeup.flags.valid flag is unset for the corresponding ACPI device objects, so acpi_device_wakeup() reproducibly fails for them causing acpi_dev_suspend_late() to return an error code. The entire system suspend is then aborted and the machines in question cannot suspend at all. Address the problem by ignoring the device_may_wakeup(dev) return value in acpi_dev_suspend_late() if the ACPI companion of the device being handled has wakeup.flags.valid unset (in which case it is clear that the wakeup is supposed to be handled by other means). This fixes a regression introduced by commit a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain) as the affected systems could suspend and resume successfully before that commit. Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain) Reported-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-by: Dmitry Torokhov <dtor@chromium.org> Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'pm+acpi-3.18-rc2' of ↵Linus Torvalds2014-10-241-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management updates from Rafael Wysocki: "This is material that didn't make it to my 3.18-rc1 pull request for various reasons, mostly related to timing and travel (LinuxCon EU / LPC) plus a couple of fixes for recent bugs. The only really new thing here is the PM QoS class for memory bandwidth, but it is simple enough and users of it will be added in the next cycle. One major change in behavior is that platform devices enumerated by ACPI will use 32-bit DMA mask by default. Also included is an ACPICA update to a new upstream release, but that's mostly cleanups, changes in tools and similar. The rest is fixes and cleanups mostly. Specifics: - Fix for a recent PCI power management change that overlooked the fact that some IRQ chips might not be able to configure PCIe PME for system wakeup from Lucas Stach. - Fix for a bug introduced in 3.17 where acpi_device_wakeup() is called with a wrong ordering of arguments from Zhang Rui. - A bunch of intel_pstate driver fixes (all -stable candidates) from Dirk Brandewie, Gabriele Mazzotta and Pali Rohár. - Fixes for a rather long-standing problem with the OOM killer and the freezer that frozen processes killed by the OOM do not actually release any memory until they are thawed, so OOM-killing them is rather pointless, with a couple of cleanups on top (Michal Hocko, Cong Wang, Rafael J Wysocki). - ACPICA update to upstream release 20140926, inlcuding mostly cleanups reducing differences between the upstream ACPICA and the kernel code, tools changes (acpidump, acpiexec) and support for the _DDN object (Bob Moore, Lv Zheng). - New PM QoS class for memory bandwidth from Tomeu Vizoso. - Default 32-bit DMA mask for platform devices enumerated by ACPI (this change is mostly needed for some drivers development in progress targeted at 3.19) from Heikki Krogerus. - ACPI EC driver cleanups, mostly related to debugging, from Lv Zheng. - cpufreq-dt driver updates from Thomas Petazzoni. - powernv cpuidle driver update from Preeti U Murthy" * tag 'pm+acpi-3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (34 commits) intel_pstate: Correct BYT VID values. intel_pstate: Fix BYT frequency reporting intel_pstate: Don't lose sysfs settings during cpu offline cpufreq: intel_pstate: Reflect current no_turbo state correctly cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers cpufreq: intel_pstate: Fix setting max_perf_pct in performance policy PCI / PM: handle failure to enable wakeup on PCIe PME ACPI: invoke acpi_device_wakeup() with correct parameters PM / freezer: Clean up code after recent fixes PM: convert do_each_thread to for_each_process_thread OOM, PM: OOM killed task shouldn't escape PM suspend freezer: remove obsolete comments in __thaw_task() freezer: Do not freeze tasks killed by OOM killer ACPI / platform: provide default DMA mask cpuidle: powernv: Populate cpuidle state details by querying the device-tree cpufreq: cpufreq-dt: adjust message related to regulators cpufreq: cpufreq-dt: extend with platform_data cpufreq: allow driver-specific data ACPI / EC: Cleanup coding style. ACPI / EC: Refine event/query debugging messages. ...
| * Merge branches 'acpi-pm' and 'pm-genirq'Rafael J. Wysocki2014-10-231-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | * acpi-pm: ACPI: invoke acpi_device_wakeup() with correct parameters * pm-genirq: PCI / PM: handle failure to enable wakeup on PCIe PME
| | * ACPI: invoke acpi_device_wakeup() with correct parametersZhang Rui2014-10-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a bug that invokes acpi_device_wakeup() with wrong parameters. Fixes: f35cec255557 (ACPI / PM: Always enable wakeup GPEs when enabling device wakeup) Signed-off-by: Zhang Rui <rui.zhang@intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | Merge branch 'next' of ↵Linus Torvalds2014-10-241-0/+1
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management updates from Zhang Rui: "Sorry that I missed the merge window as there is a bug found in the last minute, and I have to fix it and wait for the code to be tested in linux-next tree for a few days. Now the buggy patch has been dropped entirely from my next branch. Thus I hope those changes can still be merged in 3.18-rc2 as most of them are platform thermal driver changes. Specifics: - introduce ACPI INT340X thermal drivers. Newer laptops and tablets may have thermal sensors and other devices with thermal control capabilities that are exposed for the OS to use via the ACPI INT340x device objects. Several drivers are introduced to expose the temperature information and cooling ability from these objects to user-space via the normal thermal framework. From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui. - introduce a new thermal governor, which just uses a hysteresis to switch abruptly on/off a cooling device. This governor can be used to control certain fan devices that can not be throttled but just switched on or off. From: Peter Feuerer. - introduce support for some new thermal interrupt functions on i.MX6SX, in IMX thermal driver. From: Anson, Huang. - introduce tracing support on thermal framework. From: Punit Agrawal. - small fixes in OF thermal and thermal step_wise governor" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits) Thermal: int340x thermal: select ACPI fan driver Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs Thermal: int340x_thermal: expose acpi thermal relationship tables Thermal: introduce int3403 thermal driver Thermal: introduce INT3402 thermal driver Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h ACPI / Fan: support INT3404 thermal device ACPI / Fan: add ACPI 4.0 style fan support ACPI / fan: convert to platform driver ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant ACPI / fan: remove no need check for device pointer ACPI / fan: remove unused macro Thermal: int3400 thermal: register to thermal framework Thermal: int3400 thermal: add capability to detect supporting UUIDs Thermal: introduce int3400 thermal driver ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package() ACPI: make acpi_create_platform_device() an external API thermal: step_wise: fix: Prevent from binary overflow when trend is dropping ACPI: introduce ACPI int340x thermal scan handler thermal: Added Bang-bang thermal governor ...
| * | ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelantAaron Lu2014-10-101-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | When we have the acpi_device pointer, there is no need to pass the device's handle to the acpi_bus_xxx_power functions to get/set/update the device's power state, instead, use the acpi_device_xxx_power functions directly. To make this happen for fan module, export acpi_device_update_power. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
* | ACPI / PM: Convert acpi_dev_pm_detach() into a static functionUlf Hansson2014-09-221-35/+34
| | | | | | | | | | | | | | | | | | | | The ->detach() callback for the PM domain has now been fully adopted, thus there no users left of the acpi_dev_pm_detach() API. This allow us to convert it into a static function. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / PM: Assign the ->detach() callback when attaching the PM domainUlf Hansson2014-09-221-0/+2
|/ | | | | | | | | As as preparation to simplify the detachment of devices from their PM domains, we assign the ->detach() callback to genpd_dev_pm_detach(). Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Use ACPI_COMPANION() instead of ACPI_HANDLE()Rafael J. Wysocki2014-07-231-12/+9
| | | | | | | | | | | | | The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to return the handle of the device's ACPI companion, so it is much more straightforward and efficient to use ACPI_COMPANION() directly to obtain the device's ACPI companion object instead of using ACPI_HANDLE() and acpi_bus_get_device() on the returned handle for the same thing. Do that in three places in the ACPI device PM code. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Always enable wakeup GPEs when enabling device wakeupRafael J. Wysocki2014-07-231-32/+17
| | | | | | | | | | | | | | | | | | | | | Wakeup GPEs are currently only enabled when setting up devices for remote wakeup at run time. During system-wide transitions they are enabled by ACPICA at the very last stage of suspend (before asking the BIOS to take over). Of course, that only works for system sleep states supported by ACPI, so in particular it doesn't work for the "freeze" sleep state. For this reason, modify the ACPI core device PM code to enable wakeup GPEs for devices when setting them up for wakeup regardless of whether that is remote wakeup at runtime or system wakeup. That allows the same device wakeup setup routine to be used for both runtime PM and system-wide PM and makes it possible to reduce code size quite a bit. This make ACPI-based PCI Wake-on-LAN work with the "freeze" sleep state on my venerable Toshiba Portege R500 and should help other systems too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Revork the handling of ACPI device wakeup notificationsRafael J. Wysocki2014-07-231-22/+58
| | | | | | | | | | | | | | | | | | | Since ACPI wakeup GPEs are going to be enabled during system suspend as well as for runtime wakeup by a subsequent patch and the same notify handlers will be used in both cases, rework the ACPI device wakeup notification framework so that the part specific to physical devices is always run asynchronously from the PM workqueue. This prevents runtime resume callbacks for those devices from being run during system suspend and resume which may not be appropriate, among other things. Also make ACPI device wakeup notification handling a bit more robust agaist subsequent removal of ACPI device objects, whould that ever happen, and create a wakeup source object for each ACPI device configured for wakeup so that wakeup notifications for those devices can wake up the system from the "freeze" sleep state. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Export rest of the subsys PM callbacksHeikki Krogerus2014-05-201-1/+4
| | | | | | | | No reason for excluding the remaining ones. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [rjw: Rebased and exported the new acpi_subsys_complete() too.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspendRafael J. Wysocki2014-05-201-7/+36
| | | | | | | | Rework the ACPI PM domain's PM callbacks to avoid resuming devices during system suspend (in order to modify their wakeup settings etc.) if that isn't necessary. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Resume runtime-suspended devices later during system suspendRafael J. Wysocki2014-03-041-3/+38
| | | | | | | | | | | | | | | | | | | | | | | Runtime-suspended devices are resumed during system suspend by acpi_subsys_prepare() for two reasons: First, because they may need to be reprogrammed in order to change their wakeup settings and, second, because they may need to be operatonal for their children to be successfully suspended. That is a problem, though, if there are many runtime-suspended devices that need to be resumed this way during system suspend, because the .prepare() PM callbacks of devices are executed sequentially and the times taken by them accumulate, which may increase the total system suspend time quite a bit. For this reason, move the resume of runtime-suspended devices up to the next phase of device suspend (during system suspend), except for the ones that have power.ignore_children set. The exception is made, because the devices with power.ignore_children set may still be necessary for their children to be successfully suspended (during system suspend) and they won't be resumed automatically as a result of the runtime resume of their children. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*-. Merge branches 'acpi-processor', 'acpi-hotplug', 'acpi-init', 'acpi-pm' and ↵Rafael J. Wysocki2014-01-291-18/+6
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'acpica' * acpi-processor: ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed to get CPU APIC ID" ACPI / processor: Return specific error value when mapping lapic id * acpi-hotplug: ACPI / scan: Clear match_driver flag in acpi_bus_trim() * acpi-init: ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API * acpi-pm: ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices * acpica: ACPICA: Remove bool usage from ACPICA.
| | * ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devicesRafael J. Wysocki2014-01-271-18/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | The ACPI device PM code in device_pm.c uses a special function, acpi_dev_pm_get_node(), to obtain an ACPI companion object of a given device. However, that is not necessary any more after recent changes that introduced the ACPI_COMPANION() macro serving exactly the same purpose, but working in a much more straightforward way. For this reason, drop acpi_dev_pm_get_node() and use ACPI_COMPANION() instead of it everywhere. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* / ACPI / scan: Add acpi_device objects for all device nodes in the namespaceRafael J. Wysocki2013-11-221-4/+18
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify the ACPI namespace scanning code to register a struct acpi_device object for every namespace node representing a device, processor and so on, even if the device represented by that namespace node is reported to be not present and not functional by _STA. There are multiple reasons to do that. First of all, it avoids quite a lot of overhead when struct acpi_device objects are deleted every time acpi_bus_trim() is run and then added again by a subsequent acpi_bus_scan() for the same scope, although the namespace objects they correspond to stay in memory all the time (which always is the case on a vast majority of systems). Second, it will allow user space to see that there are namespace nodes representing devices that are not present at the moment and may be added to the system. It will also allow user space to evaluate _SUN for those nodes to check what physical slots the "missing" devices may be put into and it will make sense to add a sysfs attribute for _STA evaluation after this change (that will be useful for thermal management on some systems). Next, it will help to consolidate the ACPI hotplug handling among subsystems by making it possible to store hotplug-related information in struct acpi_device objects in a standard common way. Finally, it will help to avoid a race condition related to the deletion of ACPI namespace nodes. Namely, namespace nodes may be deleted as a result of a table unload triggered by _EJ0 or _DCK. If a hotplug notification for one of those nodes is triggered right before the deletion and it executes a hotplug callback via acpi_hotplug_execute(), the ACPI handle passed to that callback may be stale when the callback actually runs. One way to work around that is to always pass struct acpi_device pointers to hotplug callbacks after doing a get_device() on the objects in question which eliminates the use-after-free possibility (the ACPI handles in those objects are invalidated by acpi_scan_drop_device(), so they will trigger ACPICA errors on attempts to use them). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI: Eliminate the DEVICE_ACPI_HANDLE() macroRafael J. Wysocki2013-11-141-4/+4
| | | | | | | | | Since DEVICE_ACPI_HANDLE() is now literally identical to ACPI_HANDLE(), replace it with the latter everywhere and drop its definition from include/acpi.h. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_nodeRafael J. Wysocki2013-11-141-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify struct acpi_dev_node to contain a pointer to struct acpi_device associated with the given device object (that is, its ACPI companion device) instead of an ACPI handle corresponding to it. Introduce two new macros for manipulating that pointer in a CONFIG_ACPI-safe way, ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the ACPI_HANDLE() macro to take the above changes into account. Drop the ACPI_HANDLE_SET() macro entirely and rework its users to use ACPI_COMPANION_SET() instead. For some of them who used to pass the result of acpi_get_child() directly to ACPI_HANDLE_SET() introduce a helper routine acpi_preset_companion() doing an equivalent thing. The main motivation for doing this is that there are things represented by struct acpi_device objects that don't have valid ACPI handles (so called fixed ACPI hardware features, such as power and sleep buttons) and we would like to create platform device objects for them and "glue" them to their ACPI companions in the usual way (which currently is impossible due to the lack of valid ACPI handles). However, there are more reasons why it may be useful. First, struct acpi_device pointers allow of much better type checking than void pointers which are ACPI handles, so it should be more difficult to write buggy code using modified struct acpi_dev_node and the new macros. Second, the change should help to reduce (over time) the number of places in which the result of ACPI_HANDLE() is passed to acpi_bus_get_device() in order to obtain a pointer to the struct acpi_device associated with the given "physical" device, because now that pointer is returned by ACPI_COMPANION() directly. Finally, the change should make it easier to write generic code that will build both for CONFIG_ACPI set and unset without adding explicit compiler directives to it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
* Merge branch 'acpi-pm'Rafael J. Wysocki2013-10-281-3/+5
|\ | | | | | | | | | | | | * acpi-pm: spi: attach/detach SPI device to the ACPI power domain i2c: attach/detach I2C client device to the ACPI power domain ACPI / PM: allow child devices to ignore parent power state
| * ACPI / PM: allow child devices to ignore parent power stateMika Westerberg2013-10-111-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some serial buses like I2C and SPI don't require that the parent device is in D0 before any of its children transitions to D0, but instead the parent device can control its own power independently from the children. This does not follow the ACPI specification as it requires the parent to be powered on before its children. However, Windows seems to ignore this requirement so I think we can do the same in Linux. Implement this by adding a new power flag 'ignore_parent' to struct acpi_device. If this flag is set the ACPI core ignores checking of the parent device power state when the device is powered on/off. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / PM: Drop two functions that are not used any moreRafael J. Wysocki2013-10-171-56/+0
|/ | | | | | | | | | | | Two functions defined in device_pm.c, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), have no callers and may be dropped, so drop them. Moreover, they are the only functions adding entries to and removing entries from the power_dependent list in struct acpi_device, so drop that list too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Add state information to error message in acpi_device_set_power()Aaron Lu2013-08-031-1/+3
| | | | | | | | | | | The state information can be useful to know what the problem is when an error message about a device can not being set to a higher power state than its parent appeared, so this patch adds such state information for both the target state of the device and the current state of its parent. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Remove redundant power manageable check from acpi_bus_set_power()Aaron Lu2013-07-311-7/+0
| | | | | | | | | Now that acpi_device_set_power() checks whether or not the given device is power manageable, it is not necessary to do this check in acpi_bus_set_power() any more, so remove it. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Make messages in acpi_device_set_power() print device namesRafael J. Wysocki2013-07-301-12/+10
| | | | | | | | | | | | | Modify acpi_device_set_power() so that diagnostic messages printed by it to the kernel log always contain the name of the device concerned to make it possible to identify the device that triggered the message if need be. Also replace printk(KERN_WARNING ) with dev_warn() everywhere in that function. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
* ACPI / PM: Only set power states of devices that are power manageableRafael J. Wysocki2013-07-301-1/+2
| | | | | | | | | | | | Make acpi_device_set_power() check if the given device is power manageable before checking if the given power state is valid for that device. Otherwise it will print that "Device does not support" that power state into the kernel log, which may not make sense for some power states (D0 and D3cold are supported by all devices by definition). Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Fix corner case in acpi_bus_update_power()Rafael J. Wysocki2013-07-041-5/+18
| | | | | | | | | | | | | | | | | | | | | | The role of acpi_bus_update_power() is to update the given ACPI device object's power.state field to reflect the current physical state of the device (as inferred from the configuration of power resources and _PSC, if available). For this purpose it calls acpi_device_set_power() that should update the power resources' reference counters and set power.state as appropriate. However, that doesn't work if the "new" state is D1, D2 or D3hot and the the current value of power.state means D3cold, because in that case acpi_device_set_power() will refuse to transition the device from D3cold to non-D0. To address this problem, make acpi_bus_update_power() call acpi_power_transition() directly to update the power resources' reference counters and only use acpi_device_set_power() to put the device into D0 if the current physical state of it cannot be determined. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
* Merge branch 'acpi-pm'Rafael J. Wysocki2013-06-291-4/+8
|\ | | | | | | | | * acpi-pm: ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()
| * ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()Rafael J. Wysocki2013-06-281-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit fa1675b (ACPI / PM: Rework and clean up acpi_dev_pm_get_state()) a NULL pointer dereference will take place if NULL is passed to acpi_pm_device_sleep_state() as the second argument. Fix that by avoiding to use the pointer that may be NULL until it's necessary to store a return value at the location pointed to by it (if not NULL). Reported-and-tested-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'pm-assorted'Rafael J. Wysocki2013-06-281-1/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pm-assorted: PM / QoS: Add pm_qos and dev_pm_qos to events-power.txt PM / QoS: Add dev_pm_qos_request tracepoints PM / QoS: Add pm_qos_request tracepoints PM / QoS: Add pm_qos_update_target/flags tracepoints PM / QoS: Update Documentation/power/pm_qos_interface.txt PM / Sleep: Print last wakeup source on failed wakeup_count write PM / QoS: correct the valid range of pm_qos_class PM / wakeup: Adjust messaging for wake events during suspend PM / Runtime: Update .runtime_idle() callback documentation PM / Runtime: Rework the "runtime idle" helper routine PM / Hibernate: print physical addresses consistently with other parts of kernel
| * | PM / Runtime: Rework the "runtime idle" helper routineRafael J. Wysocki2013-06-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "runtime idle" helper routine, rpm_idle(), currently ignores return values from .runtime_idle() callbacks executed by it. However, it turns out that many subsystems use pm_generic_runtime_idle() which checks the return value of the driver's callback and executes pm_runtime_suspend() for the device unless that value is not 0. If that logic is moved to rpm_idle() instead, pm_generic_runtime_idle() can be dropped and its users will not need any .runtime_idle() callbacks any more. Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and ata_port_runtime_idle(), respectively, as well as a few drivers' ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has been returned by the .runtime_idle() callback executed by it. To reduce overall code bloat, make the changes described above. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Kevin Hilman <khilman@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu>
* | | Merge branch 'acpi-pm'Rafael J. Wysocki2013-06-281-70/+95
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | * acpi-pm: ACPI / PM: Rework and clean up acpi_dev_pm_get_state() ACPI / PM: Replace ACPI_STATE_D3 with ACPI_STATE_D3_COLD in device_pm.c ACPI / PM: Rename function acpi_device_power_state() and make it static ACPI / PM: acpi_processor_suspend() can be static xen / ACPI / sleep: Register an acpi_suspend_lowlevel callback. x86 / ACPI / sleep: Provide registration for acpi_suspend_lowlevel.
| * | ACPI / PM: Rework and clean up acpi_dev_pm_get_state()Rafael J. Wysocki2013-06-191-66/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The acpi_dev_pm_get_state() function defined in device_pm.c is quite convoluted, which isn't really necessary, and it doesn't validate the values returned by the ACPI methods executed by it appropriately. To address these shortcomings modify it in the following way. (1) Make its return value only mean whether or not it succeeded and pass the device power states determined by it through pointers. (2) Drop the d_max_in argument, used by only one of its callers, from it, and move the code related to d_max_in into that caller, acpi_pm_device_sleep_state(). (3) Make it always check the return value of acpi_evaluate_integer() and handle failures as appropriate. Moreover, make it check if the values returned by the executed ACPI methods are not out of range. (4) Make it check if the values returned by the executed ACPI methods represent valid power states of the given device and handle situations in which that's not the case gracefully. Also update the kerneldoc comments of acpi_dev_pm_get_state() and acpi_pm_device_sleep_state() to reflect the code changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI / PM: Replace ACPI_STATE_D3 with ACPI_STATE_D3_COLD in device_pm.cRafael J. Wysocki2013-06-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The two symbols ACPI_STATE_D3 and ACPI_STATE_D3_COLD actually represent the same number (4), but ACPI_STATE_D3 is slightly ambigugous, because it may not be clear that it really means D3cold and not D3hot at first sight. Remove that ambiguity from drivers/acpi/device_pm.c by making it use ACPI_STATE_D3_COLD everywhere instead of ACPI_STATE_D3. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI / PM: Rename function acpi_device_power_state() and make it staticRafael J. Wysocki2013-06-191-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a name clash between function acpi_device_power_state() defined in drivers/acpi/device_pm.c and structure type acpi_device_power_state defined in include/acpi/acpi_bus.h, which may be resolved by renaming the function. Additionally, that funtion may be made static, because it is not used anywhere outside of the file it is defined in. Rename acpi_device_power_state() to acpi_dev_pm_get_state(), which better reflects its purpose, and make it static. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | ACPI / LPSS: Power up LPSS devices during enumerationRafael J. Wysocki2013-06-201-0/+20
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* / ACPI / PM: Do not execute _PS0 for devices without _PSC during initializationRafael J. Wysocki2013-06-071-4/+6
|/ | | | | | | | | | | | | | Commit b378549 (ACPI / PM: Do not power manage devices in unknown initial states) added code to force devices without _PSC, but having _PS0 defined in the ACPI namespace, into ACPI power state D0 by executing _PS0 for them. That turned out to break Toshiba P870-303, however, so revert that code. References: https://bugzilla.kernel.org/show_bug.cgi?id=58201 Reported-and-tested-by: Jerome Cantenot <jerome.cantenot@gmail.com> Tracked-down-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Allow device power states to be used for CONFIG_PM unsetRafael J. Wysocki2013-05-221-62/+64
| | | | | | | | | | | | | | | | | | | | Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of the functions defined in there are replaced with static inline stubs if that option is unset. However, CONFIG_PM means, roughly, "runtime PM or suspend/hibernation support" and some of those functions are useful regardless of that. For example, they are used by the ACPI fan driver for controlling fans and acpi_device_set_power() is called during device removal. Moreover, device initialization may depend on setting device power states properly. For these reasons, make the routines manipulating ACPI device power states defined in drivers/acpi/device_pm.c available for CONFIG_PM unset too. Reported-by: Zhang Rui <rui.zhang@intel.com> Reported-and-tested-by: Michel Lespinasse <walken@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
* ACPI / PM: Fix potential problem in acpi_device_get_power()Rafael J. Wysocki2013-03-251-15/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Theoretically, in some situations acpi_device_get_power() may return an incorrect result, because the settings of the power resources depended on by the device may indicate a power state shallower than the actual power state of the device. Say that two devices, A and B, depend on two power resources, X and Y, in such a way that _PR0 for both A and B list both X and Y and _PR3 for both A and B list power resource Y alone. Also suppose that _PS0 and _PS3 are present for both A and B. Then, if devices A and B are initially in D0, power resources X and Y are initially "on" and their reference counters are equal to 2. To put device A into power state D3hot the kernel will decrement the reference counter of power resource X, but that power resource won't be turned off, because it is still in use by device B (its reference counter is equal to 1). Next, _PS3 will be executed for device A. Afterward the configuration of the power resources will indicate that device A is in power state D0 (both X and Y are "on"), but in fact it is in D3hot (because _PS3 has been executed for it). In that situation, if acpi_device_get_power() is called to get the power state of device A, it will first execute _PSC for it which should return 3. That will cause acpi_device_get_power() to run acpi_power_get_inferred_state() for device A and the resultant power state will be D0, which is incorrect. To fix that change acpi_device_get_power() to first execute acpi_power_get_inferred_state() for the given device (if it depends on power resources) and to evaluate _PSC for it subsequently, so that the result inferred from the power resources configuration can be amended by the _PSC return value. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
* ACPI / PM: Handle missing _PSC in acpi_bus_update_power()Rafael J. Wysocki2013-02-031-0/+3
| | | | | | | | | | | | | | If _PS0 is defined for an ACPI device node, but _PSC isn't and the device node doesn't use power resources for power management, acpi_bus_update_power() will fail to update the power state of it, because acpi_device_get_power() returns ACPI_STATE_UNKNOWN in that case. To handle that situation make acpi_bus_update_power() follow acpi_bus_init_power() and try to force the given device node into power state D0. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Do not power manage devices in unknown initial statesRafael J. Wysocki2013-02-011-0/+6
| | | | | | | | | | | | | | | | | | In general, for ACPI device power management to work, the initial power states of devices must be known (otherwise, we wouldn't be able to keep track of power resources, for example). Hence, if it is impossible to determine the initial ACPI power states of some devices, they can't be regarded as power-manageable using ACPI. For this reason, modify acpi_bus_get_power_flags() to clear the power_manageable flag if acpi_bus_init_power() fails and add some extra fallback code to acpi_bus_init_power() to cover broken BIOSes that provide _PS0/_PS3 without _PSC for some devices. Verified to work on my HP nx6325 that has this problem. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Peter Wu <lekensteyn@gmail.com>
* ACPI / PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.cYasuaki Ishimatsu2013-01-311-3/+3
| | | | | | | | | | acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_FAILURE() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Fix device power state value after transitions to D3coldRafael J. Wysocki2013-01-221-2/+5
| | | | | | | | | | | | | | When a transition to the D3cold power state is requested, acpi_device_set_power() first carries out a transition to D3hot and then turns off the device's power resources. However, it fails to update the device's power.state field appropriately and D3hot is stored in it as a result. Fix this, but make sure that the device's power state will be D3hot if its power resources cannot be turned off in the final step. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Use string "D3cold" to represent ACPI_STATE_D3_COLDRafael J. Wysocki2013-01-221-1/+1
| | | | | | | | Make acpi_power_state_string() return "D3cold" as the string representation of ACPI power state D3cold instead of "D3" returned currently, which is confusing. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Always evaluate _PSn after setting power resourcesRafael J. Wysocki2013-01-221-29/+17
| | | | | | | | | | | | | | | | | | | | | The ACPI specitication (ACPI 5, Sections 7.2.8 - 7.2.11) requires that the _PSn (n = 0..3) method, if present, be executed after the power resources for the given device power state have been set appropriately. However, acpi_device_set_power() does that only if the new power state is going to be higher-power (lower-number) than the power state the device is in already. Otherwise, the ordering is reverse to protect against situations in which _PSn might access device registers unavailable after configuring the power resources for power state Dn (D3 meaning D3hot). Such situations are very unlikely to happen, though, and _PSn may actually be implemented with the assumption that power resources have been configured for power state Dn in advance, so change the code to follow the specification literally. This change was previously porposed in a different form by Lv Zheng. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Introduce helper for executing _PSn methodsRafael J. Wysocki2013-01-221-28/+23
| | | | | | | | To reduce code duplication between acpi_device_set_power() and acpi_bus_init_power(), introduce a new helper function for executing ACPI devices' _PSn (n = 0..3) methods, acpi_dev_pm_explicit_set(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Make acpi_bus_init_power() more robustRafael J. Wysocki2013-01-221-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | The ACPI specification requires the _PSC method to be present under a device object if its power state cannot be inferred from the states of power resources used by it (ACPI 5, Section 7.6.2). However, it also requires that (for power states D0-D2 and D3hot) if the _PSn (n = 0, 1, 2, 3) method is present under the device object, it also must be executed after the power resources have been set appropriately for the device to go into power state Dn (D3 means D3hot in this case). Thus it is not clear from the specification whether or not the _PSn method should be executed if the initial configuraion of power resources used by the device indicates power state Dn and the _PSC method is not present. The current implementation of acpi_bus_init_power() is based on the assumption that it should not be necessary to execute _PSn in the above situation, but experience shows that in fact that assumption need not be satisfied. For this reason, make acpi_bus_init_power() always execute _PSn if the initial configuration of device power resources indicates power state Dn. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: remove leading whitespace from #ifdefMika Westerberg2013-01-191-1/+1
| | | | | | | | It is there probably due to an accident, get rid of it so that the format is consistent across the file. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Move device power management functions to device_pm.cRafael J. Wysocki2013-01-191-0/+288
| | | | | | | Move ACPI device power management functions from drivers/acpi/bus.c to drivers/acpi/device_pm.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 22:20:18 +0000