user/sven/linux.git/include/linux/pm_runtime.h, branch v3.18.40

PM: Create PM workqueue if runtime PM is not configured too

2014-07-22T23:00:36Z

The PM workqueue is going to be used by ACPI PM notify handlers regardless of whether or not runtime PM is configured, so move it out of #ifdef CONFIG_PM_RUNTIME. Do that in three places in the ACPI device PM code. Signed-off-by: Rafael J. Wysocki

PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily

2014-05-16T21:15:44Z

Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to resume all runtime-suspended devices during system suspend, mostly because those devices may need to be reprogrammed due to different wakeup settings for system sleep and for runtime PM. For some devices, though, it's OK to remain in runtime suspend throughout a complete system suspend/resume cycle (if the device was in runtime suspend at the start of the cycle). We would like to do this whenever possible, to avoid the overhead of extra power-up and power-down events. However, problems may arise because the device's descendants may require it to be at full power at various points during the cycle. Therefore the most straightforward way to do this safely is if the device and all its descendants can remain runtime suspended until the complete stage of system resume. To this end, introduce a new device PM flag, power.direct_complete and modify the PM core to use that flag as follows. If the ->prepare() callback of a device returns a positive number, the PM core will regard that as an indication that it may leave the device runtime-suspended. It will then check if the system power transition in progress is a suspend (and not hibernation in particular) and if the device is, indeed, runtime-suspended. In that case, the PM core will set the device's power.direct_complete flag. Otherwise it will clear power.direct_complete for the device and it also will later clear it for the device's parent (if there's one). Next, the PM core will not invoke the ->suspend() ->suspend_late(), ->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume() callbacks for all devices having power.direct_complete set. It will invoke their ->complete() callbacks, however, and those callbacks are then responsible for resuming the devices as appropriate, if necessary. For example, in some cases they may need to queue up runtime resume requests for the devices using pm_request_resume(). Changelog partly based on an Alan Stern's description of the idea (http://marc.info/?l=linux-pm&m=139940466625569&w=2). Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern

PM: Add pm_runtime_suspend|resume_force functions

2014-03-01T23:18:15Z

This patch provides two new runtime PM helper functions which intend to be used from system suspend/resume callbacks, to make sure devices are put into low power state during system suspend and brought back to full power at system resume. The prerequisite is to have all levels of a device's runtime PM callbacks to be defined through the SET_PM_RUNTIME_PM_OPS macro, which means these are available for CONFIG_PM. By using the new runtime PM helper functions especially the two scenarios below will be addressed. 1) The PM core prevents .runtime_suspend callbacks from being invoked during system suspend. That means even for a runtime PM centric subsystem and driver, the device needs to be put into low power state from a system suspend callback. Otherwise it may very well be left in full power state (runtime resumed) while the system is suspended. By using the new helper functions, we make sure to walk the hierarchy of a device's power domain, subsystem and driver. 2) Subsystems and drivers need to cope with all the combinations of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. The two new helper functions smothly addresses this. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / Runtime: Implement the pm_generic_runtime functions for CONFIG_PM

2013-12-22T00:39:58Z

The pm_generic_runtime_suspend|resume functions were implemented within CONFIG_PM_RUNTIME. As we also may use runtime PM callbacks during system suspend, to put devices into low power state, we need to move the implementation of pm_generic_runtime_suspend|resume to CONFIG_PM. This change gives a power domain provision to invoke a platform driver's runtime PM callback from a power domain's system PM callback. This were earlier prevented by the platform bus, since it uses the pm_generic_runtime_suspend|resume functions as runtime PM callbacks. Cc: Kevin Hilman Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / Runtime: Rework the "runtime idle" helper routine

2013-06-03T19:49:52Z

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 Tested-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki Acked-by: Kevin Hilman Reviewed-by: Ulf Hansson Acked-by: Alan Stern

pm / runtime: introduce pm_runtime_set_memalloc_noio()

2013-02-24T01:50:16Z

Introduce the flag memalloc_noio in 'struct dev_pm_info' to help PM core to teach mm not allocating memory with GFP_KERNEL flag for avoiding probable deadlock. As explained in the comment, any GFP_KERNEL allocation inside runtime_resume() or runtime_suspend() on any one of device in the path from one block or network device to the root device in the device tree may cause deadlock, the introduced pm_runtime_set_memalloc_noio() sets or clears the flag on device in the path recursively. Signed-off-by: Ming Lei Cc: Minchan Kim Cc: Alan Stern Cc: Oliver Neukum Cc: Jiri Kosina Cc: Mel Gorman Cc: KAMEZAWA Hiroyuki Cc: Michal Hocko Cc: Ingo Molnar Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: Greg KH Cc: Jens Axboe Cc: "David S. Miller" Cc: Eric Dumazet Cc: David Decotigny Cc: Tom Herbert Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

PM / Runtime: Add new helper function: pm_runtime_active()

2013-01-25T23:39:12Z

This boolean function simply returns whether or not the runtime status of the device is 'active'. The typical scenario is driver calls pm_runtime_get firstly, then check pm_runtime_active in atomic environment. Also add entry to Documentation/power/runtime.txt Signed-off-by: Yanmin Zhang Signed-off-by: ShuoX Liu Signed-off-by: Rafael J. Wysocki

PM / Runtime: Remove device fields related to suspend time, v2

2012-05-01T19:28:38Z

After the previous changes in default_stop_ok() and default_power_down_ok() for PM domains, there are two fields in struct dev_pm_info that aren't necessary any more, suspend_time and max_time_suspended_ns. Remove those fields along with all of the code that accesses them, which simplifies the runtime PM framework quite a bit. Signed-off-by: Rafael J. Wysocki

PM / Runtime: Use device PM QoS constraints (v2)

2011-12-01T20:46:42Z

Make the runtime PM core use device PM QoS constraints to check if it is allowed to suspend a given device, so that an error code is returned if the device's own PM QoS constraint is negative or one of its children has already been suspended for too long. If this is not the case, the maximum estimated time the device is allowed to be suspended, computed as the minimum of the device's PM QoS constraint and the PM QoS constraints of its children (reduced by the difference between the current time and their suspend times) is stored in a new device's PM field power.max_time_suspended_ns that can be used by the device's subsystem or PM domain to decide whether or not to put the device into lower-power (and presumably higher-latency) states later (if the constraint is 0, which means "no constraint", the power.max_time_suspended_ns is set to -1). Additionally, the time of execution of the subsystem-level .runtime_suspend() callback for the device is recorded in the new power.suspend_time field for later use by the device's subsystem or PM domain along with power.max_time_suspended_ns (it also is used by the core code when the device's parent is suspended). Introduce a new helper function, pm_runtime_update_max_time_suspended(), allowing subsystems and PM domains (or device drivers) to update the power.max_time_suspended_ns field, for example after changing the power state of a suspended device. Signed-off-by: Rafael J. Wysocki

PM Sleep: Do not extend wakeup paths to devices with ignore_children set

2011-11-17T20:39:33Z

Commit 4ca46ff3e0d8c234cb40ebb6457653b59584426c (PM / Sleep: Mark devices involved in wakeup signaling during suspend) introduced the power.wakeup_path field in struct dev_pm_info to mark devices whose children are enabled to wake up the system from sleep states, so that power domains containing the parents that provide their children with wakeup power and/or relay their wakeup signals are not turned off. Unfortunately, that introduced a PM regression on SH7372 whose power consumption in the system "memory sleep" state increased as a result of it, because it prevented the power domain containing the I2C controller from being turned off when some children of that controller were enabled to wake up the system, although the controller was not necessary for them to signal wakeup. To fix this issue use the observation that devices whose power.ignore_children flag is set for runtime PM should be treated analogously during system suspend. Namely, they shouldn't be included in wakeup paths going through their children. Since the SH7372 I2C controller's power.ignore_children flag is set, doing so will restore the previous behavior of that SOC. Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman