Lines Matching full:pm
26 management (PM) code is also driver-specific. Most drivers will do very
75 the PM core are involved in runtime power management. As in the system
84 synergies exist, so that several drivers using runtime PM might put the system
110 |struct dev_pm_ops| defined in :file:`include/linux/pm.h`. The roles of the
129 |struct dev_pm_domain|, or by the :c:member:`pm` member of |struct bus_type|,
133 device drivers whose subsystems (PM domains, device types, device classes and
160 its system wakeup mechanism and for notifying the PM core of system wakeup
268 the device is suspending (i.e. has been chosen by the PM core as the next
287 All phases use PM domain, bus, type, class or driver callbacks (that is, methods
288 defined in ``dev->pm_domain->ops``, ``dev->bus->pm``, ``dev->type->pm``,
289 ``dev->class->pm`` or ``dev->driver->pm``). These callbacks are regarded by the
290 PM core as mutually exclusive. Moreover, PM domain callbacks always take
295 1. If ``dev->pm_domain`` is present, the PM core will choose the callback
298 2. Otherwise, if both ``dev->type`` and ``dev->type->pm`` are present, the
299 callback provided by ``dev->type->pm`` will be chosen for execution.
301 3. Otherwise, if both ``dev->class`` and ``dev->class->pm`` are present,
302 the callback provided by ``dev->class->pm`` will be chosen for
305 4. Otherwise, if both ``dev->bus`` and ``dev->bus->pm`` are present, the
306 callback provided by ``dev->bus->pm`` will be chosen for execution.
308 This allows PM domains and device types to override callbacks provided by bus
311 The PM domain, type, class and bus callbacks may in turn invoke device- or
312 driver-specific methods stored in ``dev->driver->pm``, but they don't have to do
315 If the subsystem callback chosen for execution is not present, the PM core will
316 execute the corresponding method from the ``dev->driver->pm`` set instead if
327 devices from being registered; the PM core would never know that all the
329 registered at will. [By contrast, from the PM core's perspective,
343 prepare callback can be used to indicate to the PM core that it may
349 PM core will skip the ``suspend``, ``suspend_late`` and
357 disabled for runtime PM; only the runtime-PM status matters. It follows
359 PM, then its prepare callback must never return a positive value. This
361 runtime PM disabled.
368 these flags is set, the PM core will not apply the direct-complete
371 code (bus types, device types, PM domains, classes) that it should take
383 ``->suspend`` methods provided by subsystems (bus types and PM domains
415 runtime PM may already have performed some or all of these steps.]
424 low-power state. Instead, the PM core will unwind its actions by resuming all
442 For example, the PCI bus type's ``->pm.resume_noirq()`` puts the device
445 device driver's ``->pm.resume_noirq()`` method to perform device-specific
505 These callbacks may return an error value, but the PM core will ignore such
656 been thawed. Generally speaking, the PM notifiers are suitable for performing
711 |struct dev_pm_domain|, defined in :file:`include/linux/pm.h`, providing a set
729 Devices may be defined as IRQ-safe which indicates to the PM core that their
730 runtime PM callbacks may be invoked with disabled interrupts (see
732 IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be
734 makes sense to define a PM domain as IRQ-safe only if all the devices in it
736 PM of the parent is only allowed if the parent itself is IRQ-safe too with the
753 power states due to runtime power management. The system sleep PM callbacks
769 or a subsystem responsible for it (for example, a bus type or a PM domain).
775 Some bus types and PM domains have a policy to resume all devices from runtime
781 (bus types, PM domains etc.) to skip the ``->suspend_late`` and
784 suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM
786 after that point until the system-wide transition is over (the PM core itself
787 does that for devices whose "noirq", "late" and "early" system-wide PM callbacks
791 to "active" before enabling runtime PM for it, so the driver must be prepared to
794 so on) and the final state of the device must reflect the "active" runtime PM
807 indicate to the PM core (and middle-layer code) that they prefer the specific
817 indicate to the PM core if the device may be left in suspend by setting its
818 :c:member:`power.may_skip_resume` status bit which is checked by the PM core
823 (except for ``->complete``) will be skipped automatically by the PM core if the
827 directly by the PM core, all of the system-wide resume callbacks are skipped if
831 device's wakeup settings are suitable for runtime PM (that is, it cannot