Documentation/power/runtime_pm.rst

156 also respecting devices configured for autosuspend.  In essence this means a
212     - timer used for scheduling (delayed) suspend and autosuspend requests
288     - indicates that the device's driver supports delayed autosuspend (see
293     - indicates that the PM core should attempt to carry out an autosuspend
297     - the delay time (in milliseconds) to be used for autosuspend
302       periods for autosuspend
333     - same as pm_runtime_suspend() except that the autosuspend delay is taken
335       not yet expired then an autosuspend is scheduled for the appropriate time
359       device when the autosuspend delay has expired; if the delay has already
509     - set the power.use_autosuspend flag, enabling autosuspend delays; call
514     - clear the power.use_autosuspend flag, disabling autosuspend delays;
528     - calculate the time when the current autosuspend delay period will expire,
608 time.  A driver that makes use of the runtime autosuspend feature may want to
866 The term "autosuspend" is an historical remnant.  It doesn't mean that the
879 In order to use autosuspend, subsystems or drivers must call
882 instead of the non-autosuspend counterparts::
889 Drivers may also continue to use the non-autosuspend helper functions; they
890 will behave normally, which means sometimes taking the autosuspend delay into
895 autosuspend delay time has expired.  If the ->runtime_suspend() callback
896 returns -EAGAIN or -EBUSY, and if the next autosuspend delay expiration time is
899 autosuspend.  The ->runtime_suspend() callback can't do this rescheduling
963 The important point is that after foo_io_completion() asks for an autosuspend,