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