1 PM Quality Of Service Interface.
3 This interface provides a kernel and user mode interface for registering
4 performance expectations by drivers, subsystems and user space applications on
7 Two different PM QoS frameworks are available:
8 1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput,
10 2. the per-device PM QoS framework provides the API to manage the per-device latency
11 constraints and PM QoS flags.
13 Each parameters have defined units:
16 * throughput: kbs (kilo bit / sec)
17 * memory bandwidth: mbs (mega bit / sec)
22 The infrastructure exposes multiple misc device nodes one per implemented
23 parameter. The set of parameters implement is defined by pm_qos_power_init()
24 and pm_qos_params.h. This is done because having the available parameters
25 being runtime configurable or changeable from a driver was seen as too easy to
28 For each parameter a list of performance requests is maintained along with
29 an aggregated target value. The aggregated target value is updated with
30 changes to the request list or elements of the list. Typically the
31 aggregated target value is simply the max or min of the request values held
32 in the parameter list elements.
33 Note: the aggregated target value is implemented as an atomic variable so that
34 reading the aggregated value does not require any locking mechanism.
37 From kernel mode the use of this interface is simple:
39 void pm_qos_add_request(handle, param_class, target_value):
40 Will insert an element into the list for that identified PM QoS class with the
41 target value. Upon change to this list the new target is recomputed and any
42 registered notifiers are called only if the target value is now different.
43 Clients of pm_qos need to save the returned handle for future use in other
46 The handle is a pm_qos_request object. By default the request object sets the
47 request type to PM_QOS_REQ_ALL_CORES, in which case, the PM QoS request
48 applies to all cores. However, the driver can also specify a request type to
51 PM_QOS_REQ_AFFINE_CORES,
52 PM_QOS_REQ_AFFINE_IRQ,
54 Specify the cpumask when type is set to PM_QOS_REQ_AFFINE_CORES and specify
55 the IRQ number with PM_QOS_REQ_AFFINE_IRQ.
57 void pm_qos_update_request(handle, new_target_value):
58 Will update the list element pointed to by the handle with the new target value
59 and recompute the new aggregated target, calling the notification tree if the
62 void pm_qos_remove_request(handle):
63 Will remove the element. After removal it will update the aggregate target and
64 call the notification tree if the target was changed as a result of removing
67 int pm_qos_request(param_class):
68 Returns the aggregated value for a given PM QoS class.
70 int pm_qos_request_for_cpu(param_class, cpu):
71 Returns the aggregated value for a given PM QoS class for the specified cpu.
73 int pm_qos_request_for_cpumask(param_class, cpumask):
74 Returns the aggregated value for a given PM QoS class for the specified
77 int pm_qos_request_active(handle):
78 Returns if the request is still active, i.e. it has not been removed from a
79 PM QoS class constraints list.
81 int pm_qos_add_notifier(param_class, notifier):
82 Adds a notification callback function to the PM QoS class. The callback is
83 called when the aggregated value for the PM QoS class is changed.
85 int pm_qos_remove_notifier(int param_class, notifier):
86 Removes the notification callback function for the PM QoS class.
90 Only processes can register a pm_qos request. To provide for automatic
91 cleanup of a process, the interface requires the process to register its
92 parameter requests in the following way:
94 To register the default pm_qos target for the specific parameter, the process
95 must open one of /dev/[cpu_dma_latency, network_latency, network_throughput]
97 As long as the device node is held open that process has a registered
98 request on the parameter.
100 To change the requested target value the process needs to write an s32 value to
101 the open device node. Alternatively the user mode program could write a hex
102 string for the value using 10 char long format e.g. "0x12345678". This
103 translates to a pm_qos_update_request call.
105 To remove the user mode request for a target value simply close the device
109 2. PM QoS per-device latency and flags framework
111 For each device, there are three lists of PM QoS requests. Two of them are
112 maintained along with the aggregated targets of resume latency and active
113 state latency tolerance (in microseconds) and the third one is for PM QoS flags.
114 Values are updated in response to changes of the request list.
116 The target values of resume latency and active state latency tolerance are
117 simply the minimum of the request values held in the parameter list elements.
118 The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements'
119 values. Two device PM QoS flags are defined currently: PM_QOS_FLAG_NO_POWER_OFF
120 and PM_QOS_FLAG_REMOTE_WAKEUP.
122 Note: The aggregated target values are implemented in such a way that reading
123 the aggregated value does not require any locking mechanism.
126 From kernel mode the use of this interface is the following:
128 int dev_pm_qos_add_request(device, handle, type, value):
129 Will insert an element into the list for that identified device with the
130 target value. Upon change to this list the new target is recomputed and any
131 registered notifiers are called only if the target value is now different.
132 Clients of dev_pm_qos need to save the handle for future use in other
133 dev_pm_qos API functions.
135 int dev_pm_qos_update_request(handle, new_value):
136 Will update the list element pointed to by the handle with the new target value
137 and recompute the new aggregated target, calling the notification trees if the
140 int dev_pm_qos_remove_request(handle):
141 Will remove the element. After removal it will update the aggregate target and
142 call the notification trees if the target was changed as a result of removing
145 s32 dev_pm_qos_read_value(device):
146 Returns the aggregated value for a given device's constraints list.
148 enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
149 Check PM QoS flags of the given device against the given mask of flags.
150 The meaning of the return values is as follows:
151 PM_QOS_FLAGS_ALL: All flags from the mask are set
152 PM_QOS_FLAGS_SOME: Some flags from the mask are set
153 PM_QOS_FLAGS_NONE: No flags from the mask are set
154 PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been
155 initialized or the list of requests is empty.
157 int dev_pm_qos_add_ancestor_request(dev, handle, type, value)
158 Add a PM QoS request for the first direct ancestor of the given device whose
159 power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
160 or whose power.set_latency_tolerance callback pointer is not NULL (for
161 DEV_PM_QOS_LATENCY_TOLERANCE requests).
163 int dev_pm_qos_expose_latency_limit(device, value)
164 Add a request to the device's PM QoS list of resume latency constraints and
165 create a sysfs attribute pm_qos_resume_latency_us under the device's power
166 directory allowing user space to manipulate that request.
168 void dev_pm_qos_hide_latency_limit(device)
169 Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
170 PM QoS list of resume latency constraints and remove sysfs attribute
171 pm_qos_resume_latency_us from the device's power directory.
173 int dev_pm_qos_expose_flags(device, value)
174 Add a request to the device's PM QoS list of flags and create sysfs attributes
175 pm_qos_no_power_off and pm_qos_remote_wakeup under the device's power directory
176 allowing user space to change these flags' value.
178 void dev_pm_qos_hide_flags(device)
179 Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
180 of flags and remove sysfs attributes pm_qos_no_power_off and pm_qos_remote_wakeup
181 under the device's power directory.
183 Notification mechanisms:
184 The per-device PM QoS framework has 2 different and distinct notification trees:
185 a per-device notification tree and a global notification tree.
187 int dev_pm_qos_add_notifier(device, notifier):
188 Adds a notification callback function for the device.
189 The callback is called when the aggregated value of the device constraints list
190 is changed (for resume latency device PM QoS only).
192 int dev_pm_qos_remove_notifier(device, notifier):
193 Removes the notification callback function for the device.
195 int dev_pm_qos_add_global_notifier(notifier):
196 Adds a notification callback function in the global notification tree of the
198 The callback is called when the aggregated value for any device is changed
199 (for resume latency device PM QoS only).
201 int dev_pm_qos_remove_global_notifier(notifier):
202 Removes the notification callback function from the global notification tree
206 Active state latency tolerance
208 This device PM QoS type is used to support systems in which hardware may switch
209 to energy-saving operation modes on the fly. In those systems, if the operation
210 mode chosen by the hardware attempts to save energy in an overly aggressive way,
211 it may cause excess latencies to be visible to software, causing it to miss
212 certain protocol requirements or target frame or sample rates etc.
214 If there is a latency tolerance control mechanism for a given device available
215 to software, the .set_latency_tolerance callback in that device's dev_pm_info
216 structure should be populated. The routine pointed to by it is should implement
217 whatever is necessary to transfer the effective requirement value to the
220 Whenever the effective latency tolerance changes for the device, its
221 .set_latency_tolerance() callback will be executed and the effective value will
222 be passed to it. If that value is negative, which means that the list of
223 latency tolerance requirements for the device is empty, the callback is expected
224 to switch the underlying hardware latency tolerance control mechanism to an
225 autonomous mode if available. If that value is PM_QOS_LATENCY_ANY, in turn, and
226 the hardware supports a special "no requirement" setting, the callback is
227 expected to use it. That allows software to prevent the hardware from
228 automatically updating the device's latency tolerance in response to its power
229 state changes (e.g. during transitions from D3cold to D0), which generally may
230 be done in the autonomous latency tolerance control mode.
232 If .set_latency_tolerance() is present for the device, sysfs attribute
233 pm_qos_latency_tolerance_us will be present in the devivce's power directory.
234 Then, user space can use that attribute to specify its latency tolerance
235 requirement for the device, if any. Writing "any" to it means "no requirement,
236 but do not let the hardware control latency tolerance" and writing "auto" to it
237 allows the hardware to be switched to the autonomous mode if there are no other
238 requirements from the kernel side in the device's list.
240 Kernel code can use the functions described above along with the
241 DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type to add, remove and update
242 latency tolerance requirements for devices.