1. 16 Sep, 2019 3 commits
    • Martin Kepplinger's avatar
      thermal/drivers/cpu_cooling: workaround cpuidle time calculation error · 6e8fe3aa
      Martin Kepplinger authored
      For cpuidle_cooling_runtime() returning 0, no idle-injection is
      applied. For an idle injection percentage of 0, this makes sense. But
      this happends for the idle injection percentage of 100 too, which is
      wrong.
      
      The documented calculation: ((idle_cycle * 100) / state) - idle_cycle
      results 0 for state being 100. For "state" from 0 to 99, the thermal
      driver throttles accordingly and keeps the CPUs cool. When switching
      to 100, it stops cooling, we see a jump up in temperature and the CPU
      heats up until it shuts down.
      
      Work around this problem by keeping the "state" at 99 for calculations,
      never reaching 100. The user interface still reaches 100, but there
      is no formal connection to actual data and the UI. It's just a unified
      range that can be implemented in various ways.
      6e8fe3aa
    • Daniel Lezcano's avatar
      thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver · 01907da6
      Daniel Lezcano authored
      The cpu idle cooling driver performs synchronized idle injection across all
      cpus belonging to the same cluster and offers a new method to cool down a SoC.
      
      Each cluster has its own idle cooling device, each core has its own idle
      injection thread, each idle injection thread uses play_idle to enter idle.  In
      order to reach the deepest idle state, each cooling device has the idle
      injection threads synchronized together.
      
      It has some similarity with the intel power clamp driver but it is actually
      designed to work on the ARM architecture via the DT with a mathematical proof
      with the power model which comes with the Documentation.
      
      The idle injection cycle is fixed while the running cycle is variable. That
      allows to have control on the device reactivity for the user experience. At
      the mitigation point the idle threads are unparked, they play idle the
      specified amount of time and they schedule themselves. The last thread sets
      the next idle injection deadline and when the timer expires it wakes up all
      the threads which in turn play idle again. Meanwhile the running cycle is
      changed by set_cur_state.  When the mitigation ends, the threads are parked.
      The algorithm is self adaptive, so there is no need to handle hotplugging.
      
      If we take an example of the balanced point, we can use the DT for the hi6220.
      
      The sustainable power for the SoC is 3326mW to mitigate at 75°C. Eight cores
      running at full blast at the maximum OPP consumes 5280mW. The first value is
      given in the DT, the second is calculated from the OPP with the formula:
      
         Pdyn = Cdyn x Voltage^2 x Frequency
      
      As the SoC vendors don't want to share the static leakage values, we assume
      it is zero, so the Prun = Pdyn + Pstatic = Pdyn + 0 = Pdyn.
      
      In order to reduce the power to 3326mW, we have to apply a ratio to the
      running time.
      
      ratio = (Prun - Ptarget) / Ptarget = (5280 - 3326) / 3326 = 0,5874
      
      We know the idle cycle which is fixed, let's assume 10ms. However from this
      duration we have to substract the wake up latency for the cluster idle state.
      In our case, it is 1.5ms. So for a 10ms latency for idle, we are really idle
      8.5ms.
      
      As we know the idle duration and the ratio, we can compute the running cycle.
      
         running_cycle = 8.5 / 0.5874 = 14.47ms
      
      So for 8.5ms of idle, we have 14.47ms of running cycle, and that brings the
      SoC to the balanced trip point of 75°C.
      
      The driver has been tested on the hi6220 and it appears the temperature
      stabilizes at 75°C with an idle injection time of 10ms (8.5ms real) and
      running cycle of 14ms as expected by the theory above.
      Signed-off-by: default avatarKevin Wangtao <kevin.wangtao@linaro.org>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      01907da6
    • Daniel Lezcano's avatar
      thermal/drivers/Kconfig: Convert the CPU cooling device to a choice · a60e6a57
      Daniel Lezcano authored
      The next changes will add new way to cool down a CPU. In order to
      sanitize and make the overall cpu cooling code consistent and robust
      we must prevent the cpu cooling devices to co-exists with the same
      purpose at the same time in the kernel.
      
      Make the CPU cooling device a choice in the Kconfig, so only one CPU
      cooling strategy can be chosen.
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      a60e6a57
  2. 23 Jul, 2019 1 commit
  3. 11 Jul, 2019 1 commit
  4. 09 Jul, 2019 1 commit
  5. 27 Jun, 2019 2 commits
  6. 25 Jun, 2019 1 commit
  7. 21 Jun, 2019 1 commit
    • Greg Kroah-Hartman's avatar
      thermal: bcm2835: no need to check return value of debugfs_create functions · a6cd400a
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Ray Jui <rjui@broadcom.com>
      Cc: Scott Branden <sbranden@broadcom.com>
      Cc: bcm-kernel-feedback-list@broadcom.com
      Cc: linux-pm@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a6cd400a
  8. 19 Jun, 2019 1 commit
  9. 18 Jun, 2019 3 commits
  10. 05 Jun, 2019 9 commits
  11. 30 May, 2019 6 commits
  12. 29 May, 2019 1 commit
  13. 24 May, 2019 5 commits
  14. 23 May, 2019 2 commits
  15. 21 May, 2019 2 commits
  16. 14 May, 2019 1 commit