diff options
Diffstat (limited to 'Documentation/pm_qos_interface.txt')
-rw-r--r-- | Documentation/pm_qos_interface.txt | 59 |
1 files changed, 59 insertions, 0 deletions
diff --git a/Documentation/pm_qos_interface.txt b/Documentation/pm_qos_interface.txt new file mode 100644 index 000000000000..49adb1a33514 --- /dev/null +++ b/Documentation/pm_qos_interface.txt | |||
@@ -0,0 +1,59 @@ | |||
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 | |||