@@ -154,7 +154,7 @@ suspending the device are satisfied) and to queue up a suspend request for the
154
154
device in that case. If there is no idle callback, or if the callback returns
155
155
0, then the PM core will attempt to carry out a runtime suspend of the device,
156
156
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
157
+ call to __pm_runtime_autosuspend () (do note that drivers needs to update the
158
158
device last busy mark, pm_runtime_mark_last_busy(), to control the delay under
159
159
this circumstance). To prevent this (for example, if the callback routine has
160
160
started a delayed suspend), the routine must return a non-zero value. Negative
@@ -409,6 +409,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
409
409
pm_request_idle(dev) and return its result
410
410
411
411
`int pm_runtime_put_autosuspend(struct device *dev); `
412
+ - does the same as __pm_runtime_put_autosuspend() for now, but in the
413
+ future, will also call pm_runtime_mark_last_busy() as well, DO NOT USE!
414
+
415
+ `int __pm_runtime_put_autosuspend(struct device *dev); `
412
416
- decrement the device's usage counter; if the result is 0 then run
413
417
pm_request_autosuspend(dev) and return its result
414
418
@@ -539,6 +543,7 @@ It is safe to execute the following helper functions from interrupt context:
539
543
- pm_runtime_put_noidle()
540
544
- pm_runtime_put()
541
545
- pm_runtime_put_autosuspend()
546
+ - __pm_runtime_put_autosuspend()
542
547
- pm_runtime_enable()
543
548
- pm_suspend_ignore_children()
544
549
- pm_runtime_set_active()
@@ -864,9 +869,9 @@ automatically be delayed until the desired period of inactivity has elapsed.
864
869
865
870
Inactivity is determined based on the power.last_busy field. Drivers should
866
871
call pm_runtime_mark_last_busy() to update this field after carrying out I/O,
867
- typically just before calling pm_runtime_put_autosuspend (). The desired length
868
- of the inactivity period is a matter of policy. Subsystems can set this length
869
- initially by calling pm_runtime_set_autosuspend_delay(), but after device
872
+ typically just before calling __pm_runtime_put_autosuspend (). The desired
873
+ length of the inactivity period is a matter of policy. Subsystems can set this
874
+ length initially by calling pm_runtime_set_autosuspend_delay(), but after device
870
875
registration the length should be controlled by user space, using the
871
876
/sys/devices/.../power/autosuspend_delay_ms attribute.
872
877
@@ -877,7 +882,7 @@ instead of the non-autosuspend counterparts::
877
882
878
883
Instead of: pm_runtime_suspend use: pm_runtime_autosuspend;
879
884
Instead of: pm_schedule_suspend use: pm_request_autosuspend;
880
- Instead of: pm_runtime_put use: pm_runtime_put_autosuspend ;
885
+ Instead of: pm_runtime_put use: __pm_runtime_put_autosuspend ;
881
886
Instead of: pm_runtime_put_sync use: pm_runtime_put_sync_autosuspend.
882
887
883
888
Drivers may also continue to use the non-autosuspend helper functions; they
@@ -916,7 +921,7 @@ Here is a schematic pseudo-code example::
916
921
lock(&foo->private_lock);
917
922
if (--foo->num_pending_requests == 0) {
918
923
pm_runtime_mark_last_busy(&foo->dev);
919
- pm_runtime_put_autosuspend (&foo->dev);
924
+ __pm_runtime_put_autosuspend (&foo->dev);
920
925
} else {
921
926
foo_process_next_request(foo);
922
927
}
0 commit comments