Lines Matching full:s
54 are executed by the PM core for the device's subsystem that may be either of
57 1. PM domain of the device, if the device's PM domain object, dev->pm_domain,
88 include executing the device driver's own ->runtime_suspend() callback (from the
89 PM core's point of view it is not necessary to implement a ->runtime_suspend()
97 device will not process data and will not communicate with the CPU(s) and
102 * If the suspend callback returns -EBUSY or -EAGAIN, the device's runtime PM
123 include executing the device driver's own ->runtime_resume() callback (from the
124 PM core's point of view it is not necessary to implement a ->runtime_resume()
142 indicated to the PM core by two counters, the device's usage counter and the
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
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)
264 - the runtime PM status of the device; this field's initial value is
284 - indicates that the device's driver supports delayed autosuspend (see
323 success, 1 if the device's runtime PM status was already 'suspended', or
336 success, 1 if the device's runtime PM status was already 'active' or
356 item is queued up immediately); returns 0 on success, 1 if the device's PM
365 success, 1 if the device's runtime PM status was already 'active', or
369 - increment the device's usage counter
372 - increment the device's usage counter, run pm_request_resume(dev) and
376 - increment the device's usage counter, run pm_runtime_resume(dev) and
388 or the device's usage_count is non-zero, increment the counter and
392 - decrement the device's usage counter
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
429 - check if there's a resume request pending for the device and resume it
440 - clear the device's 'power.runtime_error' flag, set the device's runtime
441 PM status to 'active' and update its parent's counter of 'active'
448 - clear the device's 'power.runtime_error' flag, set the device's runtime
449 PM status to 'suspended' and update its parent's counter of 'active'
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'
498 decrement the device's usage counter if the flag was previously set and
505 called or the device's usage counter may be decremented and
562 However, if the device has a parent and the parent's runtime PM is enabled,
564 the parent's 'power.ignore_children' flag is set. Namely, in that case the
565 parent won't be able to suspend at run time, using the PM core's helper
566 functions, as long as the child's status is 'active', even if the child's
575 reflects the actual state of the device, its bus type's or its driver's
576 ->probe() callback will likely need to wake it up using one of the PM core's
578 should be used. Of course, for this purpose the device's runtime PM has to be
598 resumes the device if it's in the suspended state and prevents it from
637 device's wake-up setting (it may leave that to the device driver's system
650 * The device's children may need the device to be at full power in order
653 * The driver's idea of the device state may not agree with the device's
661 If the device had been suspended before the system suspend began and it's
682 mechanism entirely under the kernel's control. As a result, the kernel never
739 callback provided by the device's driver and return its result, or return
744 if successful, change the device's runtime PM status to 'active'
756 callback provided by the device's driver and return its result, or return
766 callback provided by the device's driver and return its result, or return
776 callback provided by the device's driver and return its result, or return
781 if successful, change the device's runtime PM status to 'active'
784 - invoke the ->restore_noirq() callback provided by the device's driver
813 also okay). The routine will set the device's power.no_callbacks flag and
821 As a consequence, the PM core will never directly inform the device's subsystem
822 or driver about runtime power changes. Instead, the driver for the device's
823 parent must take responsibility for telling the device's driver when the
824 parent's power state changes.
829 Changing a device's power state isn't free; it requires both time and energy.
830 A device should be put in a low-power state only when there's some reason to