1*4882a593Smuzhiyun======================= 2*4882a593SmuzhiyunCPU cooling APIs How To 3*4882a593Smuzhiyun======================= 4*4882a593Smuzhiyun 5*4882a593SmuzhiyunWritten by Amit Daniel Kachhap <amit.kachhap@linaro.org> 6*4882a593Smuzhiyun 7*4882a593SmuzhiyunUpdated: 6 Jan 2015 8*4882a593Smuzhiyun 9*4882a593SmuzhiyunCopyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) 10*4882a593Smuzhiyun 11*4882a593Smuzhiyun0. Introduction 12*4882a593Smuzhiyun=============== 13*4882a593Smuzhiyun 14*4882a593SmuzhiyunThe generic cpu cooling(freq clipping) provides registration/unregistration APIs 15*4882a593Smuzhiyunto the caller. The binding of the cooling devices to the trip point is left for 16*4882a593Smuzhiyunthe user. The registration APIs returns the cooling device pointer. 17*4882a593Smuzhiyun 18*4882a593Smuzhiyun1. cpu cooling APIs 19*4882a593Smuzhiyun=================== 20*4882a593Smuzhiyun 21*4882a593Smuzhiyun1.1 cpufreq registration/unregistration APIs 22*4882a593Smuzhiyun-------------------------------------------- 23*4882a593Smuzhiyun 24*4882a593Smuzhiyun :: 25*4882a593Smuzhiyun 26*4882a593Smuzhiyun struct thermal_cooling_device 27*4882a593Smuzhiyun *cpufreq_cooling_register(struct cpumask *clip_cpus) 28*4882a593Smuzhiyun 29*4882a593Smuzhiyun This interface function registers the cpufreq cooling device with the name 30*4882a593Smuzhiyun "thermal-cpufreq-%x". This api can support multiple instances of cpufreq 31*4882a593Smuzhiyun cooling devices. 32*4882a593Smuzhiyun 33*4882a593Smuzhiyun clip_cpus: 34*4882a593Smuzhiyun cpumask of cpus where the frequency constraints will happen. 35*4882a593Smuzhiyun 36*4882a593Smuzhiyun :: 37*4882a593Smuzhiyun 38*4882a593Smuzhiyun struct thermal_cooling_device 39*4882a593Smuzhiyun *of_cpufreq_cooling_register(struct cpufreq_policy *policy) 40*4882a593Smuzhiyun 41*4882a593Smuzhiyun This interface function registers the cpufreq cooling device with 42*4882a593Smuzhiyun the name "thermal-cpufreq-%x" linking it with a device tree node, in 43*4882a593Smuzhiyun order to bind it via the thermal DT code. This api can support multiple 44*4882a593Smuzhiyun instances of cpufreq cooling devices. 45*4882a593Smuzhiyun 46*4882a593Smuzhiyun policy: 47*4882a593Smuzhiyun CPUFreq policy. 48*4882a593Smuzhiyun 49*4882a593Smuzhiyun 50*4882a593Smuzhiyun :: 51*4882a593Smuzhiyun 52*4882a593Smuzhiyun void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 53*4882a593Smuzhiyun 54*4882a593Smuzhiyun This interface function unregisters the "thermal-cpufreq-%x" cooling device. 55*4882a593Smuzhiyun 56*4882a593Smuzhiyun cdev: Cooling device pointer which has to be unregistered. 57*4882a593Smuzhiyun 58*4882a593Smuzhiyun2. Power models 59*4882a593Smuzhiyun=============== 60*4882a593Smuzhiyun 61*4882a593SmuzhiyunThe power API registration functions provide a simple power model for 62*4882a593SmuzhiyunCPUs. The current power is calculated as dynamic power (static power isn't 63*4882a593Smuzhiyunsupported currently). This power model requires that the operating-points of 64*4882a593Smuzhiyunthe CPUs are registered using the kernel's opp library and the 65*4882a593Smuzhiyun`cpufreq_frequency_table` is assigned to the `struct device` of the 66*4882a593Smuzhiyuncpu. If you are using CONFIG_CPUFREQ_DT then the 67*4882a593Smuzhiyun`cpufreq_frequency_table` should already be assigned to the cpu 68*4882a593Smuzhiyundevice. 69*4882a593Smuzhiyun 70*4882a593SmuzhiyunThe dynamic power consumption of a processor depends on many factors. 71*4882a593SmuzhiyunFor a given processor implementation the primary factors are: 72*4882a593Smuzhiyun 73*4882a593Smuzhiyun- The time the processor spends running, consuming dynamic power, as 74*4882a593Smuzhiyun compared to the time in idle states where dynamic consumption is 75*4882a593Smuzhiyun negligible. Herein we refer to this as 'utilisation'. 76*4882a593Smuzhiyun- The voltage and frequency levels as a result of DVFS. The DVFS 77*4882a593Smuzhiyun level is a dominant factor governing power consumption. 78*4882a593Smuzhiyun- In running time the 'execution' behaviour (instruction types, memory 79*4882a593Smuzhiyun access patterns and so forth) causes, in most cases, a second order 80*4882a593Smuzhiyun variation. In pathological cases this variation can be significant, 81*4882a593Smuzhiyun but typically it is of a much lesser impact than the factors above. 82*4882a593Smuzhiyun 83*4882a593SmuzhiyunA high level dynamic power consumption model may then be represented as:: 84*4882a593Smuzhiyun 85*4882a593Smuzhiyun Pdyn = f(run) * Voltage^2 * Frequency * Utilisation 86*4882a593Smuzhiyun 87*4882a593Smuzhiyunf(run) here represents the described execution behaviour and its 88*4882a593Smuzhiyunresult has a units of Watts/Hz/Volt^2 (this often expressed in 89*4882a593SmuzhiyunmW/MHz/uVolt^2) 90*4882a593Smuzhiyun 91*4882a593SmuzhiyunThe detailed behaviour for f(run) could be modelled on-line. However, 92*4882a593Smuzhiyunin practice, such an on-line model has dependencies on a number of 93*4882a593Smuzhiyunimplementation specific processor support and characterisation 94*4882a593Smuzhiyunfactors. Therefore, in initial implementation that contribution is 95*4882a593Smuzhiyunrepresented as a constant coefficient. This is a simplification 96*4882a593Smuzhiyunconsistent with the relative contribution to overall power variation. 97*4882a593Smuzhiyun 98*4882a593SmuzhiyunIn this simplified representation our model becomes:: 99*4882a593Smuzhiyun 100*4882a593Smuzhiyun Pdyn = Capacitance * Voltage^2 * Frequency * Utilisation 101*4882a593Smuzhiyun 102*4882a593SmuzhiyunWhere `capacitance` is a constant that represents an indicative 103*4882a593Smuzhiyunrunning time dynamic power coefficient in fundamental units of 104*4882a593SmuzhiyunmW/MHz/uVolt^2. Typical values for mobile CPUs might lie in range 105*4882a593Smuzhiyunfrom 100 to 500. For reference, the approximate values for the SoC in 106*4882a593SmuzhiyunARM's Juno Development Platform are 530 for the Cortex-A57 cluster and 107*4882a593Smuzhiyun140 for the Cortex-A53 cluster. 108