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.
104 the aggregated value does not require any locking mechanism.
107 From kernel mode the use of this interface is the following:
110 Will insert an element into the list for that identified device with the
111 target value. Upon change to this list the new target is recomputed and any
112 registered notifiers are called only if the target value is now different.
113 Clients of dev_pm_qos need to save the handle for future use in other
117 Will update the list element pointed to by the handle with the new target value
118 and recompute the new aggregated target, calling the notification trees if the
122 Will remove the element. After removal it will update the aggregate target and
123 call the notification trees if the target was changed as a result of removing
124 the request.
127 Returns the aggregated value for a given device's constraints list.
130 Check PM QoS flags of the given device against the given mask of flags.
131 The meaning of the return values is as follows:
132 PM_QOS_FLAGS_ALL: All flags from the mask are set
133 PM_QOS_FLAGS_SOME: Some flags from the mask are set
134 PM_QOS_FLAGS_NONE: No flags from the mask are set
136 initialized or the list of requests is empty.
139 Add a PM QoS request for the first direct ancestor of the given device whose
145 Add a request to the device's PM QoS list of resume latency constraints and
146 create a sysfs attribute pm_qos_resume_latency_us under the device's power
150 Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
152 pm_qos_resume_latency_us from the device's power directory.
155 Add a request to the device's PM QoS list of flags and create sysfs attribute
156 pm_qos_no_power_off under the device's power directory allowing user space to
157 change the value of the PM_QOS_FLAG_NO_POWER_OFF flag.
160 Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
161 of flags and remove sysfs attribute pm_qos_no_power_off from the device's power
168 Adds a notification callback function for the device.
169 The callback is called when the aggregated value of the device constraints list
173 Removes the notification callback function for the device.
179 to energy-saving operation modes on the fly. In those systems, if the operation
180 mode chosen by the hardware attempts to save energy in an overly aggressive way,
185 to software, the .set_latency_tolerance callback in that device's dev_pm_info
187 whatever is necessary to transfer the effective requirement value to the
190 Whenever the effective latency tolerance changes for the device, its
191 .set_latency_tolerance() callback will be executed and the effective value will
192 be passed to it. If that value is negative, which means that the list of
193 latency tolerance requirements for the device is empty, the callback is expected
194 to switch the underlying hardware latency tolerance control mechanism to an
196 the hardware supports a special "no requirement" setting, the callback is
197 expected to use it. That allows software to prevent the hardware from
198 automatically updating the device's latency tolerance in response to its power
200 be done in the autonomous latency tolerance control mode.
202 If .set_latency_tolerance() is present for the device, sysfs attribute
203 pm_qos_latency_tolerance_us will be present in the devivce's power directory.
205 requirement for the device, if any. Writing "any" to it means "no requirement,
206 but do not let the hardware control latency tolerance" and writing "auto" to it
207 allows the hardware to be switched to the autonomous mode if there are no other
208 requirements from the kernel side in the device's list.
210 Kernel code can use the functions described above along with the