Based on kernel version 4.13.3. Page generated on 2017-09-23 13:55 EST.
1 PM Quality Of Service Interface. 2 3 This interface provides a kernel and user mode interface for registering 4 performance expectations by drivers, subsystems and user space applications on 5 one of the parameters. 6 7 Two different PM QoS frameworks are available: 8 1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput, 9 memory_bandwidth. 10 2. the per-device PM QoS framework provides the API to manage the per-device latency 11 constraints and PM QoS flags. 12 13 Each parameters have defined units: 14 * latency: usec 15 * timeout: usec 16 * throughput: kbs (kilo bit / sec) 17 * memory bandwidth: mbs (mega bit / sec) 18 19 20 1. PM QoS framework 21 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 26 abuse. 27 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. 35 36 37 From kernel mode the use of this interface is simple: 38 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 44 pm_qos API functions. 45 46 void pm_qos_update_request(handle, new_target_value): 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 49 target is changed. 50 51 void pm_qos_remove_request(handle): 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. 55 56 int pm_qos_request(param_class): 57 Returns the aggregated value for a given PM QoS class. 58 59 int pm_qos_request_active(handle): 60 Returns if the request is still active, i.e. it has not been removed from a 61 PM QoS class constraints list. 62 63 int pm_qos_add_notifier(param_class, notifier): 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. 66 67 int pm_qos_remove_notifier(int param_class, notifier): 68 Removes the notification callback function for the PM QoS class. 69 70 71 From user mode: 72 Only processes can register a pm_qos request. To provide for automatic 73 cleanup of a process, the interface requires the process to register its 74 parameter requests in the following way: 75 76 To register the default pm_qos target for the specific parameter, the process 77 must open one of /dev/[cpu_dma_latency, network_latency, network_throughput] 78 79 As long as the device node is held open that process has a registered 80 request on the parameter. 81 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 85 translates to a pm_qos_update_request call. 86 87 To remove the user mode request for a target value simply close the device 88 node. 89 90 91 2. PM QoS per-device latency and flags framework 92 93 For each device, there are three lists of PM QoS requests. Two of them are 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. 97 98 The target values of resume latency and active state latency tolerance are 99 simply the minimum of the request values held in the parameter list elements. 100 The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements' 101 values. Two device PM QoS flags are defined currently: PM_QOS_FLAG_NO_POWER_OFF 102 and PM_QOS_FLAG_REMOTE_WAKEUP. 103 104 Note: The aggregated target values are implemented in such a way that reading 105 the aggregated value does not require any locking mechanism. 106 107 108 From kernel mode the use of this interface is the following: 109 110 int dev_pm_qos_add_request(device, handle, type, value): 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 115 dev_pm_qos API functions. 116 117 int dev_pm_qos_update_request(handle, new_value): 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 120 target is changed. 121 122 int dev_pm_qos_remove_request(handle): 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. 126 127 s32 dev_pm_qos_read_value(device): 128 Returns the aggregated value for a given device's constraints list. 129 130 enum pm_qos_flags_status dev_pm_qos_flags(device, mask) 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 136 PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been 137 initialized or the list of requests is empty. 138 139 int dev_pm_qos_add_ancestor_request(dev, handle, type, value) 140 Add a PM QoS request for the first direct ancestor of the given device whose 141 power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests) 142 or whose power.set_latency_tolerance callback pointer is not NULL (for 143 DEV_PM_QOS_LATENCY_TOLERANCE requests). 144 145 int dev_pm_qos_expose_latency_limit(device, value) 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 148 directory allowing user space to manipulate that request. 149 150 void dev_pm_qos_hide_latency_limit(device) 151 Drop the request added by dev_pm_qos_expose_latency_limit() from the device's 152 PM QoS list of resume latency constraints and remove sysfs attribute 153 pm_qos_resume_latency_us from the device's power directory. 154 155 int dev_pm_qos_expose_flags(device, value) 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 158 allowing user space to change these flags' value. 159 160 void dev_pm_qos_hide_flags(device) 161 Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list 162 of flags and remove sysfs attributes pm_qos_no_power_off and pm_qos_remote_wakeup 163 under the device's power directory. 164 165 Notification mechanisms: 166 The per-device PM QoS framework has a per-device notification tree. 167 168 int dev_pm_qos_add_notifier(device, notifier): 169 Adds a notification callback function for the device. 170 The callback is called when the aggregated value of the device constraints list 171 is changed (for resume latency device PM QoS only). 172 173 int dev_pm_qos_remove_notifier(device, notifier): 174 Removes the notification callback function for the device. 175 176 177 Active state latency tolerance 178 179 This device PM QoS type is used to support systems in which hardware may switch 180 to energy-saving operation modes on the fly. In those systems, if the operation 181 mode chosen by the hardware attempts to save energy in an overly aggressive way, 182 it may cause excess latencies to be visible to software, causing it to miss 183 certain protocol requirements or target frame or sample rates etc. 184 185 If there is a latency tolerance control mechanism for a given device available 186 to software, the .set_latency_tolerance callback in that device's dev_pm_info 187 structure should be populated. The routine pointed to by it is should implement 188 whatever is necessary to transfer the effective requirement value to the 189 hardware. 190 191 Whenever the effective latency tolerance changes for the device, its 192 .set_latency_tolerance() callback will be executed and the effective value will 193 be passed to it. If that value is negative, which means that the list of 194 latency tolerance requirements for the device is empty, the callback is expected 195 to switch the underlying hardware latency tolerance control mechanism to an 196 autonomous mode if available. If that value is PM_QOS_LATENCY_ANY, in turn, and 197 the hardware supports a special "no requirement" setting, the callback is 198 expected to use it. That allows software to prevent the hardware from 199 automatically updating the device's latency tolerance in response to its power 200 state changes (e.g. during transitions from D3cold to D0), which generally may 201 be done in the autonomous latency tolerance control mode. 202 203 If .set_latency_tolerance() is present for the device, sysfs attribute 204 pm_qos_latency_tolerance_us will be present in the devivce's power directory. 205 Then, user space can use that attribute to specify its latency tolerance 206 requirement for the device, if any. Writing "any" to it means "no requirement, 207 but do not let the hardware control latency tolerance" and writing "auto" to it 208 allows the hardware to be switched to the autonomous mode if there are no other 209 requirements from the kernel side in the device's list. 210 211 Kernel code can use the functions described above along with the 212 DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type to add, remove and update 213 latency tolerance requirements for devices.