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