~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/Documentation/driver-api/thermal/cpu-cooling-api.rst

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.12 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

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

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php