Lines Matching refs:then

109 device, then ->runtime_suspend() should return -EBUSY.  On the other hand, if
125     I/O operations as needed.  The runtime PM status of the device is then
149 0, then the PM core will attempt to carry out a runtime suspend of the device,
314       then run pm_runtime_autosuspend(dev) and return its result
326       not yet expired then an autosuspend is scheduled for the appropriate time
345       expired then the work item is queued up immediately
378     - decrement the device's usage counter; if the result is 0 then run
382     - decrement the device's usage counter; if the result is 0 then run
386     - decrement the device's usage counter; if the result is 0 then run
390     - decrement the device's usage counter; if the result is 0 then run
394     - decrement the device's usage counter; if the result is 0 then run
482       milliseconds); if 'delay' is negative then runtime suspends are
488       is 1000 ms or larger then the expiration time is rounded up to the
512 If pm_runtime_irq_safe() has been called for a device then the following helper
556 if it is registers with a subsystem that may call back in) then the
627   * Even though the device was suspended, if its usage counter was > 0 then most
631 brought back to full power during resume, then its runtime PM status will have
665 complete callback, which is then entirely responsible for handling the device
830 Similarly, if the power.use_autosuspend field isn't set then the autosuspend
913 value then the delay has not yet expired and the callback should return