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