| Richard Hughes | bf1db69 | 2008-08-05 13:01:35 -0700 | [diff] [blame] | 1 | PM Quality Of Service Interface. | 
| Mark Gross | d82b351 | 2008-02-04 22:30:08 -0800 | [diff] [blame] | 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 | Currently we have {cpu_dma_latency, network_latency, network_throughput} as the | 
 | 8 | initial set of pm_qos parameters. | 
 | 9 |  | 
| Richard Hughes | bf1db69 | 2008-08-05 13:01:35 -0700 | [diff] [blame] | 10 | Each parameters have defined units: | 
 | 11 |  * latency: usec | 
 | 12 |  * timeout: usec | 
 | 13 |  * throughput: kbs (kilo bit / sec) | 
 | 14 |  | 
| Mark Gross | d82b351 | 2008-02-04 22:30:08 -0800 | [diff] [blame] | 15 | The infrastructure exposes multiple misc device nodes one per implemented | 
 | 16 | parameter.  The set of parameters implement is defined by pm_qos_power_init() | 
 | 17 | and pm_qos_params.h.  This is done because having the available parameters | 
 | 18 | being runtime configurable or changeable from a driver was seen as too easy to | 
 | 19 | abuse. | 
 | 20 |  | 
 | 21 | For each parameter a list of performance requirements is maintained along with | 
 | 22 | an aggregated target value.  The aggregated target value is updated with | 
 | 23 | changes to the requirement list or elements of the list.  Typically the | 
 | 24 | aggregated target value is simply the max or min of the requirement values held | 
 | 25 | in the parameter list elements. | 
 | 26 |  | 
 | 27 | From kernel mode the use of this interface is simple: | 
 | 28 | pm_qos_add_requirement(param_id, name, target_value): | 
 | 29 | Will insert a named element in the list for that identified PM_QOS parameter | 
 | 30 | with the target value.  Upon change to this list the new target is recomputed | 
 | 31 | and any registered notifiers are called only if the target value is now | 
 | 32 | different. | 
 | 33 |  | 
 | 34 | pm_qos_update_requirement(param_id, name, new_target_value): | 
 | 35 | Will search the list identified by the param_id for the named list element and | 
 | 36 | then update its target value, calling the notification tree if the aggregated | 
 | 37 | target is changed.  with that name is already registered. | 
 | 38 |  | 
 | 39 | pm_qos_remove_requirement(param_id, name): | 
 | 40 | Will search the identified list for the named element and remove it, after | 
 | 41 | removal it will update the aggregate target and call the notification tree if | 
 | 42 | the target was changed as a result of removing the named requirement. | 
 | 43 |  | 
 | 44 |  | 
 | 45 | From user mode: | 
 | 46 | Only processes can register a pm_qos requirement.  To provide for automatic | 
 | 47 | cleanup for process the interface requires the process to register its | 
 | 48 | parameter requirements in the following way: | 
 | 49 |  | 
 | 50 | To register the default pm_qos target for the specific parameter, the process | 
 | 51 | must open one of /dev/[cpu_dma_latency, network_latency, network_throughput] | 
 | 52 |  | 
 | 53 | As long as the device node is held open that process has a registered | 
 | 54 | requirement on the parameter.  The name of the requirement is "process_<PID>" | 
 | 55 | derived from the current->pid from within the open system call. | 
 | 56 |  | 
 | 57 | To change the requested target value the process needs to write a s32 value to | 
 | 58 | the open device node.  This translates to a pm_qos_update_requirement call. | 
 | 59 |  | 
 | 60 | To remove the user mode request for a target value simply close the device | 
 | 61 | node. | 
 | 62 |  | 
 | 63 |  | 
 | 64 |  |