Lines Matching refs:by
10 at the power management core (PM core) level by means of:
28 synchronization between them is taken care of by the PM core. Bus types and
48 are executed by the PM core for the device's subsystem that may be either of
61 If the subsystem chosen by applying the above rules doesn't provide the relevant
131 'suspended' (by means of special helper functions provided by the PM core
135 executed by the PM core whenever the device appears to be idle, which is
136 indicated to the PM core by two counters, the device's usage counter and the
139 * If any of these counters is decreased using a helper function provided by
144 The action performed by the idle callback is totally dependent on the subsystem
155 error return codes are ignored by the PM core.
157 The helper functions provided by the PM core, described in Section 4, guarantee
182 Additionally, the helper functions provided by the PM core obey the following
239 this flag is cleared; this is the error code returned by the failing
261 RPM_SUSPENDED, which means that each device is initially regarded by the
272 Section 8); it may be modified only by the pm_runtime_no_callbacks()
281 Section 9); it may be modified only by the
339 device (the request is represented by a work item in pm_wq); returns 0 on
359 device (the request is represented by a work item in pm_wq); returns 0 on
454 counter (used by the /sys/devices/.../power/control interface to
459 counter (used by the /sys/devices/.../power/control interface to
557 enabled earlier by calling pm_runtime_enable().
567 notifier is used by some subsystems to carry out operations affecting the
568 runtime PM functionality. It does so by calling pm_runtime_get_sync() before
573 To allow bus types and drivers to put devices into the suspended state by
582 it at run time by changing the value of its /sys/devices/.../power/control
584 this mechanism may also be used by the driver to effectively turn off the
590 manage the device at run time, the driver may confuse it by using
615 * Remote wake-up events might have been lost by the firmware.
646 states directly by the kernel in a coordinated way. Then, the system sleep
648 and the system is woken up from that state by a hardware interrupt or a similar
669 the runtime PM and system suspend/resume (and hibernation) callbacks by carrying
687 Subsystems may wish to conserve code space by using the set of generic power
688 management callbacks provided by the PM core, defined in
692 - invoke the ->runtime_suspend() callback provided by the driver of this
696 - invoke the ->runtime_resume() callback provided by the driver of this
701 callback provided by its driver and return its result, or return 0 if not
706 callback provided by the device's driver and return its result, or return
710 - invoke the ->resume() callback provided by the driver of this device and,
714 - invoke the ->resume_noirq() callback provided by the driver of this device
718 callback provided by its driver and return its result, or return 0 if not
723 callback provided by the device's driver and return its result, or return
728 callback provided by its driver and return its result, or return 0 if not
733 callback provided by the device's driver and return its result, or return
738 callback provided by its driver and return its result, or return 0 if not
743 callback provided by the device's driver and return its result, or return
747 - invoke the ->restore() callback provided by the driver of this device and,
751 - invoke the ->restore_noirq() callback provided by the device's driver
753 These functions are the defaults used by the PM core, if a subsystem doesn't
776 Subsystems can tell the PM core about these devices by calling
812 initially by calling pm_runtime_set_autosuspend_delay(), but after device
813 registration the length should be controlled by user space, using the
844 This synchronization must be handled by the driver, using its private lock.
907 In addition, the power.autosuspend_delay field can be changed by user space at