kernel/linux.git/drivers/base/power/generic_ops.c, branch v4.4.296

PM / PCI / ACPI: Kick devices that might have been reset by firmware

2015-10-14T00:17:34+00:00

There is a concern that if the platform firmware was involved in the system resume that's being completed, some devices might have been reset by it and if those devices had the power.direct_complete flag set during the preceding suspend transition, they may stay in a reset-power-on state indefinitely (until they are runtime-resumed and then suspended again). That may not be a big deal from the individual device's perspective, but if the system is an SoC, it may be prevented from entering deep SoC-wide low-power states on idle because of that. The devices that are most likely to be affected by this issue are PCI devices and ACPI-enumerated devices using the general ACPI PM domain, so to prevent it from happening for those devices, force a runtime resume for them if they have their power.direct_complete flags set and the platform firmware was involved in the resume transition currently in progress. Signed-off-by: Rafael J. Wysocki

PM / sleep: Drop pm_request_idle() from pm_generic_complete()

2015-10-14T00:17:06+00:00

The pm_request_idle() in pm_generic_complete() is pointless as it is called with the runtime PM usage counter different from zero (bumped up by the core during the prepare phase of system suspend) and the core calls pm_runtime_put() for all devices after executing their complete callbacks, so drop it. This allows the PCI PM layer to use pm_generic_complete() too. Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson

PM / Runtime: Spelling s/competing/completing/

2014-03-26T15:33:53+00:00

Signed-off-by: Geert Uytterhoeven Signed-off-by: Rafael J. Wysocki

PM / Runtime: Implement the pm_generic_runtime functions for CONFIG_PM

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

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:52+00:00

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: Asyncronous idle|suspend devices at system resume

2013-04-12T11:34:57+00:00

Use the asyncronous runtime PM API when returning the runtime reference for the device after the system resume is completed. By using the asyncronous runtime PM API we don't have to wait for each an every device to become idle|suspended. Instead we can move on and handle the next device in queue. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / Sleep: Introduce generic callbacks for new device PM phases

2012-01-29T19:38:41+00:00

Introduce generic subsystem callbacks for the new phases of device suspend/resume during system power transitions: "late suspend", "early resume", "late freeze", "early thaw", "late poweroff", "early restore". Signed-off-by: Rafael J. Wysocki

PM: Drop generic_subsys_pm_ops

2011-12-21T21:03:32+00:00

Since the PM core is now going to execute driver callbacks directly if the corresponding subsystem callbacks are not present, forward-only subsystem callbacks (i.e. such that only execute the corresponding driver callbacks) are not necessary any more. Thus it is possible to remove generic_subsys_pm_ops, because the only callback in there that is not forward-only, .runtime_idle, is not really used by the only user of generic_subsys_pm_ops, which is vio_bus_type. However, the generic callback routines themselves cannot be removed from generic_ops.c, because they are used individually by a number of subsystems. Signed-off-by: Rafael J. Wysocki

PM / Sleep: Merge internal functions in generic_ops.c

2011-12-17T23:27:43+00:00

After the change that removed the code related to runtime PM from __pm_generic_call() and __pm_generic_resume() these two functions need not be separate any more, so merge them. Signed-off-by: Rafael J. Wysocki

PM / Sleep: Simplify generic system suspend callbacks

2011-12-17T23:27:35+00:00

The pm_runtime_suspended() check in __pm_generic_call() doesn't really help and may cause problems to happen, because in some cases the system suspend callbacks need to be called even if the given device has been suspended by runtime PM. For example, if the device generally supports remote wakeup and is not enabled to wake up the system from sleep, it should be prevented from generating wakeup signals during system suspend and that has to be done by the suspend callbacks that the pm_runtime_suspended() check prevents from being executed. Similarly, it may not be a good idea to unconditionally change the runtime PM status of the device to 'active' in __pm_generic_resume(), because the driver may want to leave the device in the 'suspended' state, depending on what happened to it before the system suspend and whether or not it is enabled to wake up the system. For the above reasons, remove the pm_runtime_suspended() check from __pm_generic_call() and remove the code changing the device's runtime PM status from __pm_generic_resume(). Signed-off-by: Rafael J. Wysocki