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
486       milliseconds); if 'delay' is negative then runtime suspends are
492       is 1000 ms or larger then the expiration time is rounded up to the
516 If pm_runtime_irq_safe() has been called for a device then the following helper
625   * Even though the device was suspended, if its usage counter was > 0 then most
629 brought back to full power during resume, then its runtime PM status will have
663 complete callback, which is then entirely responsible for handling the device
828 Similarly, if the power.use_autosuspend field isn't set then the autosuspend
911 value then the delay has not yet expired and the callback should return