aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2017-02-20 09:26:21 -0500
committerJonathan Corbet <corbet@lwn.net>2017-02-20 18:40:42 -0500
commite3941cd9f59d1d5508c29eb1712a732722885ee7 (patch)
tree1cfb162d4b3a5b0835b37e8603572464006b4f23
parent62924fd789c6a381b772141f78a82361f46ae397 (diff)
PM / docs: Fix structure references in device.rst
There is a better way to represent structure references than it was done in device.rst by commit 730c4c053012 (PM / sleep / docs: Convert PM notifiers document to reST), which is to use "struct name" as a link caption (e.g. :c:type:`struct device <device>`). That will cause sphinx to generate a proper reference to the data type in question (struct device in the example above) and "struct name" will work as the link in the HTML output. Fix device.rst by using that convention where applicable. Fixes: 730c4c053012 (PM / sleep / docs: Convert PM notifiers document to reST) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-rw-r--r--Documentation/driver-api/pm/devices.rst72
1 files changed, 38 insertions, 34 deletions
diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst
index 0e8cf4efd7e7..bedd32388dac 100644
--- a/Documentation/driver-api/pm/devices.rst
+++ b/Documentation/driver-api/pm/devices.rst
@@ -1,4 +1,10 @@
1.. |struct| replace:: :c:type:`struct` 1.. |struct dev_pm_ops| replace:: :c:type:`struct dev_pm_ops <dev_pm_ops>`
2.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain <dev_pm_domain>`
3.. |struct bus_type| replace:: :c:type:`struct bus_type <bus_type>`
4.. |struct device_type| replace:: :c:type:`struct device_type <device_type>`
5.. |struct class| replace:: :c:type:`struct class <class>`
6.. |struct wakeup_source| replace:: :c:type:`struct wakeup_source <wakeup_source>`
7.. |struct device| replace:: :c:type:`struct device <device>`
2 8
3============================== 9==============================
4Device Power Management Basics 10Device Power Management Basics
@@ -95,17 +101,17 @@ Device Power Management Operations
95 101
96Device power management operations, at the subsystem level as well as at the 102Device power management operations, at the subsystem level as well as at the
97device driver level, are implemented by defining and populating objects of type 103device driver level, are implemented by defining and populating objects of type
98|struct| :c:type:`dev_pm_ops` defined in :file:`include/linux/pm.h`. 104|struct dev_pm_ops| defined in :file:`include/linux/pm.h`. The roles of the
99The roles of the methods included in it will be explained in what follows. For 105methods included in it will be explained in what follows. For now, it should be
100now, it should be sufficient to remember that the last three methods are 106sufficient to remember that the last three methods are specific to runtime power
101specific to runtime power management while the remaining ones are used during 107management while the remaining ones are used during system-wide power
102system-wide power transitions. 108transitions.
103 109
104There also is a deprecated "old" or "legacy" interface for power management 110There also is a deprecated "old" or "legacy" interface for power management
105operations available at least for some subsystems. This approach does not use 111operations available at least for some subsystems. This approach does not use
106|struct| :c:type:`dev_pm_ops` objects and it is suitable only for implementing 112|struct dev_pm_ops| objects and it is suitable only for implementing system
107system sleep power management methods in a limited way. Therefore it is not 113sleep power management methods in a limited way. Therefore it is not described
108described in this document, so please refer directly to the source code for more 114in this document, so please refer directly to the source code for more
109information about it. 115information about it.
110 116
111 117
@@ -113,14 +119,13 @@ Subsystem-Level Methods
113----------------------- 119-----------------------
114 120
115The core methods to suspend and resume devices reside in 121The core methods to suspend and resume devices reside in
116|struct| :c:type:`dev_pm_ops` pointed to by the :c:member:`ops` 122|struct dev_pm_ops| pointed to by the :c:member:`ops` member of
117member of |struct| :c:type:`dev_pm_domain`, or by the :c:member:`pm` 123|struct dev_pm_domain|, or by the :c:member:`pm` member of |struct bus_type|,
118member of |struct| :c:type:`bus_type`, |struct| :c:type:`device_type` and 124|struct device_type| and |struct class|. They are mostly of interest to the
119|struct| :c:type:`class`. They are mostly of interest to the people writing 125people writing infrastructure for platforms and buses, like PCI or USB, or
120infrastructure for platforms and buses, like PCI or USB, or device type and 126device type and device class drivers. They also are relevant to the writers of
121device class drivers. They also are relevant to the writers of device drivers 127device drivers whose subsystems (PM domains, device types, device classes and
122whose subsystems (PM domains, device types, device classes and bus types) don't 128bus types) don't provide all power management methods.
123provide all power management methods.
124 129
125Bus drivers implement these methods as appropriate for the hardware and the 130Bus drivers implement these methods as appropriate for the hardware and the
126drivers using it; PCI works differently from USB, and so on. Not many people 131drivers using it; PCI works differently from USB, and so on. Not many people
@@ -145,12 +150,11 @@ The :c:member:`power.can_wakeup` flag just records whether the device (and its
145driver) can physically support wakeup events. The 150driver) can physically support wakeup events. The
146:c:func:`device_set_wakeup_capable()` routine affects this flag. The 151:c:func:`device_set_wakeup_capable()` routine affects this flag. The
147:c:member:`power.wakeup` field is a pointer to an object of type 152:c:member:`power.wakeup` field is a pointer to an object of type
148|struct| :c:type:`wakeup_source` used for controlling whether or not 153|struct wakeup_source| used for controlling whether or not the device should use
149the device should use its system wakeup mechanism and for notifying the 154its system wakeup mechanism and for notifying the PM core of system wakeup
150PM core of system wakeup events signaled by the device. This object is only 155events signaled by the device. This object is only present for wakeup-capable
151present for wakeup-capable devices (i.e. devices whose 156devices (i.e. devices whose :c:member:`can_wakeup` flags are set) and is created
152:c:member:`can_wakeup` flags are set) and is created (or removed) by 157(or removed) by :c:func:`device_set_wakeup_capable()`.
153:c:func:`device_set_wakeup_capable()`.
154 158
155Whether or not a device is capable of issuing wakeup events is a hardware 159Whether or not a device is capable of issuing wakeup events is a hardware
156matter, and the kernel is responsible for keeping track of it. By contrast, 160matter, and the kernel is responsible for keeping track of it. By contrast,
@@ -670,17 +674,17 @@ nested inside another power domain. The nested domain is referred to as the
670sub-domain of the parent domain. 674sub-domain of the parent domain.
671 675
672Support for power domains is provided through the :c:member:`pm_domain` field of 676Support for power domains is provided through the :c:member:`pm_domain` field of
673|struct| :c:type:`device`. This field is a pointer to an object of 677|struct device|. This field is a pointer to an object of type
674type |struct| :c:type:`dev_pm_domain`, defined in :file:`include/linux/pm.h``, 678|struct dev_pm_domain|, defined in :file:`include/linux/pm.h``, providing a set
675providing a set of power management callbacks analogous to the subsystem-level 679of power management callbacks analogous to the subsystem-level and device driver
676and device driver callbacks that are executed for the given device during all 680callbacks that are executed for the given device during all power transitions,
677power transitions, instead of the respective subsystem-level callbacks. 681instead of the respective subsystem-level callbacks. Specifically, if a
678Specifically, if a device's :c:member:`pm_domain` pointer is not NULL, the 682device's :c:member:`pm_domain` pointer is not NULL, the ``->suspend()`` callback
679``->suspend()`` callback from the object pointed to by it will be executed 683from the object pointed to by it will be executed instead of its subsystem's
680instead of its subsystem's (e.g. bus type's) ``->suspend()`` callback and 684(e.g. bus type's) ``->suspend()`` callback and analogously for all of the
681analogously for all of the remaining callbacks. In other words, power 685remaining callbacks. In other words, power management domain callbacks, if
682management domain callbacks, if defined for the given device, always take 686defined for the given device, always take precedence over the callbacks provided
683precedence over the callbacks provided by the device's subsystem (e.g. bus type). 687by the device's subsystem (e.g. bus type).
684 688
685The support for device power management domains is only relevant to platforms 689The support for device power management domains is only relevant to platforms
686needing to use the same device driver power management callbacks in many 690needing to use the same device driver power management callbacks in many