2019-04-02 15:32:01 +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:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2017-02-02 20:43:54 +01:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
|
|
|
|
|
2011-05-27 07:12:15 -04:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
PM / Wakeirq: Add automated device wake IRQ handling
Turns out we can automate the handling for the device_may_wakeup()
quite a bit by using the kernel wakeup source list as suggested
by Rafael J. Wysocki <rjw@rjwysocki.net>.
And as some hardware has separate dedicated wake-up interrupt
in addition to the IO interrupt, we can automate the handling by
adding a generic threaded interrupt handler that just calls the
device PM runtime to wake up the device.
This allows dropping code from device drivers as we currently
are doing it in multiple ways, and often wrong.
For most drivers, we should be able to drop the following
boilerplate code from runtime_suspend and runtime_resume
functions:
...
device_init_wakeup(dev, true);
...
if (device_may_wakeup(dev))
enable_irq_wake(irq);
...
if (device_may_wakeup(dev))
disable_irq_wake(irq);
...
device_init_wakeup(dev, false);
...
We can replace it with just the following init and exit
time code:
...
device_init_wakeup(dev, true);
dev_pm_set_wake_irq(dev, irq);
...
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
...
And for hardware with dedicated wake-up interrupts:
...
device_init_wakeup(dev, true);
dev_pm_set_dedicated_wake_irq(dev, irq);
...
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
...
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-18 15:40:29 -07:00
|
|
|
|
2023-12-17 19:57:18 -05:00
|
|
|
|
2011-09-27 22:54:41 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
2014-03-01 11:56:04 +01:00
|
|
|
|
2025-06-27 21:20:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
2014-03-01 11:56:04 +01:00
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
2025-06-27 21:20:40 +02:00
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-27 21:20:40 +02:00
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
2025-06-27 21:20:40 +02:00
|
|
|
|
|
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:04 +01:00
|
|
|
|
|
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:04 +01:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-05 13:55:35 +01:00
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
2019-02-04 17:25:53 +01:00
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-04 17:25:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
|
|
|
|
|
2019-02-04 17:25:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-26 22:35:27 +05:30
|
|
|
|
2019-02-04 17:25:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
2019-01-23 08:50:14 +01:00
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
2019-01-23 08:50:14 +01:00
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-21 19:47:53 +00:00
|
|
|
|
2010-09-25 23:34:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-05 13:55:26 +01:00
|
|
|
|
2018-12-21 11:33:54 +01:00
|
|
|
|
2019-01-23 08:50:14 +01:00
|
|
|
|
|
|
|
|
|
2018-12-21 11:33:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-05 13:55:26 +01:00
|
|
|
|
2018-12-21 11:33:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-23 08:50:14 +01:00
|
|
|
|
2018-12-21 11:33:54 +01:00
|
|
|
|
2019-03-05 13:55:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-21 11:33:54 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-21 08:59:02 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-10 00:19:44 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2019-01-30 22:40:17 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2019-01-30 22:40:17 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-23 14:07:29 -07:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-01-30 22:40:17 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-01-30 22:40:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2019-01-30 22:40:17 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-22 16:34:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-26 22:35:27 +05:30
|
|
|
|
2013-02-22 16:34:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2013-02-22 16:34:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-01 22:29:15 +02:00
|
|
|
|
|
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2019-07-04 13:06:18 +05:30
|
|
|
|
2012-08-15 21:32:04 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-16 18:12:25 -04:00
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
2025-06-16 20:16:21 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-01 14:58:34 +01:00
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
driver core: Fix handling of runtime PM flags in device_link_add()
After commit ead18c23c263 ("driver core: Introduce device links
reference counting"), if there is a link between the given supplier
and the given consumer already, device_link_add() will refcount it
and return it unconditionally without updating its flags. It is
possible, however, that the second (or any subsequent) caller of
device_link_add() for the same consumer-supplier pair will pass
DL_FLAG_PM_RUNTIME, possibly along with DL_FLAG_RPM_ACTIVE, in flags
to it and the existing link may not behave as expected then.
First, if DL_FLAG_PM_RUNTIME is not set in the existing link's flags
at all, it needs to be set like during the original initialization of
the link.
Second, if DL_FLAG_RPM_ACTIVE is passed to device_link_add() in flags
(in addition to DL_FLAG_PM_RUNTIME), the existing link should to be
updated to reflect the "active" runtime PM configuration of the
consumer-supplier pair and extra care must be taken here to avoid
possible destructive races with runtime PM of the consumer.
To that end, redefine the rpm_active field in struct device_link
as a refcount, initialize it to 1 and make rpm_resume() (for the
consumer) and device_link_add() increment it whenever they acquire
a runtime PM reference on the supplier device. Accordingly, make
rpm_suspend() (for the consumer) and pm_runtime_clean_up_links()
decrement it and drop runtime PM references to the supplier
device in a loop until rpm_active becones 1 again.
Fixes: ead18c23c263 ("driver core: Introduce device links reference counting")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-01 01:49:14 +01:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-10 17:10:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-27 20:42:18 +02:00
|
|
|
|
2021-12-10 17:10:13 +01:00
|
|
|
|
2022-06-27 20:42:18 +02:00
|
|
|
|
2021-12-10 17:10:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-16 18:12:25 -04:00
|
|
|
|
2022-06-27 20:42:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-08 11:02:49 +02:00
|
|
|
|
2021-03-19 15:47:25 +01:00
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
|
|
|
|
|
2021-03-19 15:47:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-08 11:02:49 +02:00
|
|
|
|
|
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
2021-03-19 15:47:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-19 15:47:25 +01:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
2021-03-19 15:47:25 +01:00
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-02 15:32:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-25 18:06:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-02 15:32:09 +01:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
2013-10-15 22:25:08 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2010-10-04 22:08:01 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM: runtime: Make put{,_sync}() return 1 when already suspended
The pm_runtime.h docs say pm_runtime_put() and pm_runtime_put_sync()
return 1 when already suspended, but this is not true -- they return
-EAGAIN. On the other hand, pm_runtime_put_sync_suspend() and
pm_runtime_put_sync_autosuspend() *do* return 1.
This is an artifact of the fact that the former are built on rpm_idle(),
whereas the latter are built on rpm_suspend().
There are precious few pm_runtime_put()/pm_runtime_put_sync() callers
that check the return code at all, but most of them only log errors, and
usually only for negative error codes. None of them should be treating
this as an error, so:
* at best, this may fix some case where a driver treats this condition
as an error, when it shouldn't;
* at worst, this should make no effect; and
* somewhere in between, we could potentially clear up non-fatal log
messages.
Fix the pm_runtime_already_suspended_test() while tweaking the behavior.
The test makes a lot more sense when these all return 1 when the device
is already suspended:
pm_runtime_put_sync(dev);
pm_runtime_suspend(dev);
pm_runtime_autosuspend(dev);
pm_request_autosuspend(dev);
pm_runtime_put_sync_autosuspend(dev);
Notably, I've avoided testing the return codes for these, since they
really should be ignored by callers, and we may make them 'void'
altogether:
pm_runtime_put(dev);
pm_runtime_put_autosuspend(dev);
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-25 12:42:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-08 11:02:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
PM / Runtime: Rework the "runtime idle" helper routine
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>
2013-06-03 21:49:52 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-02 15:30:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2013-10-15 22:25:08 +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:34:54 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-10-12 11:53:32 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-12 22:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-03 23:39:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-10-04 22:08:01 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
2020-05-22 18:09:55 +03:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
2020-05-22 18:09:55 +03:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-10 10:00:40 +01:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-19 02:01:06 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
2016-12-05 16:38:16 -08:00
|
|
|
|
2010-10-04 22:08:01 +02:00
|
|
|
|
2011-12-01 00:01:31 +01:00
|
|
|
|
|
|
|
|
|
2011-11-03 23:39:18 +01:00
|
|
|
|
PM / wakeirq: support enabling wake-up irq after runtime_suspend called
When the dedicated wake IRQ is level trigger, and it uses the
device's low-power status as the wakeup source, that means if the
device is not in low-power state, the wake IRQ will be triggered
if enabled; For this case, need enable the wake IRQ after running
the device's ->runtime_suspend() which make it enter low-power state.
e.g.
Assume the wake IRQ is a low level trigger type, and the wakeup
signal comes from the low-power status of the device.
The wakeup signal is low level at running time (0), and becomes
high level when the device enters low-power state (runtime_suspend
(1) is called), a wakeup event at (2) make the device exit low-power
state, then the wakeup signal also becomes low level.
------------------
| ^ ^|
---------------- | | --------------
|<---(0)--->|<--(1)--| (3) (2) (4)
if enable the wake IRQ before running runtime_suspend during (0),
a wake IRQ will arise, it causes resume immediately;
it works if enable wake IRQ ( e.g. at (3) or (4)) after running
->runtime_suspend().
This patch introduces a new status WAKE_IRQ_DEDICATED_REVERSE to
optionally support enabling wake IRQ after running ->runtime_suspend().
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-10-25 15:01:53 +08:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
2011-10-12 22:59:33 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-10-12 22:59:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-15 21:31:55 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-25 20:50:07 +01:00
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
2011-01-25 20:50:07 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-01-25 20:50:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-01-25 20:50:07 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2021-03-19 15:47:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-12-01 00:01:31 +01:00
|
|
|
|
|
|
|
|
|
PM / wakeirq: support enabling wake-up irq after runtime_suspend called
When the dedicated wake IRQ is level trigger, and it uses the
device's low-power status as the wakeup source, that means if the
device is not in low-power state, the wake IRQ will be triggered
if enabled; For this case, need enable the wake IRQ after running
the device's ->runtime_suspend() which make it enter low-power state.
e.g.
Assume the wake IRQ is a low level trigger type, and the wakeup
signal comes from the low-power status of the device.
The wakeup signal is low level at running time (0), and becomes
high level when the device enters low-power state (runtime_suspend
(1) is called), a wakeup event at (2) make the device exit low-power
state, then the wakeup signal also becomes low level.
------------------
| ^ ^|
---------------- | | --------------
|<---(0)--->|<--(1)--| (3) (2) (4)
if enable the wake IRQ before running runtime_suspend during (0),
a wake IRQ will arise, it causes resume immediately;
it works if enable wake IRQ ( e.g. at (3) or (4)) after running
->runtime_suspend().
This patch introduces a new status WAKE_IRQ_DEDICATED_REVERSE to
optionally support enabling wake IRQ after running ->runtime_suspend().
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-10-25 15:01:53 +08:00
|
|
|
|
2011-12-01 00:01:31 +01:00
|
|
|
|
|
|
|
|
|
2012-03-26 22:46:52 +02:00
|
|
|
|
|
|
|
|
|
2025-02-25 18:06:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-01 00:01:31 +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
|
|
|
|
2010-09-25 23:34:54 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2011-03-30 22:57:33 -03:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-10-04 22:08:01 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +01: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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM: runtime: Add auto-cleanup macros for "resume and get" operations
It is generally useful to be able to automatically drop a device's
runtime PM usage counter incremented by runtime PM operations that
resume a device and bump up its usage counter [1].
To that end, add guard definition macros allowing pm_runtime_put()
and pm_runtime_put_autosuspend() to be used for the auto-cleanup in
those cases.
Simply put, a piece of code like below:
pm_runtime_get_sync(dev);
.....
pm_runtime_put(dev);
return 0;
can be transformed with guard() like:
guard(pm_runtime_active)(dev);
.....
return 0;
(see the pm_runtime_put() call is gone).
However, it is better to do proper error handling in the majority of
cases, so doing something like this instead of the above is recommended:
ACQUIRE(pm_runtime_active_try, pm)(dev);
if (ACQUIRE_ERR(pm_runtime_active_try, &pm))
return -ENXIO;
.....
return 0;
In all of the cases in which runtime PM is known to be enabled for the
given device or the device can be regarded as operational (and so it can
be accessed) with runtime PM disabled, a piece of code like:
ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
.....
pm_runtime_put(dev);
return 0;
can be changed as follows:
ACQUIRE(pm_runtime_active_try, pm)(dev);
ret = ACQUIRE_ERR(pm_runtime_active_try, &pm);
if (ret < 0)
return ret;
.....
return 0;
(again, see the pm_runtime_put() call is gone).
Still, if the device cannot be accessed unless runtime PM has been
enabled for it, the pm_runtime_active_try_enabled guard variant
needs to be used, that is (in the context of the example above):
ACQUIRE(pm_runtime_active_try_enabled, pm)(dev);
ret = ACQUIRE_ERR(pm_runtime_active_try_enabled, &pm);
if (ret < 0)
return ret;
.....
return 0;
When the original code calls pm_runtime_put_autosuspend(), use one
of the "auto" guard variants, pm_runtime_active_auto/_try/_enabled,
so for example, a piece of code like:
ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
.....
pm_runtime_put_autosuspend(dev);
return 0;
will become:
ACQUIRE(pm_runtime_active_auto_try_enabled, pm)(dev);
ret = ACQUIRE_ERR(pm_runtime_active_auto_try_enabled, &pm);
if (ret < 0)
return ret;
.....
return 0;
Note that the cases in which the return value of pm_runtime_get_sync()
is checked can also be handled with the help of the new guard macros.
For example, a piece of code like:
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
pm_runtime_put(dev);
return ret;
}
.....
pm_runtime_put(dev);
return 0;
can be rewritten as:
ACQUIRE(pm_runtime_active_auto_try_enabled, pm)(dev);
ret = ACQUIRE_ERR(pm_runtime_active_auto_try_enabled, &pm);
if (ret < 0)
return ret;
.....
return 0;
or pm_runtime_get_active_try can be used if transparent handling of
disabled runtime PM is desirable.
Link: https://lore.kernel.org/linux-pm/878qimv24u.wl-tiwai@suse.de/ [1]
Link: https://lore.kernel.org/linux-pm/20250926150613.000073a4@huawei.com/
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/2238241.irdbgypaU6@rafael.j.wysocki
[ rjw: Fixed leftovers from the previous version in the changelog ]
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-26 17:47:14 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2022-09-22 20:04:40 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2022-09-22 20:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2022-09-22 20:04:40 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-27 21:54:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-22 23:48:14 +02:00
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
2012-08-15 21:31:45 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2009-11-25 01:06:37 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-25 01:06:37 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2016-10-17 20:16:59 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-25 01:06:37 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2009-11-25 01:06:37 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-19 02:01:06 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2014-10-17 12:58:02 +02:00
|
|
|
|
2011-12-18 00:34:13 +01:00
|
|
|
|
PM / wakeirq: support enabling wake-up irq after runtime_suspend called
When the dedicated wake IRQ is level trigger, and it uses the
device's low-power status as the wakeup source, that means if the
device is not in low-power state, the wake IRQ will be triggered
if enabled; For this case, need enable the wake IRQ after running
the device's ->runtime_suspend() which make it enter low-power state.
e.g.
Assume the wake IRQ is a low level trigger type, and the wakeup
signal comes from the low-power status of the device.
The wakeup signal is low level at running time (0), and becomes
high level when the device enters low-power state (runtime_suspend
(1) is called), a wakeup event at (2) make the device exit low-power
state, then the wakeup signal also becomes low level.
------------------
| ^ ^|
---------------- | | --------------
|<---(0)--->|<--(1)--| (3) (2) (4)
if enable the wake IRQ before running runtime_suspend during (0),
a wake IRQ will arise, it causes resume immediately;
it works if enable wake IRQ ( e.g. at (3) or (4)) after running
->runtime_suspend().
This patch introduces a new status WAKE_IRQ_DEDICATED_REVERSE to
optionally support enabling wake IRQ after running ->runtime_suspend().
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-10-25 15:01:53 +08:00
|
|
|
|
2010-10-04 22:08:01 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-07-19 02:01:06 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2016-12-05 16:38:16 -08:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:15 +02:00
|
|
|
|
2010-07-19 02:01:06 +02:00
|
|
|
|
2015-05-13 16:36:32 -07:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-15 21:31:45 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +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:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +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
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-31 18:26:10 -05:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-10 00:19:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-15 12:11:25 +05:30
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-30 18:26:02 +01:00
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-30 18:26:02 +01:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2018-12-14 15:22:25 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
2011-08-08 23:39:36 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2020-01-04 17:27:57 +01:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
PM / runtime: Avoid false-positive warnings from might_sleep_if()
The might_sleep_if() assertions in __pm_runtime_idle(),
__pm_runtime_suspend() and __pm_runtime_resume() may generate
false-positive warnings in some situations. For example, that
happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
is executed with disabled interrupts within an outer
pm_runtime_get_sync()/pm_runtime_put() section for the same device.
[Generally, pm_runtime_get_sync() may sleep, so it should not be
called with disabled interrupts, but in this particular case the
previous pm_runtime_get_sync() guarantees that the device will not
be suspended, so the inner pm_runtime_get_sync() will return
immediately after incrementing the device's usage counter.]
That started to happen in the i915 driver in 4.10-rc, leading to
the following splat:
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
1 lock held by Xorg/1500:
#0: (&dev->struct_mutex){+.+.+.}, at:
[<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
CPU: 0 PID: 1500 Comm: Xorg Not tainted
Call Trace:
dump_stack+0x85/0xc2
___might_sleep+0x196/0x260
__might_sleep+0x53/0xb0
__pm_runtime_resume+0x7a/0x90
intel_runtime_pm_get+0x25/0x90 [i915]
aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
i915_vma_bind+0xaf/0x1e0 [i915]
i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
? trace_hardirqs_on+0xd/0x10
? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
? __might_fault+0x4e/0xb0
i915_gem_execbuffer2+0xc5/0x260 [i915]
? __might_fault+0x4e/0xb0
drm_ioctl+0x206/0x450 [drm]
? i915_gem_execbuffer+0x340/0x340 [i915]
? __fget+0x5/0x200
do_vfs_ioctl+0x91/0x6f0
? __fget+0x111/0x200
? __fget+0x5/0x200
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x23/0xc6
even though the code triggering it is correct.
Unfortunately, the might_sleep_if() assertions in question are
too coarse-grained to cover such cases correctly, so make them
a bit less sensitive in order to avoid the false-positives.
Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-04 00:44:36 +01:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2011-08-08 23:39:36 +02:00
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
2020-01-04 17:27:57 +01:00
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
PM / runtime: Avoid false-positive warnings from might_sleep_if()
The might_sleep_if() assertions in __pm_runtime_idle(),
__pm_runtime_suspend() and __pm_runtime_resume() may generate
false-positive warnings in some situations. For example, that
happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
is executed with disabled interrupts within an outer
pm_runtime_get_sync()/pm_runtime_put() section for the same device.
[Generally, pm_runtime_get_sync() may sleep, so it should not be
called with disabled interrupts, but in this particular case the
previous pm_runtime_get_sync() guarantees that the device will not
be suspended, so the inner pm_runtime_get_sync() will return
immediately after incrementing the device's usage counter.]
That started to happen in the i915 driver in 4.10-rc, leading to
the following splat:
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
1 lock held by Xorg/1500:
#0: (&dev->struct_mutex){+.+.+.}, at:
[<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
CPU: 0 PID: 1500 Comm: Xorg Not tainted
Call Trace:
dump_stack+0x85/0xc2
___might_sleep+0x196/0x260
__might_sleep+0x53/0xb0
__pm_runtime_resume+0x7a/0x90
intel_runtime_pm_get+0x25/0x90 [i915]
aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
i915_vma_bind+0xaf/0x1e0 [i915]
i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
? trace_hardirqs_on+0xd/0x10
? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
? __might_fault+0x4e/0xb0
i915_gem_execbuffer2+0xc5/0x260 [i915]
? __might_fault+0x4e/0xb0
drm_ioctl+0x206/0x450 [drm]
? i915_gem_execbuffer+0x340/0x340 [i915]
? __fget+0x5/0x200
do_vfs_ioctl+0x91/0x6f0
? __fget+0x111/0x200
? __fget+0x5/0x200
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x23/0xc6
even though the code triggering it is correct.
Unfortunately, the might_sleep_if() assertions in question are
too coarse-grained to cover such cases correctly, so make them
a bit less sensitive in order to avoid the false-positives.
Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-04 00:44:36 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2010-09-25 23:34:54 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-08 23:39:36 +02:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-12-13 20:28:30 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
PM / runtime: Avoid false-positive warnings from might_sleep_if()
The might_sleep_if() assertions in __pm_runtime_idle(),
__pm_runtime_suspend() and __pm_runtime_resume() may generate
false-positive warnings in some situations. For example, that
happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
is executed with disabled interrupts within an outer
pm_runtime_get_sync()/pm_runtime_put() section for the same device.
[Generally, pm_runtime_get_sync() may sleep, so it should not be
called with disabled interrupts, but in this particular case the
previous pm_runtime_get_sync() guarantees that the device will not
be suspended, so the inner pm_runtime_get_sync() will return
immediately after incrementing the device's usage counter.]
That started to happen in the i915 driver in 4.10-rc, leading to
the following splat:
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
1 lock held by Xorg/1500:
#0: (&dev->struct_mutex){+.+.+.}, at:
[<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
CPU: 0 PID: 1500 Comm: Xorg Not tainted
Call Trace:
dump_stack+0x85/0xc2
___might_sleep+0x196/0x260
__might_sleep+0x53/0xb0
__pm_runtime_resume+0x7a/0x90
intel_runtime_pm_get+0x25/0x90 [i915]
aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
i915_vma_bind+0xaf/0x1e0 [i915]
i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
? trace_hardirqs_on+0xd/0x10
? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
? __might_fault+0x4e/0xb0
i915_gem_execbuffer2+0xc5/0x260 [i915]
? __might_fault+0x4e/0xb0
drm_ioctl+0x206/0x450 [drm]
? i915_gem_execbuffer+0x340/0x340 [i915]
? __fget+0x5/0x200
do_vfs_ioctl+0x91/0x6f0
? __fget+0x111/0x200
? __fget+0x5/0x200
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x23/0xc6
even though the code triggering it is correct.
Unfortunately, the might_sleep_if() assertions in question are
too coarse-grained to cover such cases correctly, so make them
a bit less sensitive in order to avoid the false-positives.
Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-04 00:44:36 +01:00
|
|
|
|
|
|
|
|
|
2011-08-08 23:39:36 +02:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
2024-01-30 13:28:05 +02:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
2020-07-31 19:04:11 +02:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
2020-07-31 19:04:11 +02:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
2025-07-09 12:41:45 +02:00
|
|
|
|
|
|
|
|
|
2025-10-26 22:35:27 +05:30
|
|
|
|
2025-07-09 12:41:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-25 11:31:02 +02:00
|
|
|
|
2020-07-31 19:04:11 +02:00
|
|
|
|
|
|
|
|
|
2020-02-25 11:31:02 +02:00
|
|
|
|
2020-07-31 19:04:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-25 11:31:02 +02:00
|
|
|
|
2021-01-20 20:03:12 +05:30
|
|
|
|
2020-07-31 19:04:11 +02:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
2024-01-30 13:28:05 +02:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-25 11:31:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-09 12:41:45 +02:00
|
|
|
|
|
|
|
|
|
2020-02-25 11:31:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
2020-02-25 11:31:02 +02: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
|
|
|
|
2015-12-17 02:54:26 +01:00
|
|
|
|
2024-01-30 13:28:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-09 12:41:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-30 13:28:05 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-07 19:38:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 16:11:23 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 16:11:23 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-02-12 13:04:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-02-12 13:04:12 +01:00
|
|
|
|
2022-04-01 16:11:23 +02:00
|
|
|
|
2019-02-12 13:04:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-07 19:38:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
2022-04-01 16:11:23 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-16 22:51:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-03 20:21:21 +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
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-20 11:14:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2016-06-20 11:14:26 +02:00
|
|
|
|
2009-12-03 21:04:41 +01:00
|
|
|
|
2016-06-20 11:14:26 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2009-11-25 01:06:37 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-02-07 19:38:56 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2019-02-07 19:38:56 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-19 02:01:06 +02:00
|
|
|
|
2019-02-07 19:38:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2022-04-01 16:11:23 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-07 19:38:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-12 13:04:12 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +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
|
|
|
|
|
|
|
|
|
2025-12-02 11:30:25 -08:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-02 11:30:25 -08:00
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-18 21:20:46 +01:00
|
|
|
|
2025-02-18 21:11:42 +01:00
|
|
|
|
2025-02-18 21:20:46 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 21:11:42 +01:00
|
|
|
|
|
|
|
|
|
2025-02-27 11:49:12 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 21:11:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-18 21:20:46 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 21:11:42 +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
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-04 17:25:53 +01: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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02: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
|
|
|
|
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-01-23 08:50:13 +01: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
|
|
|
|
|
|
|
|
|
2017-11-16 22:51:22 +01:00
|
|
|
|
2025-02-18 21:11:42 +01: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-27 20:59:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-31 22:50:32 +03:00
|
|
|
|
|
|
|
|
|
2022-02-23 08:34:48 -08:00
|
|
|
|
2021-07-31 22:50:32 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-23 08:34:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-31 22:50:32 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-27 20:59:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
|
|
|
|
|
2025-10-22 22:26:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:07 +02:00
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-06 10:52:13 +02:00
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
|
|
|
|
|
2025-10-22 22:26:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
|
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
|
|
|
|
|
2016-06-29 02:53:48 +02:00
|
|
|
|
2022-04-13 17:30:32 +02:00
|
|
|
|
2023-01-12 20:43:54 +01:00
|
|
|
|
2010-01-23 22:02:51 +01: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-12-01 00:14:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 19:54:59 +01:00
|
|
|
|
2010-12-01 00:14:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-25 23:35:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-04 17:27:57 +01:00
|
|
|
|
2023-01-12 20:43:54 +01: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02: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
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-23 22:02:51 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-27 21:06:34 +02:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-05 11:39:12 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM / runtime: Re-init runtime PM states at probe error and driver unbind
There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.
Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.
This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().
Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.
These are two scenarios that suffers from this unmet expectation.
i) A failed ->probe() sequence requests probe deferral:
->probe()
...
pm_runtime_enable()
pm_runtime_get_sync()
...
err:
pm_runtime_put()
pm_runtime_disable()
...
As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.
In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.
ii) A driver re-bind sequence:
At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.
->remove()
...
pm_runtime_put()
pm_runtime_disable()
...
Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.
Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.
Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.
The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.
A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.
This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.
To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.
Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-18 11:48:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-15 15:21:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM / runtime: Re-init runtime PM states at probe error and driver unbind
There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.
Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.
This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().
Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.
These are two scenarios that suffers from this unmet expectation.
i) A failed ->probe() sequence requests probe deferral:
->probe()
...
pm_runtime_enable()
pm_runtime_get_sync()
...
err:
pm_runtime_put()
pm_runtime_disable()
...
As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.
In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.
ii) A driver re-bind sequence:
At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.
->remove()
...
pm_runtime_put()
pm_runtime_disable()
...
Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.
Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.
Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.
The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.
A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.
This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.
To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.
Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-18 11:48:39 +01:00
|
|
|
|
2025-06-27 21:16:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM / runtime: Re-init runtime PM states at probe error and driver unbind
There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.
Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.
This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().
Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.
These are two scenarios that suffers from this unmet expectation.
i) A failed ->probe() sequence requests probe deferral:
->probe()
...
pm_runtime_enable()
pm_runtime_get_sync()
...
err:
pm_runtime_put()
pm_runtime_disable()
...
As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.
In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.
ii) A driver re-bind sequence:
At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.
->remove()
...
pm_runtime_put()
pm_runtime_disable()
...
Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.
Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.
Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.
The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.
A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.
This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.
To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.
Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-18 11:48:39 +01:00
|
|
|
|
|
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-12 11:27:20 -07:00
|
|
|
|
PM / runtime: Re-init runtime PM states at probe error and driver unbind
There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.
Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.
This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().
Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.
These are two scenarios that suffers from this unmet expectation.
i) A failed ->probe() sequence requests probe deferral:
->probe()
...
pm_runtime_enable()
pm_runtime_get_sync()
...
err:
pm_runtime_put()
pm_runtime_disable()
...
As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.
In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.
ii) A driver re-bind sequence:
At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.
->remove()
...
pm_runtime_put()
pm_runtime_disable()
...
Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.
Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.
Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.
The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.
A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.
This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.
To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.
Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-18 11:48:39 +01:00
|
|
|
|
2009-08-18 23:38:32 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2018-06-12 10:24:13 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
2018-06-12 10:24:13 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
2018-06-12 10:24:13 +02:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-02 15:45:14 +02:00
|
|
|
|
2025-06-16 20:16:21 +02:00
|
|
|
|
2019-02-19 17:53:26 +01:00
|
|
|
|
2018-06-12 10:24:13 +02:00
|
|
|
|
driver core: Fix possible supplier PM-usage counter imbalance
If a stateless device link to a certain supplier with
DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the
consumer driver's probe callback, the supplier's PM-runtime usage
counter will be nonzero after that which effectively causes the
supplier to remain "always on" going forward.
Namely, device_link_add() called to add the link invokes
device_link_rpm_prepare() which notices that the consumer driver is
probing, so it increments the supplier's PM-runtime usage counter
with the assumption that the link will stay around until
pm_runtime_put_suppliers() is called by driver_probe_device(),
but if the link goes away before that point, the supplier's
PM-runtime usage counter will remain nonzero.
To prevent that from happening, first rework pm_runtime_get_suppliers()
and pm_runtime_put_suppliers() to use the rpm_active refounts of device
links and make the latter only drop rpm_active and the supplier's
PM-runtime usage counter for each link by one, unless rpm_active is
one already for it. Next, modify device_link_add() to bump up the
new link's rpm_active refcount and the suppliers PM-runtime usage
counter by two, to prevent pm_runtime_put_suppliers(), if it is
called subsequently, from suspending the supplier prematurely (in
case its PM-runtime usage counter goes down to 0 in there).
Due to the way rpm_put_suppliers() works, this change does not
affect runtime suspend of the consumer ends of new device links (or,
generally, device links for which DL_FLAG_PM_RUNTIME has just been
set).
Fixes: e2f3cd831a28 ("driver core: Fix handling of runtime PM flags in device_link_add()")
Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12 13:08:10 +01:00
|
|
|
|
2018-06-12 10:24:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-16 18:12:25 -04:00
|
|
|
|
|
|
|
|
|
2019-02-19 17:53:26 +01:00
|
|
|
|
|
|
|
|
|
PM: runtime: Fix supplier device management during consumer probe
Because pm_runtime_get_suppliers() bumps up the rpm_active counter
of each device link to a supplier of the given device in addition
to bumping up the supplier's PM-runtime usage counter, a runtime
suspend of the consumer device may case the latter to go down to 0
when pm_runtime_put_suppliers() is running on a remote CPU. If that
happens after pm_runtime_put_suppliers() has released power.lock for
the consumer device, and a runtime resume of that device takes place
immediately after it, before pm_runtime_put() is called for the
supplier, that pm_runtime_put() call may cause the supplier to be
suspended even though the consumer is active.
To prevent that from happening, modify pm_runtime_get_suppliers() to
call pm_runtime_get_sync() for the given device's suppliers without
touching the rpm_active counters of the involved device links
Accordingly, modify pm_runtime_put_suppliers() to call pm_runtime_put()
for the given device's suppliers without looking at the rpm_active
counters of the device links at hand. [This is analogous to what
happened before commit 4c06c4e6cf63 ("driver core: Fix possible
supplier PM-usage counter imbalance").]
Since pm_runtime_get_suppliers() sets supplier_preactivated for each
device link where the supplier's PM-runtime usage counter has been
incremented and pm_runtime_put_suppliers() calls pm_runtime_put() for
the suppliers whose device links have supplier_preactivated set, the
PM-runtime usage counter is balanced for each supplier and this is
independent of the runtime suspend and resume of the consumer device.
However, in case a device link with DL_FLAG_PM_RUNTIME set is dropped
during the consumer device probe, so pm_runtime_get_suppliers() bumps
up the supplier's PM-runtime usage counter, but it cannot be dropped by
pm_runtime_put_suppliers(), make device_link_release_fn() take care of
that.
Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance")
Reported-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Cc: 5.1+ <stable@vger.kernel.org> # 5.1+
2022-06-30 21:16:41 +02:00
|
|
|
|
2019-02-19 17:53:26 +01:00
|
|
|
|
2016-10-30 17:32:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-21 21:12:15 +02:00
|
|
|
|
2016-10-30 17:32:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-21 21:12:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-16 20:16:21 +02:00
|
|
|
|
2020-10-21 21:12:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-27 20:42:18 +02:00
|
|
|
|
|
|
|
|
|
2016-10-30 17:32:43 +01:00
|
|
|
|
|
|
|
|
|
PM: sleep: Add strict_midlayer flag to struct dev_pm_info
Add a new flag, called strict_midlayer, to struct dev_pm_info, along
with helper functions for updating and reading its value, to allow
middle layer code that provides proper callbacks for device suspend-
resume during system-wide PM transitions to let pm_runtime_force_suspend()
and and pm_runtime_force_resume() know that they should only invoke
runtime PM callbacks coming from the device's driver.
Namely, if this flag is set, pm_runtime_force_suspend() and
and pm_runtime_force_resume() will invoke runtime PM callbacks
provided by the device's driver directly with the assumption that
they have been called via a middle layer callback for device suspend
or resume, respectively.
For instance, acpi_general_pm_domain provides specific
callback functions for system suspend, acpi_subsys_suspend(),
acpi_subsys_suspend_late() and acpi_subsys_suspend_noirq(), and
it does not expect its runtime suspend callback function,
acpi_subsys_runtime_suspend(), to be invoked at any point during
system suspend. In particular, it does not expect that function
to be called from within any of the system suspend callback functions
mentioned above which would happen if a device driver collaborating
with acpi_general_pm_domain used pm_runtime_force_suspend() as its
callback function for any system suspend phase later than "prepare".
The new flag allows this expectation of acpi_general_pm_domain to
be formally expressed, which is going to be done subsequently.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/24017035.6Emhk5qWAg@rjwysocki.net
2025-06-27 21:23:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM / runtime: Rework pm_runtime_force_suspend/resume()
One of the limitations of pm_runtime_force_suspend/resume() is that
if a parent driver wants to use these functions, all of its child
drivers generally have to do that too because of the parent usage
counter manipulations necessary to get the correct state of the parent
during system-wide transitions to the working state (system resume).
However, that limitation turns out to be artificial, so remove it.
Namely, pm_runtime_force_suspend() only needs to update the children
counter of its parent (if there's is a parent) when the device can
stay in suspend after the subsequent system resume transition, as
that counter is correct already otherwise. Now, if the parent's
children counter is not updated, it is not necessary to increment
the parent's usage counter in that case any more, as long as the
children counters of devices are checked along with their usage
counters in order to decide whether or not the devices may be left
in suspend after the subsequent system resume transition.
Accordingly, modify pm_runtime_force_suspend() to only call
pm_runtime_set_suspended() for devices whose usage and children
counters are at the "no references" level (the runtime PM status
of the device needs to be updated to "suspended" anyway in case
this function is called once again for the same device during the
transition under way), drop the parent usage counter incrementation
from it and update pm_runtime_force_resume() to compensate for these
changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-01-12 14:12:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
PM / runtime: Rework pm_runtime_force_suspend/resume()
One of the limitations of pm_runtime_force_suspend/resume() is that
if a parent driver wants to use these functions, all of its child
drivers generally have to do that too because of the parent usage
counter manipulations necessary to get the correct state of the parent
during system-wide transitions to the working state (system resume).
However, that limitation turns out to be artificial, so remove it.
Namely, pm_runtime_force_suspend() only needs to update the children
counter of its parent (if there's is a parent) when the device can
stay in suspend after the subsequent system resume transition, as
that counter is correct already otherwise. Now, if the parent's
children counter is not updated, it is not necessary to increment
the parent's usage counter in that case any more, as long as the
children counters of devices are checked along with their usage
counters in order to decide whether or not the devices may be left
in suspend after the subsequent system resume transition.
Accordingly, modify pm_runtime_force_suspend() to only call
pm_runtime_set_suspended() for devices whose usage and children
counters are at the "no references" level (the runtime PM status
of the device needs to be updated to "suspended" anyway in case
this function is called once again for the same device during the
transition under way), drop the parent usage counter incrementation
from it and update pm_runtime_force_resume() to compensate for these
changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-01-12 14:12:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-16 09:01:27 +01:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
PM: Check power.needs_force_resume in pm_runtime_force_suspend()
Add a power.needs_force_resume check to pm_runtime_force_suspend() so
it need not rely on the runtime PM status of the device when deciding
whether or not to return early.
With the new check in place, pm_runtime_force_suspend() will also skip
devices with the runtime PM status equal to RPM_ACTIVE if they have
power.needs_force_resume set, so it won't need to change the RPM
status of the device to RPM_SUSPENDED in addition to setting
power.needs_force_resume in the case when pm_runtime_need_not_resume()
return false.
That allows the runtime PM status update to be removed from
pm_runtime_force_resume(), so the runtime PM status remains unchanged
between the pm_runtime_force_suspend() and pm_runtime_force_resume()
calls.
This change potentially unbreaks drivers that call pm_runtime_force_suspend()
from their ->remove() callbacks because currently, if the device being
unbound from its driver has a parent with enabled runtime PM and/or
(possibly) device links respecting runtime PM to suppliers, and it is
RPM_ACTIVE when the remove takes place, pm_runtime_force_suspend() will
not drop the parent's child count and the suppliers' runtime PM usage
counters after force-suspending the device unless pm_runtime_need_not_resume()
returns 'true' for it. Moreover, because pm_runtime_force_suspend()
changes the device's runtime PM status to RPM_SUSPENDED, in the above
case pm_runtime_reinit() will not cause those counters to drop, so they
will remain nonzero forever effectively preventing the devices in
question from runtime-suspending going forward.
This change is also needed for pm_runtime_force_suspend() to work
with PCI PM and ACPI PM after subsequent changes. Namely, say
DPM_FLAG_SMART_SUSPEND is set for a PCI device and its driver uses
pm_runtime_force_suspend() as its ->suspend() callback. If
pm_runtime_force_suspend() changed the runtime PM status of the
device to RPM_SUSPENDED, pci_pm_suspend_noirq() would skip the
device due to the dev_pm_skip_suspend() check.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/1855933.VLH7GnMWUR@rjwysocki.net
2025-06-27 21:19:31 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
PM: sleep: Add strict_midlayer flag to struct dev_pm_info
Add a new flag, called strict_midlayer, to struct dev_pm_info, along
with helper functions for updating and reading its value, to allow
middle layer code that provides proper callbacks for device suspend-
resume during system-wide PM transitions to let pm_runtime_force_suspend()
and and pm_runtime_force_resume() know that they should only invoke
runtime PM callbacks coming from the device's driver.
Namely, if this flag is set, pm_runtime_force_suspend() and
and pm_runtime_force_resume() will invoke runtime PM callbacks
provided by the device's driver directly with the assumption that
they have been called via a middle layer callback for device suspend
or resume, respectively.
For instance, acpi_general_pm_domain provides specific
callback functions for system suspend, acpi_subsys_suspend(),
acpi_subsys_suspend_late() and acpi_subsys_suspend_noirq(), and
it does not expect its runtime suspend callback function,
acpi_subsys_runtime_suspend(), to be invoked at any point during
system suspend. In particular, it does not expect that function
to be called from within any of the system suspend callback functions
mentioned above which would happen if a device driver collaborating
with acpi_general_pm_domain used pm_runtime_force_suspend() as its
callback function for any system suspend phase later than "prepare".
The new flag allows this expectation of acpi_general_pm_domain to
be formally expressed, which is going to be done subsequently.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/24017035.6Emhk5qWAg@rjwysocki.net
2025-06-27 21:23:42 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2022-06-08 17:31:20 +02:00
|
|
|
|
2018-01-16 09:01:27 +01:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-08 17:31:20 +02:00
|
|
|
|
|
|
|
|
|
2016-10-13 16:58:54 +02:00
|
|
|
|
PM / runtime: Rework pm_runtime_force_suspend/resume()
One of the limitations of pm_runtime_force_suspend/resume() is that
if a parent driver wants to use these functions, all of its child
drivers generally have to do that too because of the parent usage
counter manipulations necessary to get the correct state of the parent
during system-wide transitions to the working state (system resume).
However, that limitation turns out to be artificial, so remove it.
Namely, pm_runtime_force_suspend() only needs to update the children
counter of its parent (if there's is a parent) when the device can
stay in suspend after the subsequent system resume transition, as
that counter is correct already otherwise. Now, if the parent's
children counter is not updated, it is not necessary to increment
the parent's usage counter in that case any more, as long as the
children counters of devices are checked along with their usage
counters in order to decide whether or not the devices may be left
in suspend after the subsequent system resume transition.
Accordingly, modify pm_runtime_force_suspend() to only call
pm_runtime_set_suspended() for devices whose usage and children
counters are at the "no references" level (the runtime PM status
of the device needs to be updated to "suspended" anyway in case
this function is called once again for the same device during the
transition under way), drop the parent usage counter incrementation
from it and update pm_runtime_force_resume() to compensate for these
changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-01-12 14:12:05 +01:00
|
|
|
|
|
|
|
|
|
PM: Check power.needs_force_resume in pm_runtime_force_suspend()
Add a power.needs_force_resume check to pm_runtime_force_suspend() so
it need not rely on the runtime PM status of the device when deciding
whether or not to return early.
With the new check in place, pm_runtime_force_suspend() will also skip
devices with the runtime PM status equal to RPM_ACTIVE if they have
power.needs_force_resume set, so it won't need to change the RPM
status of the device to RPM_SUSPENDED in addition to setting
power.needs_force_resume in the case when pm_runtime_need_not_resume()
return false.
That allows the runtime PM status update to be removed from
pm_runtime_force_resume(), so the runtime PM status remains unchanged
between the pm_runtime_force_suspend() and pm_runtime_force_resume()
calls.
This change potentially unbreaks drivers that call pm_runtime_force_suspend()
from their ->remove() callbacks because currently, if the device being
unbound from its driver has a parent with enabled runtime PM and/or
(possibly) device links respecting runtime PM to suppliers, and it is
RPM_ACTIVE when the remove takes place, pm_runtime_force_suspend() will
not drop the parent's child count and the suppliers' runtime PM usage
counters after force-suspending the device unless pm_runtime_need_not_resume()
returns 'true' for it. Moreover, because pm_runtime_force_suspend()
changes the device's runtime PM status to RPM_SUSPENDED, in the above
case pm_runtime_reinit() will not cause those counters to drop, so they
will remain nonzero forever effectively preventing the devices in
question from runtime-suspending going forward.
This change is also needed for pm_runtime_force_suspend() to work
with PCI PM and ACPI PM after subsequent changes. Namely, say
DPM_FLAG_SMART_SUSPEND is set for a PCI device and its driver uses
pm_runtime_force_suspend() as its ->suspend() callback. If
pm_runtime_force_suspend() changed the runtime PM status of the
device to RPM_SUSPENDED, pci_pm_suspend_noirq() would skip the
device due to the dev_pm_skip_suspend() check.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/1855933.VLH7GnMWUR@rjwysocki.net
2025-06-27 21:19:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-13 16:58:54 +02:00
|
|
|
|
PM: Check power.needs_force_resume in pm_runtime_force_suspend()
Add a power.needs_force_resume check to pm_runtime_force_suspend() so
it need not rely on the runtime PM status of the device when deciding
whether or not to return early.
With the new check in place, pm_runtime_force_suspend() will also skip
devices with the runtime PM status equal to RPM_ACTIVE if they have
power.needs_force_resume set, so it won't need to change the RPM
status of the device to RPM_SUSPENDED in addition to setting
power.needs_force_resume in the case when pm_runtime_need_not_resume()
return false.
That allows the runtime PM status update to be removed from
pm_runtime_force_resume(), so the runtime PM status remains unchanged
between the pm_runtime_force_suspend() and pm_runtime_force_resume()
calls.
This change potentially unbreaks drivers that call pm_runtime_force_suspend()
from their ->remove() callbacks because currently, if the device being
unbound from its driver has a parent with enabled runtime PM and/or
(possibly) device links respecting runtime PM to suppliers, and it is
RPM_ACTIVE when the remove takes place, pm_runtime_force_suspend() will
not drop the parent's child count and the suppliers' runtime PM usage
counters after force-suspending the device unless pm_runtime_need_not_resume()
returns 'true' for it. Moreover, because pm_runtime_force_suspend()
changes the device's runtime PM status to RPM_SUSPENDED, in the above
case pm_runtime_reinit() will not cause those counters to drop, so they
will remain nonzero forever effectively preventing the devices in
question from runtime-suspending going forward.
This change is also needed for pm_runtime_force_suspend() to work
with PCI PM and ACPI PM after subsequent changes. Namely, say
DPM_FLAG_SMART_SUSPEND is set for a PCI device and its driver uses
pm_runtime_force_suspend() as its ->suspend() callback. If
pm_runtime_force_suspend() changed the runtime PM status of the
device to RPM_SUSPENDED, pci_pm_suspend_noirq() would skip the
device due to the dev_pm_skip_suspend() check.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/1855933.VLH7GnMWUR@rjwysocki.net
2025-06-27 21:19:31 +02:00
|
|
|
|
PM / runtime: Rework pm_runtime_force_suspend/resume()
One of the limitations of pm_runtime_force_suspend/resume() is that
if a parent driver wants to use these functions, all of its child
drivers generally have to do that too because of the parent usage
counter manipulations necessary to get the correct state of the parent
during system-wide transitions to the working state (system resume).
However, that limitation turns out to be artificial, so remove it.
Namely, pm_runtime_force_suspend() only needs to update the children
counter of its parent (if there's is a parent) when the device can
stay in suspend after the subsequent system resume transition, as
that counter is correct already otherwise. Now, if the parent's
children counter is not updated, it is not necessary to increment
the parent's usage counter in that case any more, as long as the
children counters of devices are checked along with their usage
counters in order to decide whether or not the devices may be left
in suspend after the subsequent system resume transition.
Accordingly, modify pm_runtime_force_suspend() to only call
pm_runtime_set_suspended() for devices whose usage and children
counters are at the "no references" level (the runtime PM status
of the device needs to be updated to "suspended" anyway in case
this function is called once again for the same device during the
transition under way), drop the parent usage counter incrementation
from it and update pm_runtime_force_resume() to compensate for these
changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-01-12 14:12:05 +01:00
|
|
|
|
PM: Check power.needs_force_resume in pm_runtime_force_suspend()
Add a power.needs_force_resume check to pm_runtime_force_suspend() so
it need not rely on the runtime PM status of the device when deciding
whether or not to return early.
With the new check in place, pm_runtime_force_suspend() will also skip
devices with the runtime PM status equal to RPM_ACTIVE if they have
power.needs_force_resume set, so it won't need to change the RPM
status of the device to RPM_SUSPENDED in addition to setting
power.needs_force_resume in the case when pm_runtime_need_not_resume()
return false.
That allows the runtime PM status update to be removed from
pm_runtime_force_resume(), so the runtime PM status remains unchanged
between the pm_runtime_force_suspend() and pm_runtime_force_resume()
calls.
This change potentially unbreaks drivers that call pm_runtime_force_suspend()
from their ->remove() callbacks because currently, if the device being
unbound from its driver has a parent with enabled runtime PM and/or
(possibly) device links respecting runtime PM to suppliers, and it is
RPM_ACTIVE when the remove takes place, pm_runtime_force_suspend() will
not drop the parent's child count and the suppliers' runtime PM usage
counters after force-suspending the device unless pm_runtime_need_not_resume()
returns 'true' for it. Moreover, because pm_runtime_force_suspend()
changes the device's runtime PM status to RPM_SUSPENDED, in the above
case pm_runtime_reinit() will not cause those counters to drop, so they
will remain nonzero forever effectively preventing the devices in
question from runtime-suspending going forward.
This change is also needed for pm_runtime_force_suspend() to work
with PCI PM and ACPI PM after subsequent changes. Namely, say
DPM_FLAG_SMART_SUSPEND is set for a PCI device and its driver uses
pm_runtime_force_suspend() as its ->suspend() callback. If
pm_runtime_force_suspend() changed the runtime PM status of the
device to RPM_SUSPENDED, pci_pm_suspend_noirq() would skip the
device due to the dev_pm_skip_suspend() check.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/1855933.VLH7GnMWUR@rjwysocki.net
2025-06-27 21:19:31 +02:00
|
|
|
|
2025-06-27 21:06:34 +02:00
|
|
|
|
2016-10-13 16:58:54 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
PM / runtime: Rework pm_runtime_force_suspend/resume()
One of the limitations of pm_runtime_force_suspend/resume() is that
if a parent driver wants to use these functions, all of its child
drivers generally have to do that too because of the parent usage
counter manipulations necessary to get the correct state of the parent
during system-wide transitions to the working state (system resume).
However, that limitation turns out to be artificial, so remove it.
Namely, pm_runtime_force_suspend() only needs to update the children
counter of its parent (if there's is a parent) when the device can
stay in suspend after the subsequent system resume transition, as
that counter is correct already otherwise. Now, if the parent's
children counter is not updated, it is not necessary to increment
the parent's usage counter in that case any more, as long as the
children counters of devices are checked along with their usage
counters in order to decide whether or not the devices may be left
in suspend after the subsequent system resume transition.
Accordingly, modify pm_runtime_force_suspend() to only call
pm_runtime_set_suspended() for devices whose usage and children
counters are at the "no references" level (the runtime PM status
of the device needs to be updated to "suspended" anyway in case
this function is called once again for the same device during the
transition under way), drop the parent usage counter incrementation
from it and update pm_runtime_force_resume() to compensate for these
changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-01-12 14:12:05 +01:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2022-06-08 17:31:20 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-27 21:08:48 +02:00
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2016-10-13 16:58:54 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
2025-06-27 21:15:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2025-06-27 21:15:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-27 21:15:59 +02:00
|
|
|
|
|
|
|
|
|
2016-05-30 11:33:12 +02:00
|
|
|
|
|
|
|
|
|
PM: sleep: Add strict_midlayer flag to struct dev_pm_info
Add a new flag, called strict_midlayer, to struct dev_pm_info, along
with helper functions for updating and reading its value, to allow
middle layer code that provides proper callbacks for device suspend-
resume during system-wide PM transitions to let pm_runtime_force_suspend()
and and pm_runtime_force_resume() know that they should only invoke
runtime PM callbacks coming from the device's driver.
Namely, if this flag is set, pm_runtime_force_suspend() and
and pm_runtime_force_resume() will invoke runtime PM callbacks
provided by the device's driver directly with the assumption that
they have been called via a middle layer callback for device suspend
or resume, respectively.
For instance, acpi_general_pm_domain provides specific
callback functions for system suspend, acpi_subsys_suspend(),
acpi_subsys_suspend_late() and acpi_subsys_suspend_noirq(), and
it does not expect its runtime suspend callback function,
acpi_subsys_runtime_suspend(), to be invoked at any point during
system suspend. In particular, it does not expect that function
to be called from within any of the system suspend callback functions
mentioned above which would happen if a device driver collaborating
with acpi_general_pm_domain used pm_runtime_force_suspend() as its
callback function for any system suspend phase later than "prepare".
The new flag allows this expectation of acpi_general_pm_domain to
be formally expressed, which is going to be done subsequently.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/24017035.6Emhk5qWAg@rjwysocki.net
2025-06-27 21:23:42 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2022-06-08 17:31:20 +02:00
|
|
|
|
2018-01-16 09:01:27 +01:00
|
|
|
|
2016-04-08 13:10:23 +02:00
|
|
|
|
|
|
|
|
|
2022-06-08 17:31:20 +02:00
|
|
|
|
2016-04-08 13:10:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2025-06-27 21:15:59 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
2025-06-27 21:15:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-27 21:06:34 +02:00
|
|
|
|
2025-06-27 21:15:59 +02:00
|
|
|
|
2014-03-01 11:56:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-27 21:08:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
