Lines Matching refs:PM
18 management (PM) code is also driver-specific. Most drivers will do very
67 the PM core are involved in runtime power management. As in the system
76 synergies exist, so that several drivers using runtime PM might put the system
125 device drivers whose subsystems (PM domains, device types, device classes and
152 its system wakeup mechanism and for notifying the PM core of system wakeup
260 the device is suspending (i.e. has been chosen by the PM core as the next
279 All phases use PM domain, bus, type, class or driver callbacks (that is, methods
282 PM core as mutually exclusive. Moreover, PM domain callbacks always take
287 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 devices from being registered; the PM core would never know that all the
321 registered at will. [By contrast, from the PM core's perspective,
335 prepare callback can be used to indicate to the PM core that it may
341 PM core will skip the ``suspend``, ``suspend_late`` and
349 disabled for runtime PM; only the runtime-PM status matters. It follows
351 PM, then its prepare callback must never return a positive value. This
353 runtime PM disabled.
360 these flags is set, the PM core will not apply the direct-complete
363 code (bus types, device types, PM domains, classes) that it should take
375 ``->suspend`` methods provided by subsystems (bus types and PM domains
382 suspend in their ``->suspend`` methods). In fact, the PM core prevents
411 runtime PM may already have performed some or all of these steps.]
420 low-power state. Instead, the PM core will unwind its actions by resuming all
501 These callbacks may return an error value, but the PM core will ignore such
654 been thawed. Generally speaking, the PM notifiers are suitable for performing
727 Devices may be defined as IRQ-safe which indicates to the PM core that their
728 runtime PM callbacks may be invoked with disabled interrupts (see
730 IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be
732 makes sense to define a PM domain as IRQ-safe only if all the devices in it
734 PM of the parent is only allowed if the parent itself is IRQ-safe too with the
751 power states due to runtime power management. The system sleep PM callbacks
767 device's driver or its subsystem (for example, a bus type or a PM domain).
777 Some bus types and PM domains have a policy to resume all devices from runtime
784 Setting that flag causes the PM core and middle-layer code
785 (bus types, PM domains etc.) to skip the ``->suspend_late`` and
791 be valid in general.] If the middle-layer system-wide PM callbacks are present
793 if not then the PM core skips them. The subsystem callback routines can
801 doing this, otherwise the PM core takes care of it.
817 indicate to the PM core and middle-layer code that they allow their "noirq" and
819 after system-wide PM transitions to the working state. Whether or not that is
832 the :c:member:`power.may_skip_resume` status bit set by the PM core during the
848 callbacks should be skipped and the device's runtime PM status will be set to
849 "suspended" by the PM core. Otherwise, if the device was runtime-suspended
851 ``DPM_FLAG_SMART_SUSPEND`` is set, its runtime PM status will be set to
852 "active" by the PM core. [Hence, the drivers that do not set
853 ``DPM_FLAG_SMART_SUSPEND`` should not expect the runtime PM status of their
854 devices to be changed from "suspended" to "active" by the PM core during
860 present, are invoked as usual and the device's runtime PM status is set to
861 "active" by the PM core before enabling runtime PM for it. In that case, the
865 final state of the device must reflect the "active" runtime PM status in that
880 functions for runtime PM and system-wide suspend/resume.]