Lines Matching full:autosuspend

156 also respecting devices configured for autosuspend.  In essence this means a
210     - timer used for scheduling (delayed) suspend and autosuspend requests
286     - indicates that the device's driver supports delayed autosuspend (see
291     - indicates that the PM core should attempt to carry out an autosuspend
295     - the delay time (in milliseconds) to be used for autosuspend
300       periods for autosuspend
332       pm_runtime_mark_last_busy() is made and an autosuspend is scheduled for
358       subsystem-level suspend callback for the device when the autosuspend delay
510     - set the power.use_autosuspend flag, enabling autosuspend delays; call
515     - clear the power.use_autosuspend flag, disabling autosuspend delays;
529     - calculate the time when the current autosuspend delay period will expire,
609 time.  A driver that makes use of the runtime autosuspend feature may want to
855 9. Autosuspend, or automatically-delayed suspends
867 The term "autosuspend" is an historical remnant.  It doesn't mean that the
878 In order to use autosuspend, subsystems or drivers must call
881 instead of the non-autosuspend counterparts::
888 Drivers may also continue to use the non-autosuspend helper functions; they
889 will behave normally, which means sometimes taking the autosuspend delay into
890 account (see pm_runtime_idle). The autosuspend variants of the functions also
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
961 The important point is that after foo_io_completion() asks for an autosuspend,