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 cpufreq_policy *policy) 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 policy: CPUFreq policy. 37 381.1.3 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 39 40 This interface function unregisters the "thermal-cpufreq-%x" cooling device. 41 42 cdev: Cooling device pointer which has to be unregistered. 43 442. Power models 45 46The power API registration functions provide a simple power model for 47CPUs. The current power is calculated as dynamic power (static power isn't 48supported currently). This power model requires that the operating-points of 49the CPUs are registered using the kernel's opp library and the 50`cpufreq_frequency_table` is assigned to the `struct device` of the 51cpu. If you are using CONFIG_CPUFREQ_DT then the 52`cpufreq_frequency_table` should already be assigned to the cpu 53device. 54 55The dynamic power consumption of a processor depends on many factors. 56For a given processor implementation the primary factors are: 57 58- The time the processor spends running, consuming dynamic power, as 59 compared to the time in idle states where dynamic consumption is 60 negligible. Herein we refer to this as 'utilisation'. 61- The voltage and frequency levels as a result of DVFS. The DVFS 62 level is a dominant factor governing power consumption. 63- In running time the 'execution' behaviour (instruction types, memory 64 access patterns and so forth) causes, in most cases, a second order 65 variation. In pathological cases this variation can be significant, 66 but typically it is of a much lesser impact than the factors above. 67 68A high level dynamic power consumption model may then be represented as: 69 70Pdyn = f(run) * Voltage^2 * Frequency * Utilisation 71 72f(run) here represents the described execution behaviour and its 73result has a units of Watts/Hz/Volt^2 (this often expressed in 74mW/MHz/uVolt^2) 75 76The detailed behaviour for f(run) could be modelled on-line. However, 77in practice, such an on-line model has dependencies on a number of 78implementation specific processor support and characterisation 79factors. Therefore, in initial implementation that contribution is 80represented as a constant coefficient. This is a simplification 81consistent with the relative contribution to overall power variation. 82 83In this simplified representation our model becomes: 84 85Pdyn = Capacitance * Voltage^2 * Frequency * Utilisation 86 87Where `capacitance` is a constant that represents an indicative 88running time dynamic power coefficient in fundamental units of 89mW/MHz/uVolt^2. Typical values for mobile CPUs might lie in range 90from 100 to 500. For reference, the approximate values for the SoC in 91ARM's Juno Development Platform are 530 for the Cortex-A57 cluster and 92140 for the Cortex-A53 cluster. 93