1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
CPU cooling APIs How To
===================================
Written by Amit Daniel Kachhap <amit.kachhap@linaro.org>
Updated: 6 Jan 2015
Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
0. Introduction
The generic cpu cooling(freq clipping) provides registration/unregistration APIs
to the caller. The binding of the cooling devices to the trip point is left for
the user. The registration APIs returns the cooling device pointer.
1. cpu cooling APIs
1.1 cpufreq registration/unregistration APIs
1.1.1 struct thermal_cooling_device *cpufreq_cooling_register(
struct cpumask *clip_cpus)
This interface function registers the cpufreq cooling device with the name
"thermal-cpufreq-%x". This api can support multiple instances of cpufreq
cooling devices.
clip_cpus: cpumask of cpus where the frequency constraints will happen.
1.1.2 struct thermal_cooling_device *of_cpufreq_cooling_register(
struct cpufreq_policy *policy)
This interface function registers the cpufreq cooling device with
the name "thermal-cpufreq-%x" linking it with a device tree node, in
order to bind it via the thermal DT code. This api can support multiple
instances of cpufreq cooling devices.
policy: CPUFreq policy.
1.1.3 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
This interface function unregisters the "thermal-cpufreq-%x" cooling device.
cdev: Cooling device pointer which has to be unregistered.
2. Power models
The power API registration functions provide a simple power model for
CPUs. The current power is calculated as dynamic + (optionally)
static power. This power model requires that the operating-points of
the CPUs are registered using the kernel's opp library and the
`cpufreq_frequency_table` is assigned to the `struct device` of the
cpu. If you are using CONFIG_CPUFREQ_DT then the
`cpufreq_frequency_table` should already be assigned to the cpu
device.
2.1 Dynamic power
The dynamic power consumption of a processor depends on many factors.
For a given processor implementation the primary factors are:
- The time the processor spends running, consuming dynamic power, as
compared to the time in idle states where dynamic consumption is
negligible. Herein we refer to this as 'utilisation'.
- The voltage and frequency levels as a result of DVFS. The DVFS
level is a dominant factor governing power consumption.
- In running time the 'execution' behaviour (instruction types, memory
access patterns and so forth) causes, in most cases, a second order
variation. In pathological cases this variation can be significant,
but typically it is of a much lesser impact than the factors above.
A high level dynamic power consumption model may then be represented as:
Pdyn = f(run) * Voltage^2 * Frequency * Utilisation
f(run) here represents the described execution behaviour and its
result has a units of Watts/Hz/Volt^2 (this often expressed in
mW/MHz/uVolt^2)
The detailed behaviour for f(run) could be modelled on-line. However,
in practice, such an on-line model has dependencies on a number of
implementation specific processor support and characterisation
factors. Therefore, in initial implementation that contribution is
represented as a constant coefficient. This is a simplification
consistent with the relative contribution to overall power variation.
In this simplified representation our model becomes:
Pdyn = Capacitance * Voltage^2 * Frequency * Utilisation
Where `capacitance` is a constant that represents an indicative
running time dynamic power coefficient in fundamental units of
mW/MHz/uVolt^2. Typical values for mobile CPUs might lie in range
from 100 to 500. For reference, the approximate values for the SoC in
ARM's Juno Development Platform are 530 for the Cortex-A57 cluster and
140 for the Cortex-A53 cluster.
2.2 Static power
Static leakage power consumption depends on a number of factors. For a
given circuit implementation the primary factors are:
- Time the circuit spends in each 'power state'
- Temperature
- Operating voltage
- Process grade
The time the circuit spends in each 'power state' for a given
evaluation period at first order means OFF or ON. However,
'retention' states can also be supported that reduce power during
inactive periods without loss of context.
Note: The visibility of state entries to the OS can vary, according to
platform specifics, and this can then impact the accuracy of a model
based on OS state information alone. It might be possible in some
cases to extract more accurate information from system resources.
The temperature, operating voltage and process 'grade' (slow to fast)
of the circuit are all significant factors in static leakage power
consumption. All of these have complex relationships to static power.
Circuit implementation specific factors include the chosen silicon
process as well as the type, number and size of transistors in both
the logic gates and any RAM elements included.
The static power consumption modelling must take into account the
power managed regions that are implemented. Taking the example of an
ARM processor cluster, the modelling would take into account whether
each CPU can be powered OFF separately or if only a single power
region is implemented for the complete cluster.
In one view, there are others, a static power consumption model can
then start from a set of reference values for each power managed
region (e.g. CPU, Cluster/L2) in each state (e.g. ON, OFF) at an
arbitrary process grade, voltage and temperature point. These values
are then scaled for all of the following: the time in each state, the
process grade, the current temperature and the operating voltage.
However, since both implementation specific and complex relationships
dominate the estimate, the appropriate interface to the model from the
cpu cooling device is to provide a function callback that calculates
the static power in this platform. When registering the cpu cooling
device pass a function pointer that follows the `get_static_t`
prototype:
int plat_get_static(cpumask_t *cpumask, int interval,
unsigned long voltage, u32 &power);
`cpumask` is the cpumask of the cpus involved in the calculation.
`voltage` is the voltage at which they are operating. The function
should calculate the average static power for the last `interval`
milliseconds. It returns 0 on success, -E* on error. If it
succeeds, it should store the static power in `power`. Reading the
temperature of the cpus described by `cpumask` is left for
plat_get_static() to do as the platform knows best which thermal
sensor is closest to the cpu.
If `plat_static_func` is NULL, static power is considered to be
negligible for this platform and only dynamic power is considered.
The platform specific callback can then use any combination of tables
and/or equations to permute the estimated value. Process grade
information is not passed to the model since access to such data, from
on-chip measurement capability or manufacture time data, is platform
specific.
Note: the significance of static power for CPUs in comparison to
dynamic power is highly dependent on implementation. Given the
potential complexity in implementation, the importance and accuracy of
its inclusion when using cpu cooling devices should be assessed on a
case by case basis.
|
