Skip to content

Commit 769fced

Browse files
committed
treewide: Remove redundant
Merge series from Sakari Ailus <[email protected]>: Late last year I posted a set to switch to __pm_runtime_mark_last_busy() and gradually get rid of explicit pm_runtime_mark_last_busy() calls in drivers, embedding them in the appropriate pm_runtime_*autosuspend*() calls. The overall feedback I got at the time was that this is an unnecessary intermediate step, and removing the pm_runtime_mark_last_busy() calls can be done after adding them to the relevant Runtime PM autosuspend related functions. The latter part has been done and is present in Rafael's tree at the moment, also see <URL:https://lore.kernel.org/linux-pm/CAJZ5v0g7-8UWp6ATOy+=oGdxDaCnfKHBG_+kbiTr+ [email protected]/>: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-runtime-6.17-rc1
2 parents 427ceac + c61e94e commit 769fced

File tree

3 files changed

+186
-57
lines changed

3 files changed

+186
-57
lines changed

Documentation/power/runtime_pm.rst

Lines changed: 23 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -154,11 +154,9 @@ suspending the device are satisfied) and to queue up a suspend request for the
154154
device in that case. If there is no idle callback, or if the callback returns
155155
0, then the PM core will attempt to carry out a runtime suspend of the device,
156156
also respecting devices configured for autosuspend. In essence this means a
157-
call to pm_runtime_autosuspend() (do note that drivers needs to update the
158-
device last busy mark, pm_runtime_mark_last_busy(), to control the delay under
159-
this circumstance). To prevent this (for example, if the callback routine has
160-
started a delayed suspend), the routine must return a non-zero value. Negative
161-
error return codes are ignored by the PM core.
157+
call to pm_runtime_autosuspend(). To prevent this (for example, if the callback
158+
routine has started a delayed suspend), the routine must return a non-zero
159+
value. Negative error return codes are ignored by the PM core.
162160

163161
The helper functions provided by the PM core, described in Section 4, guarantee
164162
that the following constraints are met with respect to runtime PM callbacks for
@@ -330,10 +328,9 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
330328
'power.disable_depth' is different from 0
331329

332330
`int pm_runtime_autosuspend(struct device *dev);`
333-
- same as pm_runtime_suspend() except that the autosuspend delay is taken
334-
`into account;` if pm_runtime_autosuspend_expiration() says the delay has
335-
not yet expired then an autosuspend is scheduled for the appropriate time
336-
and 0 is returned
331+
- same as pm_runtime_suspend() except that a call to
332+
pm_runtime_mark_last_busy() is made and an autosuspend is scheduled for
333+
the appropriate time and 0 is returned
337334

338335
`int pm_runtime_resume(struct device *dev);`
339336
- execute the subsystem-level resume callback for the device; returns 0 on
@@ -357,9 +354,9 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
357354
success or error code if the request has not been queued up
358355

359356
`int pm_request_autosuspend(struct device *dev);`
360-
- schedule the execution of the subsystem-level suspend callback for the
361-
device when the autosuspend delay has expired; if the delay has already
362-
expired then the work item is queued up immediately
357+
- Call pm_runtime_mark_last_busy() and schedule the execution of the
358+
subsystem-level suspend callback for the device when the autosuspend delay
359+
expires
363360

364361
`int pm_schedule_suspend(struct device *dev, unsigned int delay);`
365362
- schedule the execution of the subsystem-level suspend callback for the
@@ -411,8 +408,9 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
411408
pm_request_idle(dev) and return its result
412409

413410
`int pm_runtime_put_autosuspend(struct device *dev);`
414-
- does the same as __pm_runtime_put_autosuspend() for now, but in the
415-
future, will also call pm_runtime_mark_last_busy() as well, DO NOT USE!
411+
- set the power.last_busy field to the current time and decrement the
412+
device's usage counter; if the result is 0 then run
413+
pm_request_autosuspend(dev) and return its result
416414

417415
`int __pm_runtime_put_autosuspend(struct device *dev);`
418416
- decrement the device's usage counter; if the result is 0 then run
@@ -427,7 +425,8 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
427425
pm_runtime_suspend(dev) and return its result
428426

429427
`int pm_runtime_put_sync_autosuspend(struct device *dev);`
430-
- decrement the device's usage counter; if the result is 0 then run
428+
- set the power.last_busy field to the current time and decrement the
429+
device's usage counter; if the result is 0 then run
431430
pm_runtime_autosuspend(dev) and return its result
432431

433432
`void pm_runtime_enable(struct device *dev);`
@@ -870,11 +869,9 @@ device is automatically suspended (the subsystem or driver still has to call
870869
the appropriate PM routines); rather it means that runtime suspends will
871870
automatically be delayed until the desired period of inactivity has elapsed.
872871

873-
Inactivity is determined based on the power.last_busy field. Drivers should
874-
call pm_runtime_mark_last_busy() to update this field after carrying out I/O,
875-
typically just before calling __pm_runtime_put_autosuspend(). The desired
876-
length of the inactivity period is a matter of policy. Subsystems can set this
877-
length initially by calling pm_runtime_set_autosuspend_delay(), but after device
872+
Inactivity is determined based on the power.last_busy field. The desired length
873+
of the inactivity period is a matter of policy. Subsystems can set this length
874+
initially by calling pm_runtime_set_autosuspend_delay(), but after device
878875
registration the length should be controlled by user space, using the
879876
/sys/devices/.../power/autosuspend_delay_ms attribute.
880877

@@ -885,12 +882,13 @@ instead of the non-autosuspend counterparts::
885882

886883
Instead of: pm_runtime_suspend use: pm_runtime_autosuspend;
887884
Instead of: pm_schedule_suspend use: pm_request_autosuspend;
888-
Instead of: pm_runtime_put use: __pm_runtime_put_autosuspend;
885+
Instead of: pm_runtime_put use: pm_runtime_put_autosuspend;
889886
Instead of: pm_runtime_put_sync use: pm_runtime_put_sync_autosuspend.
890887

891888
Drivers may also continue to use the non-autosuspend helper functions; they
892889
will behave normally, which means sometimes taking the autosuspend delay into
893-
account (see pm_runtime_idle).
890+
account (see pm_runtime_idle). The autosuspend variants of the functions also
891+
call pm_runtime_mark_last_busy().
894892

895893
Under some circumstances a driver or subsystem may want to prevent a device
896894
from autosuspending immediately, even though the usage counter is zero and the
@@ -922,12 +920,10 @@ Here is a schematic pseudo-code example::
922920
foo_io_completion(struct foo_priv *foo, void *req)
923921
{
924922
lock(&foo->private_lock);
925-
if (--foo->num_pending_requests == 0) {
926-
pm_runtime_mark_last_busy(&foo->dev);
927-
__pm_runtime_put_autosuspend(&foo->dev);
928-
} else {
923+
if (--foo->num_pending_requests == 0)
924+
pm_runtime_put_autosuspend(&foo->dev);
925+
else
929926
foo_process_next_request(foo);
930-
}
931927
unlock(&foo->private_lock);
932928
/* Send req result back to the user ... */
933929
}

drivers/regulator/stm32-vrefbuf.c

Lines changed: 0 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -67,7 +67,6 @@ static int stm32_vrefbuf_enable(struct regulator_dev *rdev)
6767
writel_relaxed(val, priv->base + STM32_VREFBUF_CSR);
6868
}
6969

70-
pm_runtime_mark_last_busy(priv->dev);
7170
pm_runtime_put_autosuspend(priv->dev);
7271

7372
return ret;
@@ -87,7 +86,6 @@ static int stm32_vrefbuf_disable(struct regulator_dev *rdev)
8786
val &= ~STM32_ENVR;
8887
writel_relaxed(val, priv->base + STM32_VREFBUF_CSR);
8988

90-
pm_runtime_mark_last_busy(priv->dev);
9189
pm_runtime_put_autosuspend(priv->dev);
9290

9391
return 0;
@@ -104,7 +102,6 @@ static int stm32_vrefbuf_is_enabled(struct regulator_dev *rdev)
104102

105103
ret = readl_relaxed(priv->base + STM32_VREFBUF_CSR) & STM32_ENVR;
106104

107-
pm_runtime_mark_last_busy(priv->dev);
108105
pm_runtime_put_autosuspend(priv->dev);
109106

110107
return ret;
@@ -125,7 +122,6 @@ static int stm32_vrefbuf_set_voltage_sel(struct regulator_dev *rdev,
125122
val = (val & ~STM32_VRS) | FIELD_PREP(STM32_VRS, sel);
126123
writel_relaxed(val, priv->base + STM32_VREFBUF_CSR);
127124

128-
pm_runtime_mark_last_busy(priv->dev);
129125
pm_runtime_put_autosuspend(priv->dev);
130126

131127
return 0;
@@ -144,7 +140,6 @@ static int stm32_vrefbuf_get_voltage_sel(struct regulator_dev *rdev)
144140
val = readl_relaxed(priv->base + STM32_VREFBUF_CSR);
145141
ret = FIELD_GET(STM32_VRS, val);
146142

147-
pm_runtime_mark_last_busy(priv->dev);
148143
pm_runtime_put_autosuspend(priv->dev);
149144

150145
return ret;
@@ -218,7 +213,6 @@ static int stm32_vrefbuf_probe(struct platform_device *pdev)
218213
}
219214
platform_set_drvdata(pdev, rdev);
220215

221-
pm_runtime_mark_last_busy(&pdev->dev);
222216
pm_runtime_put_autosuspend(&pdev->dev);
223217

224218
return 0;

0 commit comments

Comments
 (0)