Lines Matching full:if
57 1. PM domain of the device, if the device's PM domain object, dev->pm_domain,
60 2. Device type of the device, if both dev->type and dev->type->pm are present.
62 3. Device class of the device, if both dev->class and dev->class->pm are
65 4. Bus type of the device, if both dev->bus and dev->bus->pm are present.
67 If the subsystem chosen by applying the above rules doesn't provide the relevant
69 dev->driver->pm directly (if present).
86 The subsystem-level suspend callback, if present, is _entirely_ _responsible_
94 if invoked directly) has completed successfully for the given device, the PM
102 * If the suspend callback returns -EBUSY or -EAGAIN, the device's runtime PM
106 * If the suspend callback returns an error code different from -EBUSY and
112 In particular, if the driver requires remote wakeup capability (i.e. hardware
115 device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
121 The subsystem-level resume callback, if present, is **entirely responsible** for
128 * Once the subsystem-level resume callback (or the driver resume callback, if
134 * If the resume callback returns an error code, the PM core regards this as a
140 The idle callback (a subsystem-level one, if present, or the driver one) is
145 * If any of these counters is decreased using a helper function provided by
147 checked. If that counter also is equal to zero, the PM core executes the
152 if the device can be suspended (i.e. if all of the conditions necessary for
154 device in that case. If there is no idle callback, or if the callback returns
159 this circumstance). To prevent this (for example, if the callback routine has
191 * If ->runtime_suspend() is about to be executed or there's a pending request
198 * If ->runtime_resume() is about to be executed or there's a pending request
215 - timer expiration time, in jiffies (if this is different from zero, the
223 - wait queue used if any of the helper functions needs to wait for another
236 - if set, the value of child_count is ignored (but still updated)
239 - used for disabling the helper functions (they work normally if this is
244 - if set, there was a fatal error (one of the callbacks returned error code
250 - if set, ->runtime_idle() is being executed
253 - if set, there's a pending request (i.e. a work item queued up into pm_wq)
256 - type of request that's pending (valid if request_pending is set)
259 - set if ->runtime_resume() is about to be run while ->runtime_suspend() is
269 - if set, indicates that the user space has allowed the device driver to
318 already being executed; if there is no callback or the callback returns 0
323 success, 1 if the device's runtime PM status was already 'suspended', or
330 `into account;` if pm_runtime_autosuspend_expiration() says the delay has
336 success, 1 if the device's runtime PM status was already 'active' or
345 success or error code if the request has not been queued up
349 device when the autosuspend delay has expired; if the delay has already
355 suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work
356 item is queued up immediately); returns 0 on success, 1 if the device's PM
357 runtime status was already 'suspended', or error code if the request
358 hasn't been scheduled (or queued up if 'delay' is 0); if the execution of
365 success, 1 if the device's runtime PM status was already 'active', or
366 error code if the request hasn't been queued up
380 - return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the
386 - return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the
395 - decrement the device's usage counter; if the result is 0 then run
399 - decrement the device's usage counter; if the result is 0 then run
403 - decrement the device's usage counter; if the result is 0 then run
407 - decrement the device's usage counter; if the result is 0 then run
411 - decrement the device's usage counter; if the result is 0 then run
415 - decrement the device's 'power.disable_depth' field; if that field is equal
420 - increment the device's 'power.disable_depth' field (if the value of that
424 canceled; returns 1 if there was a resume request pending and it was
429 - check if there's a resume request pending for the device and resume it
432 complete; returns 1 if there was a resume request pending and it was
442 children as appropriate (it is only valid to use this function if
444 zero); it will fail and return error code if the device has a parent
450 children as appropriate (it is only valid to use this function if
455 - return true if the device's runtime PM status is 'active' or its
459 - return true if the device's runtime PM status is 'suspended' and its
463 - return true if the device's runtime PM status is 'suspended'
485 - return true if power.irq_safe flag was set for the device, causing
493 pm_runtime_get_sync if the flag was previously cleared and
498 decrement the device's usage counter if the flag was previously set and
503 milliseconds); if 'delay' is negative then runtime suspends are
504 prevented; if power.use_autosuspend is set, pm_runtime_get_sync may be
506 pm_runtime_idle called depending on if power.autosuspend_delay is
507 changed to or from a negative value; if power.use_autosuspend is clear,
512 based on power.last_busy and power.autosuspend_delay; if the delay time
514 nearest second; returns 0 if the delay period has already expired or
537 If pm_runtime_irq_safe() has been called for a device then the following helper
558 Thus, if the device is initially active (i.e. it is able to process I/O), its
562 However, if the device has a parent and the parent's runtime PM is enabled,
566 functions, as long as the child's status is 'active', even if the child's
574 If the default initial runtime PM status of the device (i.e. 'suspended')
581 Note, if the device may execute pm_runtime calls during the probe (such as
582 if it is registers with a subsystem that may call back in) then the
598 resumes the device if it's in the suspended state and prevents it from
620 noted, however, that if the user space has already intentionally changed the
630 ways. If a device is active when a system sleep starts, everything is
631 straightforward. But what should happen if the device is already suspended?
639 in order to do so. The same is true if the driver uses different power levels
643 power, even if they had been suspended before the system suspend began. There
658 * Even though the device was suspended, if its usage counter was > 0 then most
661 If the device had been suspended before the system suspend began and it's
673 suspend attempts to be permanently lost. If the usage count goes to zero
684 known to it. If that is the case and none of the situations listed above takes
685 place (in particular, if the system is not waking up from hibernation), it may
690 different levels of device hierarchy. Namely, if a system suspend .prepare()
694 left in runtime suspend. If that happens, the PM core will not execute any
726 device and return its result, or return 0 if not defined
730 device and return its result, or return 0 if not defined
733 - if the device has not been suspended at run time, invoke the ->suspend()
734 callback provided by its driver and return its result, or return 0 if not
738 - if pm_runtime_suspended(dev) returns "false", invoke the ->suspend_noirq()
740 0 if not defined
744 if successful, change the device's runtime PM status to 'active'
750 - if the device has not been suspended at run time, invoke the ->freeze()
751 callback provided by its driver and return its result, or return 0 if not
755 - if pm_runtime_suspended(dev) returns "false", invoke the ->freeze_noirq()
757 0 if not defined
760 - if the device has not been suspended at run time, invoke the ->thaw()
761 callback provided by its driver and return its result, or return 0 if not
765 - if pm_runtime_suspended(dev) returns "false", invoke the ->thaw_noirq()
767 0 if not defined
770 - if the device has not been suspended at run time, invoke the ->poweroff()
771 callback provided by its driver and return its result, or return 0 if not
775 - if pm_runtime_suspended(dev) returns "false", run the ->poweroff_noirq()
777 0 if not defined
781 if successful, change the device's runtime PM status to 'active'
786 These functions are the defaults used by the PM core, if a subsystem doesn't
806 need of runtime PM callbacks; if the callbacks did exist, ->runtime_suspend()
867 autosuspend delay time has expired. If the ->runtime_suspend() callback
868 returns -EAGAIN or -EBUSY, and if the next autosuspend delay expiration time is
869 in the future (as it normally would be if the callback invoked
885 if (foo->num_pending_requests++ == 0)
887 if (!foo->is_suspended)
895 if (--foo->num_pending_requests == 0) {
911 if (foo->num_pending_requests > 0) {
929 if (foo->num_pending_requests > 0)
942 any time. If a driver cares about this, it can call
944 callback while holding its private lock. If the function returns a nonzero