Documentation/power/pm_qos_interface.rst

   1 ===============================
   2 PM Quality Of Service Interface
   3 ===============================
   4
   5 This interface provides a kernel and user mode interface for registering
   6 performance expectations by drivers, subsystems and user space applications on
   7 one of the parameters.
   8
   9 Two different PM QoS frameworks are available:
  10 1. PM QoS classes for cpu_dma_latency
  11 2. The per-device PM QoS framework provides the API to manage the
  12    per-device latency constraints and PM QoS flags.
  13
  14 Each 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
  22 1. PM QoS framework
  23 ===================
  24
  25 The infrastructure exposes multiple misc device nodes one per implemented
  26 parameter.  The set of parameters implement is defined by pm_qos_power_init()
  27 and pm_qos_params.h.  This is done because having the available parameters
  28 being runtime configurable or changeable from a driver was seen as too easy to
  29 abuse.
  30
  31 For each parameter a list of performance requests is maintained along with
  32 an aggregated target value.  The aggregated target value is updated with
  33 changes to the request list or elements of the list.  Typically the
  34 aggregated target value is simply the max or min of the request values held
  35 in the parameter list elements.
  36 Note: the aggregated target value is implemented as an atomic variable so that
  37 reading the aggregated value does not require any locking mechanism.
  38
  39
  40 From kernel mode the use of this interface is simple:
  41
  42 void 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
  49 void 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
  54 void 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
  59 int pm_qos_request(param_class):
  60   Returns the aggregated value for a given PM QoS class.
  61
  62 int 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
  66 int 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
  70 int pm_qos_remove_notifier(int param_class, notifier):
  71   Removes the notification callback function for the PM QoS class.
  72
  73
  74 From user mode:
  75
  76 Only processes can register a pm_qos request.  To provide for automatic
  77 cleanup of a process, the interface requires the process to register its
  78 parameter requests in the following way:
  79
  80 To register the default pm_qos target for the specific parameter, the process
  81 must open /dev/cpu_dma_latency
  82
  83 As long as the device node is held open that process has a registered
  84 request on the parameter.
  85
  86 To change the requested target value the process needs to write an s32 value to
  87 the open device node.  Alternatively the user mode program could write a hex
  88 string for the value using 10 char long format e.g. "0x12345678".  This
  89 translates to a pm_qos_update_request call.
  90
  91 To remove the user mode request for a target value simply close the device
  92 node.
  93
  94
  95 2. PM QoS per-device latency and flags framework
  96 ================================================
  97
  98 For each device, there are three lists of PM QoS requests. Two of them are
  99 maintained along with the aggregated targets of resume latency and active
 100 state latency tolerance (in microseconds) and the third one is for PM QoS flags.
 101 Values are updated in response to changes of the request list.
 102
 103 The target values of resume latency and active state latency tolerance are
 104 simply the minimum of the request values held in the parameter list elements.
 105 The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements'
 106 values.  One device PM QoS flag is defined currently: PM_QOS_FLAG_NO_POWER_OFF.
 107
 108 Note: The aggregated target values are implemented in such a way that reading
 109 the aggregated value does not require any locking mechanism.
 110
 111
 112 From kernel mode the use of this interface is the following:
 113
 114 int 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
 121 int 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
 126 int 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
 131 s32 dev_pm_qos_read_value(device, type):
 132   Returns the aggregated value for a given device's constraints list.
 133
 134 enum 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
 148 int 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
 154 int 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
 159 void 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
 164 int 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
 169 void 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
 174 Notification mechanisms:
 175
 176 The per-device PM QoS framework has a per-device notification tree.
 177
 178 int 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
 185 int dev_pm_qos_remove_notifier(device, notifier, type):
 186   Removes the notification callback function for the device.
 187
 188
 189 Active state latency tolerance
 190 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 191
 192 This device PM QoS type is used to support systems in which hardware may switch
 193 to energy-saving operation modes on the fly.  In those systems, if the operation
 194 mode chosen by the hardware attempts to save energy in an overly aggressive way,
 195 it may cause excess latencies to be visible to software, causing it to miss
 196 certain protocol requirements or target frame or sample rates etc.
 197
 198 If there is a latency tolerance control mechanism for a given device available
 199 to software, the .set_latency_tolerance callback in that device's dev_pm_info
 200 structure should be populated.  The routine pointed to by it is should implement
 201 whatever is necessary to transfer the effective requirement value to the
 202 hardware.
 203
 204 Whenever the effective latency tolerance changes for the device, its
 205 .set_latency_tolerance() callback will be executed and the effective value will
 206 be passed to it.  If that value is negative, which means that the list of
 207 latency tolerance requirements for the device is empty, the callback is expected
 208 to switch the underlying hardware latency tolerance control mechanism to an
 209 autonomous mode if available.  If that value is PM_QOS_LATENCY_ANY, in turn, and
 210 the hardware supports a special "no requirement" setting, the callback is
 211 expected to use it.  That allows software to prevent the hardware from
 212 automatically updating the device's latency tolerance in response to its power
 213 state changes (e.g. during transitions from D3cold to D0), which generally may
 214 be done in the autonomous latency tolerance control mode.
 215
 216 If .set_latency_tolerance() is present for the device, sysfs attribute
 217 pm_qos_latency_tolerance_us will be present in the devivce's power directory.
 218 Then, user space can use that attribute to specify its latency tolerance
 219 requirement for the device, if any.  Writing "any" to it means "no requirement,
 220 but do not let the hardware control latency tolerance" and writing "auto" to it
 221 allows the hardware to be switched to the autonomous mode if there are no other
 222 requirements from the kernel side in the device's list.
 223
 224 Kernel code can use the functions described above along with the
 225 DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type to add, remove and update
 226 latency tolerance requirements for devices.