aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/power/pm_qos_interface.txt
diff options
context:
space:
mode:
authorRandy Dunlap <randy.dunlap@oracle.com>2008-03-12 18:10:51 -0400
committerLen Brown <len.brown@intel.com>2008-03-12 18:10:51 -0400
commit53471121a8aad3f0b590bfce7c95a1f5f52150f3 (patch)
treebadfd31e8602fab32d9b5e693c6558e32e298e7d /Documentation/power/pm_qos_interface.txt
parenta09a20b526fde0611b49b76521e3c546a47216a5 (diff)
documentation: Move power-related files to Documentation/power/
Move 00-INDEX entries to power/00-INDEX (and add entry for pm_qos_interface.txt). Update references to moved filenames. Fix some trailing whitespace. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'Documentation/power/pm_qos_interface.txt')
-rw-r--r--Documentation/power/pm_qos_interface.txt59
1 files changed, 59 insertions, 0 deletions
diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt
new file mode 100644
index 000000000000..49adb1a33514
--- /dev/null
+++ b/Documentation/power/pm_qos_interface.txt
@@ -0,0 +1,59 @@
1PM quality of Service interface.
2
3This interface provides a kernel and user mode interface for registering
4performance expectations by drivers, subsystems and user space applications on
5one of the parameters.
6
7Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
8initial set of pm_qos parameters.
9
10The infrastructure exposes multiple misc device nodes one per implemented
11parameter. The set of parameters implement is defined by pm_qos_power_init()
12and pm_qos_params.h. This is done because having the available parameters
13being runtime configurable or changeable from a driver was seen as too easy to
14abuse.
15
16For each parameter a list of performance requirements is maintained along with
17an aggregated target value. The aggregated target value is updated with
18changes to the requirement list or elements of the list. Typically the
19aggregated target value is simply the max or min of the requirement values held
20in the parameter list elements.
21
22From kernel mode the use of this interface is simple:
23pm_qos_add_requirement(param_id, name, target_value):
24Will insert a named element in the list for that identified PM_QOS parameter
25with the target value. Upon change to this list the new target is recomputed
26and any registered notifiers are called only if the target value is now
27different.
28
29pm_qos_update_requirement(param_id, name, new_target_value):
30Will search the list identified by the param_id for the named list element and
31then update its target value, calling the notification tree if the aggregated
32target is changed. with that name is already registered.
33
34pm_qos_remove_requirement(param_id, name):
35Will search the identified list for the named element and remove it, after
36removal it will update the aggregate target and call the notification tree if
37the target was changed as a result of removing the named requirement.
38
39
40From user mode:
41Only processes can register a pm_qos requirement. To provide for automatic
42cleanup for process the interface requires the process to register its
43parameter requirements in the following way:
44
45To register the default pm_qos target for the specific parameter, the process
46must open one of /dev/[cpu_dma_latency, network_latency, network_throughput]
47
48As long as the device node is held open that process has a registered
49requirement on the parameter. The name of the requirement is "process_<PID>"
50derived from the current->pid from within the open system call.
51
52To change the requested target value the process needs to write a s32 value to
53the open device node. This translates to a pm_qos_update_requirement call.
54
55To remove the user mode request for a target value simply close the device
56node.
57
58
59