Loading...
1===============================
2PM Quality Of Service Interface
3===============================
4
5This interface provides a kernel and user mode interface for registering
6performance expectations by drivers, subsystems and user space applications on
7one of the parameters.
8
9Two different PM QoS frameworks are available:
10 * CPU latency QoS.
11 * The per-device PM QoS framework provides the API to manage the
12 per-device latency constraints and PM QoS flags.
13
14The latency unit used in the PM QoS framework is the microsecond (usec).
15
16
171. PM QoS framework
18===================
19
20A global list of CPU latency QoS requests is maintained along with an aggregated
21(effective) target value. The aggregated target value is updated with changes
22to the request list or elements of the list. For CPU latency QoS, the
23aggregated target value is simply the min of the request values held in the list
24elements.
25
26Note: the aggregated target value is implemented as an atomic variable so that
27reading the aggregated value does not require any locking mechanism.
28
29From kernel space the use of this interface is simple:
30
31void cpu_latency_qos_add_request(handle, target_value):
32 Will insert an element into the CPU latency QoS list with the target value.
33 Upon change to this list the new target is recomputed and any registered
34 notifiers are called only if the target value is now different.
35 Clients of PM QoS need to save the returned handle for future use in other
36 PM QoS API functions.
37
38void cpu_latency_qos_update_request(handle, new_target_value):
39 Will update the list element pointed to by the handle with the new target
40 value and recompute the new aggregated target, calling the notification tree
41 if the target is changed.
42
43void cpu_latency_qos_remove_request(handle):
44 Will remove the element. After removal it will update the aggregate target
45 and call the notification tree if the target was changed as a result of
46 removing the request.
47
48int cpu_latency_qos_limit():
49 Returns the aggregated value for the CPU latency QoS.
50
51int cpu_latency_qos_request_active(handle):
52 Returns if the request is still active, i.e. it has not been removed from the
53 CPU latency QoS list.
54
55int cpu_latency_qos_add_notifier(notifier):
56 Adds a notification callback function to the CPU latency QoS. The callback is
57 called when the aggregated value for the CPU latency QoS is changed.
58
59int cpu_latency_qos_remove_notifier(notifier):
60 Removes the notification callback function from the CPU latency QoS.
61
62
63From user space:
64
65The infrastructure exposes one device node, /dev/cpu_dma_latency, for the CPU
66latency QoS.
67
68Only processes can register a PM QoS request. To provide for automatic
69cleanup of a process, the interface requires the process to register its
70parameter requests as follows.
71
72To register the default PM QoS target for the CPU latency QoS, the process must
73open /dev/cpu_dma_latency.
74
75As long as the device node is held open that process has a registered
76request on the parameter.
77
78To change the requested target value, the process needs to write an s32 value to
79the open device node. Alternatively, it can write a hex string for the value
80using the 10 char long format e.g. "0x12345678". This translates to a
81cpu_latency_qos_update_request() call.
82
83To remove the user mode request for a target value simply close the device
84node.
85
86
872. PM QoS per-device latency and flags framework
88================================================
89
90For each device, there are three lists of PM QoS requests. Two of them are
91maintained along with the aggregated targets of resume latency and active
92state latency tolerance (in microseconds) and the third one is for PM QoS flags.
93Values are updated in response to changes of the request list.
94
95The target values of resume latency and active state latency tolerance are
96simply the minimum of the request values held in the parameter list elements.
97The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements'
98values. One device PM QoS flag is defined currently: PM_QOS_FLAG_NO_POWER_OFF.
99
100Note: The aggregated target values are implemented in such a way that reading
101the aggregated value does not require any locking mechanism.
102
103
104From kernel mode the use of this interface is the following:
105
106int dev_pm_qos_add_request(device, handle, type, value):
107 Will insert an element into the list for that identified device with the
108 target value. Upon change to this list the new target is recomputed and any
109 registered notifiers are called only if the target value is now different.
110 Clients of dev_pm_qos need to save the handle for future use in other
111 dev_pm_qos API functions.
112
113int dev_pm_qos_update_request(handle, new_value):
114 Will update the list element pointed to by the handle with the new target
115 value and recompute the new aggregated target, calling the notification
116 trees if the target is changed.
117
118int dev_pm_qos_remove_request(handle):
119 Will remove the element. After removal it will update the aggregate target
120 and call the notification trees if the target was changed as a result of
121 removing the request.
122
123s32 dev_pm_qos_read_value(device, type):
124 Returns the aggregated value for a given device's constraints list.
125
126enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
127 Check PM QoS flags of the given device against the given mask of flags.
128 The meaning of the return values is as follows:
129
130 PM_QOS_FLAGS_ALL:
131 All flags from the mask are set
132 PM_QOS_FLAGS_SOME:
133 Some flags from the mask are set
134 PM_QOS_FLAGS_NONE:
135 No flags from the mask are set
136 PM_QOS_FLAGS_UNDEFINED:
137 The device's PM QoS structure has not been initialized
138 or the list of requests is empty.
139
140int dev_pm_qos_add_ancestor_request(dev, handle, type, value)
141 Add a PM QoS request for the first direct ancestor of the given device whose
142 power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
143 or whose power.set_latency_tolerance callback pointer is not NULL (for
144 DEV_PM_QOS_LATENCY_TOLERANCE requests).
145
146int dev_pm_qos_expose_latency_limit(device, value)
147 Add a request to the device's PM QoS list of resume latency constraints and
148 create a sysfs attribute pm_qos_resume_latency_us under the device's power
149 directory allowing user space to manipulate that request.
150
151void dev_pm_qos_hide_latency_limit(device)
152 Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
153 PM QoS list of resume latency constraints and remove sysfs attribute
154 pm_qos_resume_latency_us from the device's power directory.
155
156int dev_pm_qos_expose_flags(device, value)
157 Add a request to the device's PM QoS list of flags and create sysfs attribute
158 pm_qos_no_power_off under the device's power directory allowing user space to
159 change the value of the PM_QOS_FLAG_NO_POWER_OFF flag.
160
161void dev_pm_qos_hide_flags(device)
162 Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS
163 list of flags and remove sysfs attribute pm_qos_no_power_off from the device's
164 power directory.
165
166Notification mechanisms:
167
168The per-device PM QoS framework has a per-device notification tree.
169
170int dev_pm_qos_add_notifier(device, notifier, type):
171 Adds a notification callback function for the device for a particular request
172 type.
173
174 The callback is called when the aggregated value of the device constraints
175 list is changed.
176
177int dev_pm_qos_remove_notifier(device, notifier, type):
178 Removes the notification callback function for the device.
179
180
181Active state latency tolerance
182^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
183
184This device PM QoS type is used to support systems in which hardware may switch
185to energy-saving operation modes on the fly. In those systems, if the operation
186mode chosen by the hardware attempts to save energy in an overly aggressive way,
187it may cause excess latencies to be visible to software, causing it to miss
188certain protocol requirements or target frame or sample rates etc.
189
190If there is a latency tolerance control mechanism for a given device available
191to software, the .set_latency_tolerance callback in that device's dev_pm_info
192structure should be populated. The routine pointed to by it is should implement
193whatever is necessary to transfer the effective requirement value to the
194hardware.
195
196Whenever the effective latency tolerance changes for the device, its
197.set_latency_tolerance() callback will be executed and the effective value will
198be passed to it. If that value is negative, which means that the list of
199latency tolerance requirements for the device is empty, the callback is expected
200to switch the underlying hardware latency tolerance control mechanism to an
201autonomous mode if available. If that value is PM_QOS_LATENCY_ANY, in turn, and
202the hardware supports a special "no requirement" setting, the callback is
203expected to use it. That allows software to prevent the hardware from
204automatically updating the device's latency tolerance in response to its power
205state changes (e.g. during transitions from D3cold to D0), which generally may
206be done in the autonomous latency tolerance control mode.
207
208If .set_latency_tolerance() is present for the device, sysfs attribute
209pm_qos_latency_tolerance_us will be present in the devivce's power directory.
210Then, user space can use that attribute to specify its latency tolerance
211requirement for the device, if any. Writing "any" to it means "no requirement,
212but do not let the hardware control latency tolerance" and writing "auto" to it
213allows the hardware to be switched to the autonomous mode if there are no other
214requirements from the kernel side in the device's list.
215
216Kernel code can use the functions described above along with the
217DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type to add, remove and update
218latency tolerance requirements for devices.
1===============================
2PM Quality Of Service Interface
3===============================
4
5This interface provides a kernel and user mode interface for registering
6performance expectations by drivers, subsystems and user space applications on
7one of the parameters.
8
9Two different PM QoS frameworks are available:
10 * CPU latency QoS.
11 * The per-device PM QoS framework provides the API to manage the
12 per-device latency constraints and PM QoS flags.
13
14The latency unit used in the PM QoS framework is the microsecond (usec).
15
16
171. PM QoS framework
18===================
19
20A global list of CPU latency QoS requests is maintained along with an aggregated
21(effective) target value. The aggregated target value is updated with changes
22to the request list or elements of the list. For CPU latency QoS, the
23aggregated target value is simply the min of the request values held in the list
24elements.
25
26Note: the aggregated target value is implemented as an atomic variable so that
27reading the aggregated value does not require any locking mechanism.
28
29From kernel space the use of this interface is simple:
30
31void cpu_latency_qos_add_request(handle, target_value):
32 Will insert an element into the CPU latency QoS list with the target value.
33 Upon change to this list the new target is recomputed and any registered
34 notifiers are called only if the target value is now different.
35 Clients of PM QoS need to save the returned handle for future use in other
36 PM QoS API functions.
37
38void cpu_latency_qos_update_request(handle, new_target_value):
39 Will update the list element pointed to by the handle with the new target
40 value and recompute the new aggregated target, calling the notification tree
41 if the target is changed.
42
43void cpu_latency_qos_remove_request(handle):
44 Will remove the element. After removal it will update the aggregate target
45 and call the notification tree if the target was changed as a result of
46 removing the request.
47
48int cpu_latency_qos_limit():
49 Returns the aggregated value for the CPU latency QoS.
50
51int cpu_latency_qos_request_active(handle):
52 Returns if the request is still active, i.e. it has not been removed from the
53 CPU latency QoS list.
54
55int cpu_latency_qos_add_notifier(notifier):
56 Adds a notification callback function to the CPU latency QoS. The callback is
57 called when the aggregated value for the CPU latency QoS is changed.
58
59int cpu_latency_qos_remove_notifier(notifier):
60 Removes the notification callback function from the CPU latency QoS.
61
62
63From user space:
64
65The infrastructure exposes one device node, /dev/cpu_dma_latency, for the CPU
66latency QoS.
67
68Only processes can register a PM QoS request. To provide for automatic
69cleanup of a process, the interface requires the process to register its
70parameter requests as follows.
71
72To register the default PM QoS target for the CPU latency QoS, the process must
73open /dev/cpu_dma_latency.
74
75As long as the device node is held open that process has a registered
76request on the parameter.
77
78To change the requested target value, the process needs to write an s32 value to
79the open device node. Alternatively, it can write a hex string for the value
80using the 10 char long format e.g. "0x12345678". This translates to a
81cpu_latency_qos_update_request() call.
82
83To remove the user mode request for a target value simply close the device
84node.
85
86
872. PM QoS per-device latency and flags framework
88================================================
89
90For each device, there are three lists of PM QoS requests. Two of them are
91maintained along with the aggregated targets of resume latency and active
92state latency tolerance (in microseconds) and the third one is for PM QoS flags.
93Values are updated in response to changes of the request list.
94
95The target values of resume latency and active state latency tolerance are
96simply the minimum of the request values held in the parameter list elements.
97The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements'
98values. One device PM QoS flag is defined currently: PM_QOS_FLAG_NO_POWER_OFF.
99
100Note: The aggregated target values are implemented in such a way that reading
101the aggregated value does not require any locking mechanism.
102
103
104From kernel mode the use of this interface is the following:
105
106int dev_pm_qos_add_request(device, handle, type, value):
107 Will insert an element into the list for that identified device with the
108 target value. Upon change to this list the new target is recomputed and any
109 registered notifiers are called only if the target value is now different.
110 Clients of dev_pm_qos need to save the handle for future use in other
111 dev_pm_qos API functions.
112
113int dev_pm_qos_update_request(handle, new_value):
114 Will update the list element pointed to by the handle with the new target
115 value and recompute the new aggregated target, calling the notification
116 trees if the target is changed.
117
118int dev_pm_qos_remove_request(handle):
119 Will remove the element. After removal it will update the aggregate target
120 and call the notification trees if the target was changed as a result of
121 removing the request.
122
123s32 dev_pm_qos_read_value(device, type):
124 Returns the aggregated value for a given device's constraints list.
125
126enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
127 Check PM QoS flags of the given device against the given mask of flags.
128 The meaning of the return values is as follows:
129
130 PM_QOS_FLAGS_ALL:
131 All flags from the mask are set
132 PM_QOS_FLAGS_SOME:
133 Some flags from the mask are set
134 PM_QOS_FLAGS_NONE:
135 No flags from the mask are set
136 PM_QOS_FLAGS_UNDEFINED:
137 The device's PM QoS structure has not been initialized
138 or the list of requests is empty.
139
140int dev_pm_qos_add_ancestor_request(dev, handle, type, value)
141 Add a PM QoS request for the first direct ancestor of the given device whose
142 power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
143 or whose power.set_latency_tolerance callback pointer is not NULL (for
144 DEV_PM_QOS_LATENCY_TOLERANCE requests).
145
146int dev_pm_qos_expose_latency_limit(device, value)
147 Add a request to the device's PM QoS list of resume latency constraints and
148 create a sysfs attribute pm_qos_resume_latency_us under the device's power
149 directory allowing user space to manipulate that request.
150
151void dev_pm_qos_hide_latency_limit(device)
152 Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
153 PM QoS list of resume latency constraints and remove sysfs attribute
154 pm_qos_resume_latency_us from the device's power directory.
155
156int dev_pm_qos_expose_flags(device, value)
157 Add a request to the device's PM QoS list of flags and create sysfs attribute
158 pm_qos_no_power_off under the device's power directory allowing user space to
159 change the value of the PM_QOS_FLAG_NO_POWER_OFF flag.
160
161void dev_pm_qos_hide_flags(device)
162 Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS
163 list of flags and remove sysfs attribute pm_qos_no_power_off from the device's
164 power directory.
165
166Notification mechanisms:
167
168The per-device PM QoS framework has a per-device notification tree.
169
170int dev_pm_qos_add_notifier(device, notifier, type):
171 Adds a notification callback function for the device for a particular request
172 type.
173
174 The callback is called when the aggregated value of the device constraints
175 list is changed.
176
177int dev_pm_qos_remove_notifier(device, notifier, type):
178 Removes the notification callback function for the device.
179
180
181Active state latency tolerance
182^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
183
184This device PM QoS type is used to support systems in which hardware may switch
185to energy-saving operation modes on the fly. In those systems, if the operation
186mode chosen by the hardware attempts to save energy in an overly aggressive way,
187it may cause excess latencies to be visible to software, causing it to miss
188certain protocol requirements or target frame or sample rates etc.
189
190If there is a latency tolerance control mechanism for a given device available
191to software, the .set_latency_tolerance callback in that device's dev_pm_info
192structure should be populated. The routine pointed to by it is should implement
193whatever is necessary to transfer the effective requirement value to the
194hardware.
195
196Whenever the effective latency tolerance changes for the device, its
197.set_latency_tolerance() callback will be executed and the effective value will
198be passed to it. If that value is negative, which means that the list of
199latency tolerance requirements for the device is empty, the callback is expected
200to switch the underlying hardware latency tolerance control mechanism to an
201autonomous mode if available. If that value is PM_QOS_LATENCY_ANY, in turn, and
202the hardware supports a special "no requirement" setting, the callback is
203expected to use it. That allows software to prevent the hardware from
204automatically updating the device's latency tolerance in response to its power
205state changes (e.g. during transitions from D3cold to D0), which generally may
206be done in the autonomous latency tolerance control mode.
207
208If .set_latency_tolerance() is present for the device, sysfs attribute
209pm_qos_latency_tolerance_us will be present in the devivce's power directory.
210Then, user space can use that attribute to specify its latency tolerance
211requirement for the device, if any. Writing "any" to it means "no requirement,
212but do not let the hardware control latency tolerance" and writing "auto" to it
213allows the hardware to be switched to the autonomous mode if there are no other
214requirements from the kernel side in the device's list.
215
216Kernel code can use the functions described above along with the
217DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type to add, remove and update
218latency tolerance requirements for devices.