Lines Matching refs:the

5 one of the parameters.
10 2. the per-device PM QoS framework provides the API to manage the per-device latency
24 and pm_qos_params.h.  This is done because having the available parameters
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:
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
47 Will update the list element pointed to by the handle with the new target value
48 and recompute the new aggregated target, calling the notification tree if the
52 Will remove the element.  After removal it will update the aggregate target and
53 call the notification tree if the target was changed as a result of removing
54 the request.
57 Returns the aggregated value for a given PM QoS class.
60 Returns if the request is still active, i.e. it has not been removed from a
64 Adds a notification callback function to the PM QoS class. The callback is
65 called when the aggregated value for the PM QoS class is changed.
68 Removes the notification callback function for the PM QoS class.
73 cleanup of a process, the interface requires the process to register its
74 parameter requests in the following way:
76 To register the default pm_qos target for the specific parameter, the process
79 As long as the device node is held open that process has a registered
80 request on the parameter.
82 To change the requested target value the process needs to write an s32 value to
83 the open device node.  Alternatively the user mode program could write a hex
84 string for the value using 10 char long format e.g. "0x12345678".  This
87 To remove the user mode request for a target value simply close the device
94 maintained along with the aggregated targets of resume latency and active
95 state latency tolerance (in microseconds) and the third one is for PM QoS flags.
96 Values are updated in response to changes of the request list.
99 simply the minimum of the request values held in the parameter list elements.
105 the aggregated value does not require any locking mechanism.
108 From kernel mode the use of this interface is the following:
111 Will insert an element into the list for that identified device with the
112 target value.  Upon change to this list the new target is recomputed and any
113 registered notifiers are called only if the target value is now different.
114 Clients of dev_pm_qos need to save the handle for future use in other
118 Will update the list element pointed to by the handle with the new target value
119 and recompute the new aggregated target, calling the notification trees if the
123 Will remove the element.  After removal it will update the aggregate target and
124 call the notification trees if the target was changed as a result of removing
125 the request.
128 Returns the aggregated value for a given device's constraints list.
131 Check PM QoS flags of the given device against the given mask of flags.
132 The meaning of the return values is as follows:
133 	PM_QOS_FLAGS_ALL: All flags from the mask are set
134 	PM_QOS_FLAGS_SOME: Some flags from the mask are set
135 	PM_QOS_FLAGS_NONE: No flags from the mask are set
137 			initialized or the list of requests is empty.
140 Add a PM QoS request for the first direct ancestor of the given device whose
146 Add a request to the device's PM QoS list of resume latency constraints and
147 create a sysfs attribute pm_qos_resume_latency_us under the device's power
151 Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
153 pm_qos_resume_latency_us from the device's power directory.
156 Add a request to the device's PM QoS list of flags and create sysfs attributes
157 pm_qos_no_power_off and pm_qos_remote_wakeup under the device's power directory
161 Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
163 under the device's power directory.
170 Adds a notification callback function for the device.
171 The callback is called when the aggregated value of the device constraints list
175 Removes the notification callback function for the device.
178 Adds a notification callback function in the global notification tree of the
180 The callback is called when the aggregated value for any device is changed
184 Removes the notification callback function from the global notification tree
185 of the framework.
191 to energy-saving operation modes on the fly.  In those systems, if the operation
192 mode chosen by the hardware attempts to save energy in an overly aggressive way,
197 to software, the .set_latency_tolerance callback in that device's dev_pm_info
199 whatever is necessary to transfer the effective requirement value to the
202 Whenever the effective latency tolerance changes for the device, its
203 .set_latency_tolerance() callback will be executed and the effective value will
204 be passed to it.  If that value is negative, which means that the list of
205 latency tolerance requirements for the device is empty, the callback is expected
206 to switch the underlying hardware latency tolerance control mechanism to an
208 the hardware supports a special "no requirement" setting, the callback is
209 expected to use it.  That allows software to prevent the hardware from
210 automatically updating the device's latency tolerance in response to its power
212 be done in the autonomous latency tolerance control mode.
214 If .set_latency_tolerance() is present for the device, sysfs attribute
215 pm_qos_latency_tolerance_us will be present in the devivce's power directory.
217 requirement for the device, if any.  Writing "any" to it means "no requirement,
218 but do not let the hardware control latency tolerance" and writing "auto" to it
219 allows the hardware to be switched to the autonomous mode if there are no other
220 requirements from the kernel side in the device's list.
222 Kernel code can use the functions described above along with the