2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 23:20:21 +01:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2014-05-16 02:47:37 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-03 21:04:08 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-10-09 11:40:25 +08:00
|
|
|
|
2011-11-23 21:18:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-23 21:18:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-21 21:41:53 +01:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
2017-06-24 01:58:53 +02:00
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
2017-06-24 01:58:53 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
|
|
|
|
|
2013-06-03 21:49:59 +02:00
|
|
|
|
2013-10-15 22:25:08 +02:00
|
|
|
|
|
|
|
|
|
2025-06-16 09:12:10 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2017-02-21 21:41:53 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2014-11-08 17:54:51 +09:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2014-11-08 17:54:51 +09:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM: runtime: Capture device status before disabling runtime PM
In some cases (for example, during system-wide suspend and resume of
devices) it is useful to know whether or not runtime PM has ever been
enabled for a given device and, if so, what the runtime PM status of
it had been right before runtime PM was disabled for it last time.
For this reason, introduce a new struct dev_pm_info field called
last_status that will be used for capturing the runtime PM status of
the device when its power.disable_depth counter changes from 0 to 1.
The new field will be set to RPM_INVALID to start with and whenever
power.disable_depth changes from 1 to 0, so it will be valid only
when runtime PM of the device is currently disabled, but it has been
enabled at least once.
Immediately use power.last_status in rpm_resume() to make it handle
the case when PM runtime is disabled for the device, but its runtime
PM status is RPM_ACTIVE more consistently. Namely, make it return 1
if power.last_status is also equal to RPM_ACTIVE in that case (the
idea being that if the status was RPM_ACTIVE last time when
power.disable_depth was changing from 0 to 1 and it is still
RPM_ACTIVE, it can be assumed to reflect what happened to the device
last time when it was using runtime PM) and -EACCES otherwise.
Update the documentation to provide a description of last_status and
change the description of pm_runtime_resume() in it to reflect the
new behavior of rpm_active().
While at it, rearrange the code in pm_runtime_enable() to be more
straightforward and replace the WARN() macro in it with a pr_warn()
invocation which is less disruptive.
Link: https://lore.kernel.org/linux-pm/20211026222626.39222-1-ulf.hansson@linaro.org/t/#u
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-07 19:54:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:17 +01:00
|
|
|
|
|
|
|
|
|
2019-11-19 08:09:23 -06:00
|
|
|
|
|
|
|
|
|
2010-03-06 21:28:17 +01:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2013-06-03 21:49:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-15 22:25:08 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-01 22:29:15 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2025-06-16 09:12:10 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-01-17 19:22:28 -02:00
|
|
|
|
PM: runtime: Capture device status before disabling runtime PM
In some cases (for example, during system-wide suspend and resume of
devices) it is useful to know whether or not runtime PM has ever been
enabled for a given device and, if so, what the runtime PM status of
it had been right before runtime PM was disabled for it last time.
For this reason, introduce a new struct dev_pm_info field called
last_status that will be used for capturing the runtime PM status of
the device when its power.disable_depth counter changes from 0 to 1.
The new field will be set to RPM_INVALID to start with and whenever
power.disable_depth changes from 1 to 0, so it will be valid only
when runtime PM of the device is currently disabled, but it has been
enabled at least once.
Immediately use power.last_status in rpm_resume() to make it handle
the case when PM runtime is disabled for the device, but its runtime
PM status is RPM_ACTIVE more consistently. Namely, make it return 1
if power.last_status is also equal to RPM_ACTIVE in that case (the
idea being that if the status was RPM_ACTIVE last time when
power.disable_depth was changing from 0 to 1 and it is still
RPM_ACTIVE, it can be assumed to reflect what happened to the device
last time when it was using runtime PM) and -EACCES otherwise.
Update the documentation to provide a description of last_status and
change the description of pm_runtime_resume() in it to reflect the
new behavior of rpm_active().
While at it, rearrange the code in pm_runtime_enable() to be more
straightforward and replace the WARN() macro in it with a pr_warn()
invocation which is less disruptive.
Link: https://lore.kernel.org/linux-pm/20211026222626.39222-1-ulf.hansson@linaro.org/t/#u
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-07 19:54:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-01 22:29:15 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2021-04-08 11:22:09 -04:00
|
|
|
|
|
|
|
|
|
2024-12-03 14:37:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-08 11:22:09 -04:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2025-06-16 09:12:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-12-22 20:43:17 +01:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2021-05-26 12:22:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-30 13:28:05 +02:00
|
|
|
|
2020-02-25 11:31:02 +02:00
|
|
|
|
2024-01-30 13:28:05 +02:00
|
|
|
|
2020-02-25 11:31:02 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2025-06-16 09:12:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-30 13:28:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2025-06-16 09:12:09 +03:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:06 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2011-07-06 10:52:06 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:06 +02:00
|
|
|
|
|
|
|
|
|
2014-03-24 21:31:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2025-12-02 11:30:25 -08:00
|
|
|
|
2011-07-06 10:52:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-02 11:30:25 -08:00
|
|
|
|
2011-07-06 10:52:06 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-16 22:51:22 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2013-01-23 21:49:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-12-16 17:11:58 +01:00
|
|
|
|
|
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-12 11:17:09 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
2011-08-25 15:31:05 +02:00
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2014-11-14 09:47:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2017-04-10 13:38:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2017-04-10 13:38:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2017-04-10 13:38:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-30 13:28:32 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2014-11-08 17:54:51 +09:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2015-04-17 01:14:15 +01:00
|
|
|
|
2021-01-26 15:26:55 -06:00
|
|
|
|
2015-04-17 01:14:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-08 06:13:51 +01:00
|
|
|
|
2017-02-21 21:41:53 +01:00
|
|
|
|
2013-11-08 06:13:51 +01:00
|
|
|
|
2021-01-26 15:26:55 -06:00
|
|
|
|
2013-11-08 06:13:51 +01:00
|
|
|
|
2011-07-02 14:27:11 +02:00
|
|
|
|
|
|
|
|
|
2021-01-26 15:26:55 -06:00
|
|
|
|
2011-07-02 14:27:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-26 15:26:55 -06:00
|
|
|
|
2011-07-02 14:27:11 +02:00
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
2016-04-03 12:23:07 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-06 21:28:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
|
|
|
|
|
2010-03-06 21:28:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
|
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
2011-07-01 22:29:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
2011-07-01 22:29:05 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2011-07-01 22:29:05 +02:00
|
|
|
|
|
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-22 20:43:40 +01:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 10:51:58 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 10:51:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-01 22:29:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-16 02:47:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-26 15:26:55 -06:00
|
|
|
|
2014-05-16 02:47:37 +02:00
|
|
|
|
2017-10-10 12:36:09 -05:00
|
|
|
|
2014-05-16 02:47:37 +02:00
|
|
|
|
|
|
|
|
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 10:51:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-16 13:05:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM: sleep: Do not flag runtime PM workqueue as freezable
Till now, the runtime PM workqueue has been flagged as freezable, so it
does not process work items during system-wide PM transitions like
system suspend and resume. The original reason to do that was to
reduce the likelihood of runtime PM getting in the way of system-wide
PM processing, but now it is mostly an optimization because (1) runtime
suspend of devices is prevented by bumping up their runtime PM usage
counters in device_prepare() and (2) device drivers are expected to
disable runtime PM for the devices handled by them before they embark
on system-wide PM activities that may change the state of the hardware
or otherwise interfere with runtime PM. However, it prevents
asynchronous runtime resume of devices from working during system-wide
PM transitions, which is confusing because synchronous runtime resume
is not prevented at the same time, and it also sometimes turns out to
be problematic.
For example, it has been reported that blk_queue_enter() may deadlock
during a system suspend transition because of the pm_request_resume()
usage in it [1]. It may also deadlock during a system resume transition
in a similar way. That happens because the asynchronous runtime resume
of the given device is not processed due to the freezing of the runtime
PM workqueue. While it may be better to address this particular issue
in the block layer, the very presence of it means that similar problems
may be expected to occur elsewhere.
For this reason, remove the WQ_FREEZABLE flag from the runtime PM
workqueue and make device_suspend_late() use the generic variant of
pm_runtime_disable() that will carry out runtime PM of the device
synchronously if there is pending resume work for it.
Also update the comment before the pm_runtime_disable() call in
device_suspend_late(), to document the fact that the runtime PM
should not be expected to work for the device until the end of
device_resume_early(), and update the related documentation.
This change may, even though it is not expected to, uncover some
latent issues related to queuing up asynchronous runtime resume
work items during system suspend or hibernation. However, they
should be limited to the interference between runtime resume and
system-wide PM callbacks in the cases when device drivers start
to handle system-wide PM before disabling runtime PM as described
above.
Link: https://lore.kernel.org/linux-pm/20251126101636.205505-2-yang.yang@vivo.com/
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/12794222.O9o76ZdvQC@rafael.j.wysocki
2025-12-05 16:24:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 10:51:58 +02:00
|
|
|
|
2014-05-16 13:05:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-22 23:59:01 +01:00
|
|
|
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 10:51:58 +02:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
2024-02-25 21:00:57 +08:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
2014-03-24 21:31:29 +01:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
2014-03-24 21:31:29 +01:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-01 22:12:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-01 22:12:59 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-01 22:12:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-01 22:12:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-01 22:12:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2011-07-01 22:12:59 +02:00
|
|
|
|
|
|
|
|
|
2021-01-26 15:26:55 -06:00
|
|
|
|
2014-03-24 21:31:30 +01:00
|
|
|
|
2011-07-01 22:12:59 +02:00
|
|
|
|
|
|
|
|
|
2014-03-24 21:31:30 +01:00
|
|
|
|
|
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2024-09-03 20:25:20 +03:00
|
|
|
|
|
|
|
|
|
2010-03-06 21:28:37 +01:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2021-06-09 12:06:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2025-06-16 09:12:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-16 09:12:08 +03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-10 13:38:24 +02:00
|
|
|
|
2025-06-16 09:12:12 +03:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2011-11-03 23:39:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 07:10:36 -03:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-16 09:12:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-24 21:31:31 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|