Skip to content

Commit edb7f9d

Browse files
rafaeljwrafaeljw
committed
Merge back system-wide PM updates for v5.8.
2 parents 09beebd + 2fff3f7 commit edb7f9d

File tree

19 files changed

+294
-396
lines changed

19 files changed

+294
-396
lines changed

‎Documentation/driver-api/pm/devices.rst

Lines changed: 95 additions & 50 deletions
Original file line numberDiff line numberDiff line change
@@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``.
361361
runtime PM disabled.
362362

363363
This feature also can be controlled by device drivers by using the
364-
``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power
365-
management flags. [Typically, they are set at the time the driver is
366-
probed against the device in question by passing them to the
364+
``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver
365+
power management flags. [Typically, they are set at the time the driver
366+
is probed against the device in question by passing them to the
367367
:c:func:`dev_pm_set_driver_flags` helper function.] If the first of
368368
these flags is set, the PM core will not apply the direct-complete
369369
procedure described above to the given device and, consequenty, to any
@@ -772,62 +772,107 @@ the state of devices (possibly except for resuming them from runtime suspend)
772772
from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before*
773773
invoking device drivers' ``->suspend`` callbacks (or equivalent).
774774

775+
.. _smart_suspend_flag:
776+
777+
The ``DPM_FLAG_SMART_SUSPEND`` Driver Flag
778+
------------------------------------------
779+
775780
Some bus types and PM domains have a policy to resume all devices from runtime
776781
suspend upfront in their ``->suspend`` callbacks, but that may not be really
777782
necessary if the driver of the device can cope with runtime-suspended devices.
778783
The driver can indicate that by setting ``DPM_FLAG_SMART_SUSPEND`` in
779-
:c:member:`power.driver_flags` at the probe time, by passing it to the
780-
:c:func:`dev_pm_set_driver_flags` helper. That also may cause middle-layer code
784+
:c:member:`power.driver_flags` at the probe time with the help of the
785+
:c:func:`dev_pm_set_driver_flags` helper routine.
786+
787+
However, setting that flag also causes the PM core and middle-layer code
781788
(bus types, PM domains etc.) to skip the ``->suspend_late`` and
782789
``->suspend_noirq`` callbacks provided by the driver if the device remains in
783-
runtime suspend at the beginning of the ``suspend_late`` phase of system-wide
784-
suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM
785-
has been disabled for it, under the assumption that its state should not change
786-
after that point until the system-wide transition is over (the PM core itself
787-
does that for devices whose "noirq", "late" and "early" system-wide PM callbacks
788-
are executed directly by it). If that happens, the driver's system-wide resume
789-
callbacks, if present, may still be invoked during the subsequent system-wide
790-
resume transition and the device's runtime power management status may be set
791-
to "active" before enabling runtime PM for it, so the driver must be prepared to
792-
cope with the invocation of its system-wide resume callbacks back-to-back with
793-
its ``->runtime_suspend`` one (without the intervening ``->runtime_resume`` and
794-
so on) and the final state of the device must reflect the "active" runtime PM
795-
status in that case.
790+
runtime suspend during the ``suspend_late`` phase of system-wide suspend (or
791+
during the ``poweroff_late`` or ``freeze_late`` phase of hibernation),
792+
after runtime PM was disabled for it. [Without doing that, the same driver
793+
callback might be executed twice in a row for the same device, which would not
794+
be valid in general.] If the middle-layer system-wide PM callbacks are present
795+
for the device, they are responsible for doing the above, and the PM core takes
796+
care of it otherwise.
797+
798+
In addition, with ``DPM_FLAG_SMART_SUSPEND`` set, the driver's ``->thaw_late``
799+
and ``->thaw_noirq`` callbacks are skipped if the device remained in runtime
800+
suspend during the preceding "freeze" transition related to hibernation.
801+
Again, if the middle-layer callbacks are present for the device, they are
802+
responsible for doing that, or the PM core takes care of it otherwise.
803+
804+
805+
The ``DPM_FLAG_MAY_SKIP_RESUME`` Driver Flag
806+
--------------------------------------------
796807

797808
During system-wide resume from a sleep state it's easiest to put devices into
798809
the full-power state, as explained in :file:`Documentation/power/runtime_pm.rst`.
799810
[Refer to that document for more information regarding this particular issue as
800811
well as for information on the device runtime power management framework in
801-
general.]
802-
803-
However, it often is desirable to leave devices in suspend after system
804-
transitions to the working state, especially if those devices had been in
812+
general.] However, it often is desirable to leave devices in suspend after
813+
system transitions to the working state, especially if those devices had been in
805814
runtime suspend before the preceding system-wide suspend (or analogous)
806-
transition. Device drivers can use the ``DPM_FLAG_LEAVE_SUSPENDED`` flag to
807-
indicate to the PM core (and middle-layer code) that they prefer the specific
808-
devices handled by them to be left suspended and they have no problems with
809-
skipping their system-wide resume callbacks for this reason. Whether or not the
810-
devices will actually be left in suspend may depend on their state before the
811-
given system suspend-resume cycle and on the type of the system transition under
812-
way. In particular, devices are not left suspended if that transition is a
813-
restore from hibernation, as device states are not guaranteed to be reflected
814-
by the information stored in the hibernation image in that case.
815-
816-
The middle-layer code involved in the handling of the device is expected to
817-
indicate to the PM core if the device may be left in suspend by setting its
818-
:c:member:`power.may_skip_resume` status bit which is checked by the PM core
819-
during the "noirq" phase of the preceding system-wide suspend (or analogous)
820-
transition. The middle layer is then responsible for handling the device as
821-
appropriate in its "noirq" resume callback, which is executed regardless of
822-
whether or not the device is left suspended, but the other resume callbacks
823-
(except for ``->complete``) will be skipped automatically by the PM core if the
824-
device really can be left in suspend.
825-
826-
For devices whose "noirq", "late" and "early" driver callbacks are invoked
827-
directly by the PM core, all of the system-wide resume callbacks are skipped if
828-
``DPM_FLAG_LEAVE_SUSPENDED`` is set and the device is in runtime suspend during
829-
the ``suspend_noirq`` (or analogous) phase or the transition under way is a
830-
proper system suspend (rather than anything related to hibernation) and the
831-
device's wakeup settings are suitable for runtime PM (that is, it cannot
832-
generate wakeup signals at all or it is allowed to wake up the system from
833-
sleep).
815+
transition.
816+
817+
To that end, device drivers can use the ``DPM_FLAG_MAY_SKIP_RESUME`` flag to
818+
indicate to the PM core and middle-layer code that they allow their "noirq" and
819+
"early" resume callbacks to be skipped if the device can be left in suspend
820+
after system-wide PM transitions to the working state. Whether or not that is
821+
the case generally depends on the state of the device before the given system
822+
suspend-resume cycle and on the type of the system transition under way.
823+
In particular, the "restore" and "thaw" transitions related to hibernation are
824+
not affected by ``DPM_FLAG_MAY_SKIP_RESUME`` at all. [All devices are always
825+
resumed during the "restore" transition and whether or not any driver callbacks
826+
are skipped during the "freeze" transition depends whether or not the
827+
``DPM_FLAG_SMART_SUSPEND`` flag is set (see `above <smart_suspend_flag_>`_).]
828+
829+
The ``DPM_FLAG_MAY_SKIP_RESUME`` flag is taken into account in combination with
830+
the :c:member:`power.may_skip_resume` status bit set by the PM core during the
831+
"suspend" phase of suspend-type transitions. If the driver or the middle layer
832+
has a reason to prevent the driver's "noirq" and "early" resume callbacks from
833+
being skipped during the subsequent resume transition of the system, it should
834+
clear :c:member:`power.may_skip_resume` in its ``->suspend``, ``->suspend_late``
835+
or ``->suspend_noirq`` callback. [Note that the drivers setting
836+
``DPM_FLAG_SMART_SUSPEND`` need to clear :c:member:`power.may_skip_resume` in
837+
their ``->suspend`` callback in case the other two are skipped.]
838+
839+
Setting the :c:member:`power.may_skip_resume` status bit along with the
840+
``DPM_FLAG_MAY_SKIP_RESUME`` flag is necessary, but generally not sufficient,
841+
for the driver's "noirq" and "early" resume callbacks to be skipped. Whether or
842+
not they should be skipped can be determined by evaluating the
843+
:c:func:`dev_pm_skip_resume` helper function.
844+
845+
If that function returns ``true``, the driver's "noirq" and "early" resume
846+
callbacks should be skipped and the device's runtime PM status will be set to
847+
"suspended" by the PM core. Otherwise, if the device was runtime-suspended
848+
during the preceding system-wide suspend transition and
849+
``DPM_FLAG_SMART_SUSPEND`` is set for it, its runtime PM status will be set to
850+
"active" by the PM core. [Hence, the drivers that do not set
851+
``DPM_FLAG_SMART_SUSPEND`` should not expect the runtime PM status of their
852+
devices to be changed from "suspended" to "active" by the PM core during
853+
system-wide resume-type transitions.]
854+
855+
If the ``DPM_FLAG_MAY_SKIP_RESUME`` flag is not set for a device, but
856+
``DPM_FLAG_SMART_SUSPEND`` is set and the driver's "late" and "noirq" suspend
857+
callbacks are skipped, its system-wide "noirq" and "early" resume callbacks, if
858+
present, are invoked as usual and the device's runtime PM status is set to
859+
"active" by the PM core before enabling runtime PM for it. In that case, the
860+
driver must be prepared to cope with the invocation of its system-wide resume
861+
callbacks back-to-back with its ``->runtime_suspend`` one (without the
862+
intervening ``->runtime_resume`` and system-wide suspend callbacks) and the
863+
final state of the device must reflect the "active" runtime PM status in that
864+
case. [Note that this is not a problem at all if the driver's
865+
``->suspend_late`` callback pointer points to the same function as its
866+
``->runtime_suspend`` one and its ``->resume_early`` callback pointer points to
867+
the same function as the ``->runtime_resume`` one, while none of the other
868+
system-wide suspend-resume callbacks of the driver are present, for example.]
869+
870+
Likewise, if ``DPM_FLAG_MAY_SKIP_RESUME`` is set for a device, its driver's
871+
system-wide "noirq" and "early" resume callbacks may be skipped while its "late"
872+
and "noirq" suspend callbacks may have been executed (in principle, regardless
873+
of whether or not ``DPM_FLAG_SMART_SUSPEND`` is set). In that case, the driver
874+
needs to be able to cope with the invocation of its ``->runtime_resume``
875+
callback back-to-back with its "late" and "noirq" suspend ones. [For instance,
876+
that is not a concern if the driver sets both ``DPM_FLAG_SMART_SUSPEND`` and
877+
``DPM_FLAG_MAY_SKIP_RESUME`` and uses the same pair of suspend/resume callback
878+
functions for runtime PM and system-wide suspend/resume.]

‎Documentation/power/pci.rst

Lines changed: 28 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -1004,41 +1004,39 @@ including the PCI bus type. The flags should be set once at the driver probe
10041004
time with the help of the dev_pm_set_driver_flags() function and they should not
10051005
be updated directly afterwards.
10061006

1007-
The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the direct-complete
1008-
mechanism allowing device suspend/resume callbacks to be skipped if the device
1009-
is in runtime suspend when the system suspend starts. That also affects all of
1010-
the ancestors of the device, so this flag should only be used if absolutely
1011-
necessary.
1012-
1013-
The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a
1014-
positive value from pci_pm_prepare() if the ->prepare callback provided by the
1007+
The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
1008+
direct-complete mechanism allowing device suspend/resume callbacks to be skipped
1009+
if the device is in runtime suspend when the system suspend starts. That also
1010+
affects all of the ancestors of the device, so this flag should only be used if
1011+
absolutely necessary.
1012+
1013+
The DPM_FLAG_SMART_PREPARE flag causes the PCI bus type to return a positive
1014+
value from pci_pm_prepare() only if the ->prepare callback provided by the
10151015
driver of the device returns a positive value. That allows the driver to opt
1016-
out from using the direct-complete mechanism dynamically.
1016+
out from using the direct-complete mechanism dynamically (whereas setting
1017+
DPM_FLAG_NO_DIRECT_COMPLETE means permanent opt-out).
10171018

10181019
The DPM_FLAG_SMART_SUSPEND flag tells the PCI bus type that from the driver's
10191020
perspective the device can be safely left in runtime suspend during system
10201021
suspend. That causes pci_pm_suspend(), pci_pm_freeze() and pci_pm_poweroff()
1021-
to skip resuming the device from runtime suspend unless there are PCI-specific
1022-
reasons for doing that. Also, it causes pci_pm_suspend_late/noirq(),
1023-
pci_pm_freeze_late/noirq() and pci_pm_poweroff_late/noirq() to return early
1024-
if the device remains in runtime suspend in the beginning of the "late" phase
1025-
of the system-wide transition under way. Moreover, if the device is in
1026-
runtime suspend in pci_pm_resume_noirq() or pci_pm_restore_noirq(), its runtime
1027-
power management status will be changed to "active" (as it is going to be put
1028-
into D0 going forward), but if it is in runtime suspend in pci_pm_thaw_noirq(),
1029-
the function will set the power.direct_complete flag for it (to make the PM core
1030-
skip the subsequent "thaw" callbacks for it) and return.
1031-
1032-
Setting the DPM_FLAG_LEAVE_SUSPENDED flag means that the driver prefers the
1033-
device to be left in suspend after system-wide transitions to the working state.
1034-
This flag is checked by the PM core, but the PCI bus type informs the PM core
1035-
which devices may be left in suspend from its perspective (that happens during
1036-
the "noirq" phase of system-wide suspend and analogous transitions) and next it
1037-
uses the dev_pm_may_skip_resume() helper to decide whether or not to return from
1038-
pci_pm_resume_noirq() early, as the PM core will skip the remaining resume
1039-
callbacks for the device during the transition under way and will set its
1040-
runtime PM status to "suspended" if dev_pm_may_skip_resume() returns "true" for
1041-
it.
1022+
to avoid resuming the device from runtime suspend unless there are PCI-specific
1023+
reasons for doing that. Also, it causes pci_pm_suspend_late/noirq() and
1024+
pci_pm_poweroff_late/noirq() to return early if the device remains in runtime
1025+
suspend during the "late" phase of the system-wide transition under way.
1026+
Moreover, if the device is in runtime suspend in pci_pm_resume_noirq() or
1027+
pci_pm_restore_noirq(), its runtime PM status will be changed to "active" (as it
1028+
is going to be put into D0 going forward).
1029+
1030+
Setting the DPM_FLAG_MAY_SKIP_RESUME flag means that the driver allows its
1031+
"noirq" and "early" resume callbacks to be skipped if the device can be left
1032+
in suspend after a system-wide transition into the working state. This flag is
1033+
taken into consideration by the PM core along with the power.may_skip_resume
1034+
status bit of the device which is set by pci_pm_suspend_noirq() in certain
1035+
situations. If the PM core determines that the driver's "noirq" and "early"
1036+
resume callbacks should be skipped, the dev_pm_skip_resume() helper function
1037+
will return "true" and that will cause pci_pm_resume_noirq() and
1038+
pci_pm_resume_early() to return upfront without touching the device and
1039+
executing the driver callbacks.
10421040

10431041
3.2. Device Runtime Power Management
10441042
------------------------------------

‎drivers/acpi/acpi_lpss.c

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1041,7 +1041,7 @@ static int acpi_lpss_do_suspend_late(struct device *dev)
10411041
{
10421042
int ret;
10431043

1044-
if (dev_pm_smart_suspend_and_suspended(dev))
1044+
if (dev_pm_skip_suspend(dev))
10451045
return 0;
10461046

10471047
ret = pm_generic_suspend_late(dev);
@@ -1093,6 +1093,9 @@ static int acpi_lpss_resume_early(struct device *dev)
10931093
if (pdata->dev_desc->resume_from_noirq)
10941094
return 0;
10951095

1096+
if (dev_pm_skip_resume(dev))
1097+
return 0;
1098+
10961099
return acpi_lpss_do_resume_early(dev);
10971100
}
10981101

@@ -1102,12 +1105,9 @@ static int acpi_lpss_resume_noirq(struct device *dev)
11021105
int ret;
11031106

11041107
/* Follow acpi_subsys_resume_noirq(). */
1105-
if (dev_pm_may_skip_resume(dev))
1108+
if (dev_pm_skip_resume(dev))
11061109
return 0;
11071110

1108-
if (dev_pm_smart_suspend_and_suspended(dev))
1109-
pm_runtime_set_active(dev);
1110-
11111111
ret = pm_generic_resume_noirq(dev);
11121112
if (ret)
11131113
return ret;
@@ -1169,7 +1169,7 @@ static int acpi_lpss_poweroff_late(struct device *dev)
11691169
{
11701170
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
11711171

1172-
if (dev_pm_smart_suspend_and_suspended(dev))
1172+
if (dev_pm_skip_suspend(dev))
11731173
return 0;
11741174

11751175
if (pdata->dev_desc->resume_from_noirq)
@@ -1182,7 +1182,7 @@ static int acpi_lpss_poweroff_noirq(struct device *dev)
11821182
{
11831183
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
11841184

1185-
if (dev_pm_smart_suspend_and_suspended(dev))
1185+
if (dev_pm_skip_suspend(dev))
11861186
return 0;
11871187

11881188
if (pdata->dev_desc->resume_from_noirq) {

‎drivers/acpi/acpi_tad.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -624,7 +624,7 @@ static int acpi_tad_probe(struct platform_device *pdev)
624624
*/
625625
device_init_wakeup(dev, true);
626626
dev_pm_set_driver_flags(dev, DPM_FLAG_SMART_SUSPEND |
627-
DPM_FLAG_LEAVE_SUSPENDED);
627+
DPM_FLAG_MAY_SKIP_RESUME);
628628
/*
629629
* The platform bus type layer tells the ACPI PM domain powers up the
630630
* device, so set the runtime PM status of it to "active".

‎drivers/acpi/device_pm.c

Lines changed: 13 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1084,7 +1084,7 @@ int acpi_subsys_suspend_late(struct device *dev)
10841084
{
10851085
int ret;
10861086

1087-
if (dev_pm_smart_suspend_and_suspended(dev))
1087+
if (dev_pm_skip_suspend(dev))
10881088
return 0;
10891089

10901090
ret = pm_generic_suspend_late(dev);
@@ -1100,10 +1100,8 @@ int acpi_subsys_suspend_noirq(struct device *dev)
11001100
{
11011101
int ret;
11021102

1103-
if (dev_pm_smart_suspend_and_suspended(dev)) {
1104-
dev->power.may_skip_resume = true;
1103+
if (dev_pm_skip_suspend(dev))
11051104
return 0;
1106-
}
11071105

11081106
ret = pm_generic_suspend_noirq(dev);
11091107
if (ret)
@@ -1116,8 +1114,8 @@ int acpi_subsys_suspend_noirq(struct device *dev)
11161114
* acpi_subsys_complete() to take care of fixing up the device's state
11171115
* anyway, if need be.
11181116
*/
1119-
dev->power.may_skip_resume = device_may_wakeup(dev) ||
1120-
!device_can_wakeup(dev);
1117+
if (device_can_wakeup(dev) && !device_may_wakeup(dev))
1118+
dev->power.may_skip_resume = false;
11211119

11221120
return 0;
11231121
}
@@ -1129,17 +1127,9 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend_noirq);
11291127
*/
11301128
static int acpi_subsys_resume_noirq(struct device *dev)
11311129
{
1132-
if (dev_pm_may_skip_resume(dev))
1130+
if (dev_pm_skip_resume(dev))
11331131
return 0;
11341132

1135-
/*
1136-
* Devices with DPM_FLAG_SMART_SUSPEND may be left in runtime suspend
1137-
* during system suspend, so update their runtime PM status to "active"
1138-
* as they will be put into D0 going forward.
1139-
*/
1140-
if (dev_pm_smart_suspend_and_suspended(dev))
1141-
pm_runtime_set_active(dev);
1142-
11431133
return pm_generic_resume_noirq(dev);
11441134
}
11451135

@@ -1153,7 +1143,12 @@ static int acpi_subsys_resume_noirq(struct device *dev)
11531143
*/
11541144
static int acpi_subsys_resume_early(struct device *dev)
11551145
{
1156-
int ret = acpi_dev_resume(dev);
1146+
int ret;
1147+
1148+
if (dev_pm_skip_resume(dev))
1149+
return 0;
1150+
1151+
ret = acpi_dev_resume(dev);
11571152
return ret ? ret : pm_generic_resume_early(dev);
11581153
}
11591154

@@ -1218,7 +1213,7 @@ static int acpi_subsys_poweroff_late(struct device *dev)
12181213
{
12191214
int ret;
12201215

1221-
if (dev_pm_smart_suspend_and_suspended(dev))
1216+
if (dev_pm_skip_suspend(dev))
12221217
return 0;
12231218

12241219
ret = pm_generic_poweroff_late(dev);
@@ -1234,7 +1229,7 @@ static int acpi_subsys_poweroff_late(struct device *dev)
12341229
*/
12351230
static int acpi_subsys_poweroff_noirq(struct device *dev)
12361231
{
1237-
if (dev_pm_smart_suspend_and_suspended(dev))
1232+
if (dev_pm_skip_suspend(dev))
12381233
return 0;
12391234

12401235
return pm_generic_poweroff_noirq(dev);

0 commit comments

Comments
 (0)