brintos

brintos / linux-shallow public Read only

0
0
Text · 3.9 KiB · 645d914 Raw
108 lines · plain
1=======================2CPU cooling APIs How To3=======================4 5Written by Amit Daniel Kachhap <amit.kachhap@linaro.org>6 7Updated: 6 Jan 20158 9Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)10 110. Introduction12===============13 14The generic cpu cooling(freq clipping) provides registration/unregistration APIs15to the caller. The binding of the cooling devices to the trip point is left for16the user. The registration APIs returns the cooling device pointer.17 181. cpu cooling APIs19===================20 211.1 cpufreq registration/unregistration APIs22--------------------------------------------23 24    ::25 26	struct thermal_cooling_device27	*cpufreq_cooling_register(struct cpumask *clip_cpus)28 29    This interface function registers the cpufreq cooling device with the name30    "thermal-cpufreq-%x". This api can support multiple instances of cpufreq31    cooling devices.32 33   clip_cpus:34	cpumask of cpus where the frequency constraints will happen.35 36    ::37 38	struct thermal_cooling_device39	*of_cpufreq_cooling_register(struct cpufreq_policy *policy)40 41    This interface function registers the cpufreq cooling device with42    the name "thermal-cpufreq-%x" linking it with a device tree node, in43    order to bind it via the thermal DT code. This api can support multiple44    instances of cpufreq cooling devices.45 46    policy:47	CPUFreq policy.48 49 50    ::51 52	void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)53 54    This interface function unregisters the "thermal-cpufreq-%x" cooling device.55 56    cdev: Cooling device pointer which has to be unregistered.57 582. Power models59===============60 61The power API registration functions provide a simple power model for62CPUs.  The current power is calculated as dynamic power (static power isn't63supported currently).  This power model requires that the operating-points of64the CPUs are registered using the kernel's opp library and the65`cpufreq_frequency_table` is assigned to the `struct device` of the66cpu.  If you are using CONFIG_CPUFREQ_DT then the67`cpufreq_frequency_table` should already be assigned to the cpu68device.69 70The dynamic power consumption of a processor depends on many factors.71For a given processor implementation the primary factors are:72 73- The time the processor spends running, consuming dynamic power, as74  compared to the time in idle states where dynamic consumption is75  negligible.  Herein we refer to this as 'utilisation'.76- The voltage and frequency levels as a result of DVFS.  The DVFS77  level is a dominant factor governing power consumption.78- In running time the 'execution' behaviour (instruction types, memory79  access patterns and so forth) causes, in most cases, a second order80  variation.  In pathological cases this variation can be significant,81  but typically it is of a much lesser impact than the factors above.82 83A high level dynamic power consumption model may then be represented as::84 85	Pdyn = f(run) * Voltage^2 * Frequency * Utilisation86 87f(run) here represents the described execution behaviour and its88result has a units of Watts/Hz/Volt^2 (this often expressed in89mW/MHz/uVolt^2)90 91The detailed behaviour for f(run) could be modelled on-line.  However,92in practice, such an on-line model has dependencies on a number of93implementation specific processor support and characterisation94factors.  Therefore, in initial implementation that contribution is95represented as a constant coefficient.  This is a simplification96consistent with the relative contribution to overall power variation.97 98In this simplified representation our model becomes::99 100	Pdyn = Capacitance * Voltage^2 * Frequency * Utilisation101 102Where `capacitance` is a constant that represents an indicative103running time dynamic power coefficient in fundamental units of104mW/MHz/uVolt^2.  Typical values for mobile CPUs might lie in range105from 100 to 500.  For reference, the approximate values for the SoC in106ARM's Juno Development Platform are 530 for the Cortex-A57 cluster and107140 for the Cortex-A53 cluster.108