kernel/linux.git/include/linux/pm.h, branch v3.16.61

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

2014-05-16T21:15:44+00:00

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

Merge branches 'pm-runtime' and 'pm-sleep'

2014-03-20T12:25:54+00:00

* pm-runtime: PM / Runtime: Update runtime_idle() documentation for return value meaning * pm-sleep: PM / sleep: Correct whitespace errors in PM: Add missing "freeze" state PM / Hibernate: Spelling s/anonymouns/anonymous/ PM / Runtime: Add missing "it" in comment PM / suspend: Remove unnecessary !! PCI / PM: Resume runtime-suspended devices later during system suspend ACPI / PM: Resume runtime-suspended devices later during system suspend PM / sleep: Set pm_generic functions to NULL for !CONFIG_PM_SLEEP PM: fix typo in comment PM / hibernate: use name_to_dev_t to parse resume PM / wakeup: Include appropriate header file in kernel/power/wakelock.c PM / sleep: Move prototype declaration to header file kernel/power/power.h PM / sleep: Asynchronous threads for suspend_late PM / sleep: Asynchronous threads for suspend_noirq PM / sleep: Asynchronous threads for resume_early PM / sleep: Asynchronous threads for resume_noirq PM / sleep: Two flags for async suspend_noirq and suspend_late

PM / sleep: Correct whitespace errors in

2014-03-20T12:03:22+00:00

rjw> Why exactly are they errors? Geert> checkpatch.pl says: "WARNING: please, no space before tabs", Vim (with "let c_space_errors=1") shows them in red. Signed-off-by: Geert Uytterhoeven Signed-off-by: Rafael J. Wysocki

PM / Runtime: Update runtime_idle() documentation for return value meaning

2014-03-20T02:33:41+00:00

As of commit 45f0a85c8258 ('PM / Runtime: Rework the "runtime idle" helper routine'), the return value of ->runtime_idle() is no longer ignored by the PM core, but used to decide whether to suspend the device or not. Update the documentation to match the code. Signed-off-by: Geert Uytterhoeven Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki

PM / sleep: Set pm_generic functions to NULL for !CONFIG_PM_SLEEP

2014-03-01T00:02:53+00:00

Previously only a subset of the functions were defined and set to NULL while !CONFIG_PM_SLEEP. Let's make them all available so they can be used no matter of CONFIG_PM_SLEEP or not. Signed-off-by: Ulf Hansson Reviewed-by: Pavel Machek Signed-off-by: Rafael J. Wysocki

PM: fix typo in comment

2014-03-01T00:02:52+00:00

Signed-off-by: Lad, Prabhakar Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki

PM / sleep: Two flags for async suspend_noirq and suspend_late

2014-02-20T00:30:08+00:00

The patch is a helper adding two new flags for implementing async threads for suspend_noirq and suspend_late. Signed-off-by: Chuansheng Liu Signed-off-by: Rafael J. Wysocki

PM / QoS: Introcuce latency tolerance device PM QoS type

2014-02-10T23:35:38+00:00

Add a new latency tolerance device PM QoS type to be use for specifying active state (RPM_ACTIVE) memory access (DMA) latency tolerance requirements for devices. It may be used to prevent hardware from choosing overly aggressive energy-saving operation modes (causing too much latency to appear) for the whole platform. This feature reqiures hardware support, so it only will be available for devices having a new .set_latency_tolerance() callback in struct dev_pm_info populated, in which case the routine pointed to by it should implement whatever is necessary to transfer the effective requirement value to the hardware. Whenever the effective latency tolerance changes for the device, its .set_latency_tolerance() callback will be executed and the effective value will be passed to it. If that value is negative, which means that the list of latency tolerance requirements for the device is empty, the callback is expected to switch the underlying hardware latency tolerance control mechanism to an autonomous mode if available. If that value is PM_QOS_LATENCY_ANY, in turn, and the hardware supports a special "no requirement" setting, the callback is expected to use it. That allows software to prevent the hardware from automatically updating the device's latency tolerance in response to its power state changes (e.g. during transitions from D3cold to D0), which generally may be done in the autonomous latency tolerance control mode. If .set_latency_tolerance() is present for the device, a new pm_qos_latency_tolerance_us attribute will be present in the devivce's power directory in sysfs. Then, user space can use that attribute to specify its latency tolerance requirement for the device, if any. Writing "any" to it means "no requirement, but do not let the hardware control latency tolerance" and writing "auto" to it allows the hardware to be switched to the autonomous mode if there are no other requirements from the kernel side in the device's list. This changeset includes a fix from Mika Westerberg. Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-sleep', 'pm-runtime' and 'pm-apm'

2014-01-12T22:50:03+00:00

* pm-sleep: PM / hibernate: Call platform_leave() in suspend path too PM / Sleep: Add macro to define common late/early system PM callbacks PM / hibernate: export hibernation_set_ops * pm-runtime: PM / Runtime: Implement the pm_generic_runtime functions for CONFIG_PM PM / Runtime: Add second macro for definition of runtime PM callbacks * pm-apm: apm-emulation: add hibernation APM events to support suspend2disk

PM / Runtime: Add second macro for definition of runtime PM callbacks

2013-12-22T00:39:52+00:00

By having the runtime PM callbacks implemented for CONFIG_PM, these becomes available in all combinations of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. The benefit using this, is that we don't need to implement the wrapper functions which handles runtime PM resourses, typically called from both runtime PM and system PM callbacks. Instead the runtime PM callbacks can be invoked directly from system PM callbacks, which is useful for some drivers, subsystems and power domains. Use the new macro SET_PM_RUNTIME_PM_OPS in cases were the above makes sense. Make sure the callbacks are encapsulated within CONFIG_PM instead of CONFIG_PM_RUNTIME. Do note that the old macro SET_RUNTIME_PM_OPS, which is being quite widely used right now, requires the callbacks to be defined for CONFIG_PM_RUNTIME. In many cases it will certainly be convenient to convert to the new macro above, but that will have to be distinguished in case by case. Cc: Kevin Hilman Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki