@@ -154,11 +154,9 @@ suspending the device are satisfied) and to queue up a suspend request for the
154154device in that case. If there is no idle callback, or if the callback returns
1551550, then the PM core will attempt to carry out a runtime suspend of the device,
156156also 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
163161The helper functions provided by the PM core, described in Section 4, guarantee
164162that 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
0 commit comments