Documentation/power/runtime_pm.rst

68 callback, the PM core will invoke the corresponding driver callback stored in
71 The PM core always checks which callback to use in the order given above, so the
81 interrupts disabled.  This implies that the callback routines in question must
86 The subsystem-level suspend callback, if present, is _entirely_ _responsible_
88 include executing the device driver's own ->runtime_suspend() callback (from the
90 callback in a device driver as long as the subsystem-level suspend callback
93   * Once the subsystem-level suspend callback (or the driver suspend callback,
98     RAM until the appropriate resume callback is executed for it.  The runtime
99     PM status of a device after successful execution of the suspend callback is
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
117 low-power state during the execution of the suspend callback, it is expected
121 The subsystem-level resume callback, if present, is **entirely responsible** for
123 include executing the device driver's own ->runtime_resume() callback (from the
125 callback in a device driver as long as the subsystem-level resume callback knows
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
148     idle callback with the device as its argument.
150 The action performed by the idle callback is totally dependent on the subsystem
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
247       callback
320     - execute the subsystem-level idle callback for the device; returns an
322       already being executed; if there is no callback or the callback returns 0
326     - execute the subsystem-level suspend callback for the device; returns 0 on
339     - execute the subsystem-level resume callback for the device; returns 0 on
345       that the callback could not be run, because 'power.disable_depth' was
353     - submit a request to execute the subsystem-level idle callback for the
358     - schedule the execution of the subsystem-level suspend callback for the
363     - schedule the execution of the subsystem-level suspend callback for the
373     - submit a request to execute the subsystem-level resume callback for the
439       necessary to execute the subsystem-level resume callback for the device
447       necessary to execute the subsystem-level resume callback for the device to
590 ->probe() callback will likely need to wake it up using one of the PM core's
603 request to execute the subsystem-level idle callback for the device at that
608 notifier callback in __device_release_driver(), which is necessary because the
623 Drivers in ->remove() callback should undo the runtime PM changes done
650 the subsystem-level system suspend callback is responsible for changing the
685 ->suspend() callback and decrements it after calling the ->resume() callback.
688 following the return of the ->resume() callback, the ->runtime_idle() callback
705 callback returns a positive number for a device, that indicates to the PM core
710 .complete() callback, which is then entirely responsible for handling the device
720     right before executing the subsystem-level .prepare() callback for it and
722     subsystem-level .suspend() callback for it.  In addition to that the PM core
724     device right before executing the subsystem-level .suspend_late() callback
729     callback and right after executing the subsystem-level .complete() callback
739     - invoke the ->runtime_suspend() callback provided by the driver of this
743     - invoke the ->runtime_resume() callback provided by the driver of this
748       callback provided by its driver and return its result, or return 0 if not
753       callback provided by the device's driver and return its result, or return
757     - invoke the ->resume() callback provided by the driver of this device and,
761     - invoke the ->resume_noirq() callback provided by the driver of this device
765       callback provided by its driver and return its result, or return 0 if not
770       callback provided by the device's driver and return its result, or return
775       callback provided by its driver and return its result, or return 0 if not
780       callback provided by the device's driver and return its result, or return
785       callback provided by its driver and return its result, or return 0 if not
790       callback provided by the device's driver and return its result, or return
794     - invoke the ->restore() callback provided by the driver of this device and,
798     - invoke the ->restore_noirq() callback provided by the device's driver
808 poweroff and runtime suspend callback, and similarly for system resume, thaw,
813 8. "No-Callback" Devices
846 unassigned. More precisely, if a callback pointer is NULL, the PM core will act
847 as though there was a callback and it returned 0.
890 autosuspend delay time has expired.  If the ->runtime_suspend() callback
892 in the future (as it normally would be if the callback invoked
894 autosuspend.  The ->runtime_suspend() callback can't do this rescheduling
896 suspending (i.e., while the callback is running).
959 the foo_runtime_suspend() callback may race with foo_read_or_write().
967 callback while holding its private lock.  If the function returns a nonzero
968 value then the delay has not yet expired and the callback should return