aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/power/devices.txt
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2011-11-23 15:18:39 -0500
committerRafael J. Wysocki <rjw@sisk.pl>2011-11-28 16:14:19 -0500
commit5841eb6402707a387b216373e65c9c28e8136663 (patch)
tree1841f84c931e6e55ab510f4d44c505e802eae4eb /Documentation/power/devices.txt
parentbb58dd5d1ffad6c2d21c69698ba766dad4ae54e6 (diff)
PM / Domains: Document how PM domains are used by the PM core
The current power management documentation in Documentation/power/ either doesn't cover PM domains at all, or gives inaccurate information about them, so update the relevant files in there to follow the code. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Diffstat (limited to 'Documentation/power/devices.txt')
-rw-r--r--Documentation/power/devices.txt42
1 files changed, 27 insertions, 15 deletions
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 646a89e0c07d..4342acbeee10 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -123,9 +123,10 @@ please refer directly to the source code for more information about it.
123Subsystem-Level Methods 123Subsystem-Level Methods
124----------------------- 124-----------------------
125The core methods to suspend and resume devices reside in struct dev_pm_ops 125The core methods to suspend and resume devices reside in struct dev_pm_ops
126pointed to by the pm member of struct bus_type, struct device_type and 126pointed to by the ops member of struct dev_pm_domain, or by the pm member of
127struct class. They are mostly of interest to the people writing infrastructure 127struct bus_type, struct device_type and struct class. They are mostly of
128for buses, like PCI or USB, or device type and device class drivers. 128interest to the people writing infrastructure for platforms and buses, like PCI
129or USB, or device type and device class drivers.
129 130
130Bus drivers implement these methods as appropriate for the hardware and the 131Bus drivers implement these methods as appropriate for the hardware and the
131drivers using it; PCI works differently from USB, and so on. Not many people 132drivers using it; PCI works differently from USB, and so on. Not many people
@@ -251,18 +252,29 @@ various phases always run after tasks have been frozen and before they are
251unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have 252unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have
252been disabled (except for those marked with the IRQ_WAKEUP flag). 253been disabled (except for those marked with the IRQ_WAKEUP flag).
253 254
254All phases use bus, type, or class callbacks (that is, methods defined in 255All phases use PM domain, bus, type, or class callbacks (that is, methods
255dev->bus->pm, dev->type->pm, or dev->class->pm). These callbacks are mutually 256defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, or dev->class->pm).
256exclusive, so if the device type provides a struct dev_pm_ops object pointed to 257These callbacks are regarded by the PM core as mutually exclusive. Moreover,
257by its pm field (i.e. both dev->type and dev->type->pm are defined), the 258PM domain callbacks always take precedence over bus, type and class callbacks,
258callbacks included in that object (i.e. dev->type->pm) will be used. Otherwise, 259while type callbacks take precedence over bus and class callbacks, and class
259if the class provides a struct dev_pm_ops object pointed to by its pm field 260callbacks take precedence over bus callbacks. To be precise, the following
260(i.e. both dev->class and dev->class->pm are defined), the PM core will use the 261rules are used to determine which callback to execute in the given phase:
261callbacks from that object (i.e. dev->class->pm). Finally, if the pm fields of 262
262both the device type and class objects are NULL (or those objects do not exist), 263 1. If dev->pm_domain is present, the PM core will attempt to execute the
263the callbacks provided by the bus (that is, the callbacks from dev->bus->pm) 264 callback included in dev->pm_domain->ops. If that callback is not
264will be used (this allows device types to override callbacks provided by bus 265 present, no action will be carried out for the given device.
265types or classes if necessary). 266
267 2. Otherwise, if both dev->type and dev->type->pm are present, the callback
268 included in dev->type->pm will be executed.
269
270 3. Otherwise, if both dev->class and dev->class->pm are present, the
271 callback included in dev->class->pm will be executed.
272
273 4. Otherwise, if both dev->bus and dev->bus->pm are present, the callback
274 included in dev->bus->pm will be executed.
275
276This allows PM domains and device types to override callbacks provided by bus
277types or device classes if necessary.
266 278
267These callbacks may in turn invoke device- or driver-specific methods stored in 279These callbacks may in turn invoke device- or driver-specific methods stored in
268dev->driver->pm, but they don't have to. 280dev->driver->pm, but they don't have to.