Lines Matching refs:PM

9 management (PM) code is also driver-specific.  Most drivers will do very
55 	the PM core are involved in runtime power management.  As in the system
64 synergies exist, so that several drivers using runtime PM might put the system
137 writers of device drivers whose subsystems (PM domains, device types, device
162 its system wakeup mechanism and for notifying the PM core of system wakeup
263 the device is suspending (i.e. has been chosen by the PM core as the next
280 All phases use PM domain, bus, type, class or driver callbacks (that is, methods
282 dev->driver->pm).  These callbacks are regarded by the PM core as mutually
283 exclusive.  Moreover, PM domain callbacks always take precedence over all of the
288     1.	If dev->pm_domain is present, the PM core will choose the callback
300 This allows PM domains and device types to override callbacks provided by bus
303 The PM domain, type, class and bus callbacks may in turn invoke device- or
307 If the subsystem callback chosen for execution is not present, the PM core will
319 	from being registered; the PM core would never know that all the
331 	prepare callback can be used to indicate to the PM core that it may
337 	PM core will skip the suspend, suspend_late and	suspend_noirq suspend
345 	disabled for runtime PM; only the runtime-PM status matters.  It follows
347 	PM, then its prepare callback must never return a positive value.  This
349 	runtime PM disabled.
379 runtime PM may already have performed some or all of these steps.)
388 low-power state.  Instead the PM core will unwind its actions by resuming all
463 These callbacks may return an error value, but the PM core will ignore such
671 been thawed.  Generally speaking, the PM notifiers are suitable for performing
689 power states due to runtime power management.  The system sleep PM callbacks