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 | |