Lines Matching +full:keep +full:- +full:power +full:- +full:in +full:- +full:suspend
23 suspend/resume and shutdown ordering.
25 Device links allow representation of such dependencies in the driver core.
27 In its standard or *managed* form, a device link combines *both* dependency
28 types: It guarantees correct suspend/resume and shutdown ordering between a
35 suspend/resume and shutdown ordering is needed, the device link may
36 simply be set up with the ``DL_FLAG_STATELESS`` flag. In other words,
41 is instructed to runtime resume the supplier and keep it active
47 The earliest point in time when device links can be added is after
52 remains in a consistent state: E.g. a device link cannot be added in
53 the midst of a suspend/resume transition, so either commencement of
56 not to run in parallel to a suspend/resume transition, such as from a
57 device ``->probe`` callback or a boot-time PCI quirk.
61 ``->probe`` callback while the supplier hasn't started to probe yet: Had the
63 consumer in the first place. The onus is thus on the consumer to check
65 non-presence. [Note that it is valid to create a link from the consumer's
66 ``->probe`` callback while the supplier is still probing, but the consumer must
72 is added in the ``->probe`` callback of the supplier or consumer driver, it is
73 typically deleted in its ``->remove`` callback for symmetry. That way, if the
76 addition (e.g. exclusion of a parallel suspend/resume transition) apply equally
82 driver presence dependency is needed (but only correct suspend/resume and
87 link is added from the consumer's ``->probe`` callback: ``DL_FLAG_RPM_ACTIVE``
93 Similarly, when the device link is added from supplier's ``->probe`` callback,
117 by the driver core when they are not necessary any more in accordance with the
125 :c:func:`device_link_add()` may cause the PM-runtime usage counter of the
129 called twice in a row for the same consumer-supplier pair without removing the
130 link between these calls, in which case allowing the PM-runtime usage counter
132 suspended while the consumer is still PM-runtime-active and that has to be
134 runtime suspend at least once, or call :c:func:`pm_runtime_set_suspended()` for
135 it with PM-runtime disabled, between the :c:func:`device_link_add()` and
139 in a degraded mode (reduced feature set or performance) when those resources
141 or work in PIO mode. The controller can determine presence of the optional
142 resources at probe time but on non-presence there is no way to know whether
143 they will become available in the near future (due to a supplier driver
149 based on probe deferral. In any case optional resources are beyond the
155 * An MMU device exists alongside a busmaster device, both are in the same
156 power domain. The MMU implements DMA address translation for the busmaster
164 The fact that both devices share the same power domain would normally
166 however these are not independent devices that happen to share a power
173 the NHI device needs to re-establish PCI tunnels to attached devices
181 * Discrete GPUs in hybrid graphics laptops often feature an HDA controller
182 for HDMI/DP audio. In the device hierarchy the HDA controller is a sibling
183 of the VGA device, yet both share the same power domain and the HDA
189 A classical example is when ACPI power management methods on one device
190 are implemented in terms of I\ :sup:`2`\ C accesses and require a specific
191 I\ :sup:`2`\ C controller to be present and functional for the power
192 management of the device in question to work.
194 * In some SoCs a functional dependency exists from display, video codec and
204 suspend/resume ordering, this needs to be implemented separately.
206 devices and turn off the power switch only when all of them are runtime
217 The device hierarchy, which -- as the name implies -- is a tree,
220 Ordering of these devices during suspend/resume is determined by the
222 no device links present, the two lists are a flattened, one-dimensional
225 or OpenFirmware device tree top-down and appending devices to the lists
231 entire sub-graph below it (all children and consumers of the consumer)
245 correct suspend/resume and shutdown ordering between parent and child,
247 needed on top of that. In this case driver authors should weigh
256 .. kernel-doc:: include/linux/device.h
280 verified by checking the consumer device is not in the wait_for_suppliers
281 list and by checking that links to suppliers are in ``DL_STATE_AVAILABLE``
298 :c:func:`device_links_driver_cleanup()`, which in turn is called from
312 Once all links to consumers are in ``DL_STATE_SUPPLIER_UNBIND`` state,