1. 27 Jun, 2019 1 commit
  2. 27 Dec, 2017 1 commit
    • Yi Zeng's avatar
      thermal: power_allocator: fix one race condition issue for thermal_instances list · a5de11d6
      Yi Zeng authored
      When invoking allow_maximum_power and traverse tz->thermal_instances,
      we should grab thermal_zone_device->lock to avoid race condition. For
      example, during the system reboot, if the mali GPU device implements
      device shutdown callback and unregister GPU devfreq cooling device,
      the deleted list head may be accessed to cause panic, as the following
      log shows:
      [   33.551070] c3 25 (kworker/3:0) Unable to handle kernel paging request at virtual address dead000000000070
      [   33.566708] c3 25 (kworker/3:0) pgd = ffffffc0ed290000
      [   33.572071] c3 25 (kworker/3:0) [dead000000000070] *pgd=00000001ed292003, *pud=00000001ed292003, *pmd=0000000000000000
      [   33.581515] c3 25 (kworker/3:0) Internal error: Oops: 96000004 [#1] PREEMPT SMP
      [   33.599761] c3 25 (kworker/3:0) CPU: 3 PID: 25 Comm: kworker/3:0 Not tainted 4.4.35+ #912
      [   33.614137] c3 25 (kworker/3:0) Workqueue: events_freezable thermal_zone_device_check
      [   33.620245] c3 25 (kworker/3:0) task: ffffffc0f32e4200 ti: ffffffc0f32f0000 task.ti: ffffffc0f32f0000
      [   33.629466] c3 25 (kworker/3:0) PC is at power_allocator_throttle+0x7c8/0x8a4
      [   33.636609] c3 25 (kworker/3:0) LR is at power_allocator_throttle+0x808/0x8a4
      [   33.643742] c3 25 (kworker/3:0) pc : [<ffffff8008683dd0>] lr : [<ffffff8008683e10>] pstate: 20000145
      [   33.652874] c3 25 (kworker/3:0) sp : ffffffc0f32f3bb0
      [   34.468519] c3 25 (kworker/3:0) Process kworker/3:0 (pid: 25, stack limit = 0xffffffc0f32f0020)
      [   34.477220] c3 25 (kworker/3:0) Stack: (0xffffffc0f32f3bb0 to 0xffffffc0f32f4000)
      [   34.819822] c3 25 (kworker/3:0) Call trace:
      [   34.824021] c3 25 (kworker/3:0) Exception stack(0xffffffc0f32f39c0 to 0xffffffc0f32f3af0)
      [   34.924993] c3 25 (kworker/3:0) [<ffffff8008683dd0>] power_allocator_throttle+0x7c8/0x8a4
      [   34.933184] c3 25 (kworker/3:0) [<ffffff80086807f4>] handle_thermal_trip.part.25+0x70/0x224
      [   34.941545] c3 25 (kworker/3:0) [<ffffff8008680a68>] thermal_zone_device_update+0xc0/0x20c
      [   34.949818] c3 25 (kworker/3:0) [<ffffff8008680bd4>] thermal_zone_device_check+0x20/0x2c
      [   34.957924] c3 25 (kworker/3:0) [<ffffff80080b93a4>] process_one_work+0x168/0x458
      [   34.965414] c3 25 (kworker/3:0) [<ffffff80080ba068>] worker_thread+0x13c/0x4b4
      [   34.972650] c3 25 (kworker/3:0) [<ffffff80080c0a4c>] kthread+0xe8/0xfc
      [   34.979187] c3 25 (kworker/3:0) [<ffffff8008084e90>] ret_from_fork+0x10/0x40
      [   34.986244] c3 25 (kworker/3:0) Code: f9405e73 eb1302bf d102e273 54ffc460 (b9402a61)
      [   34.994339] c3 25 (kworker/3:0) ---[ end trace 32057901e3b7e1db ]---
      Signed-off-by: default avatarYi Zeng <yizeng@asrmicro.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
  3. 08 Aug, 2016 1 commit
    • Michele Di Giorgio's avatar
      thermal: fix race condition when updating cooling device · d0b7306d
      Michele Di Giorgio authored
      When multiple thermal zones are bound to the same cooling device, multiple
      kernel threads may want to update the cooling device state by calling
      thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race
      condition. Consider the following situation with two kernel threads k1 and k2:
      	    Thread k1				Thread k2
                                          ||  call thermal_cdev_update()
                                          ||      ...
                                          ||      set_cur_state(cdev, target);
          call power_actor_set_power()    ||
              ...                         ||
              instance->target = state;   ||
              cdev->updated = false;      ||
                                          ||      cdev->updated = true;
                                          ||      // completes execution
          call thermal_cdev_update()      ||
              // cdev->updated == true    ||
              return;                     ||
      k2 has already looped through the thermal instances looking for the deepest
      cooling device state and is preempted right before setting cdev->updated to
      true. Now, k1 runs, modifies the thermal instance state and sets cdev->updated
      to false. Then, k1 is preempted and k2 continues the execution by setting
      cdev->updated to true, therefore preventing k1 from performing the update.
      Notice that this is not an issue if k2 looks at the instance->target modified by
      k1 "after" it is assigned by k1. In fact, in this case the update will happen
      anyway and k1 can safely return immediately from thermal_cdev_update().
      This may lead to a situation where a thermal governor never updates the cooling
      device. For example, this is the case for the step_wise governor: when calling
      the function thermal_zone_trip_update(), the governor may always get a new state
      equal to the old one (which, however, wasn't notified to the cooling device) and
      will therefore skip the update.
      CC: Zhang Rui <rui.zhang@intel.com>
      CC: Eduardo Valentin <edubezval@gmail.com>
      CC: Peter Feuerer <peter@piie.net>
      Reported-by: default avatarToby Huang <toby.huang@arm.com>
      Signed-off-by: default avatarMichele Di Giorgio <michele.digiorgio@arm.com>
      Reviewed-by: default avatarJavi Merino <javi.merino@arm.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
  4. 20 Apr, 2016 1 commit
  5. 12 Nov, 2015 1 commit
  6. 09 Nov, 2015 1 commit
    • Andrew Morton's avatar
      remove abs64() · 79211c8e
      Andrew Morton authored
      Switch everything to the new and more capable implementation of abs().
      Mainly to give the new abs() a bit of a workout.
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 02 Oct, 2015 1 commit
  8. 20 Sep, 2015 1 commit
  9. 14 Sep, 2015 3 commits
  10. 29 Aug, 2015 1 commit
  11. 14 Aug, 2015 1 commit
  12. 03 Aug, 2015 2 commits
    • Sascha Hauer's avatar
      thermal: consistently use int for temperatures · 17e8351a
      Sascha Hauer authored
      The thermal code uses int, long and unsigned long for temperatures
      in different places.
      Using an unsigned type limits the thermal framework to positive
      temperatures without need. Also several drivers currently will report
      temperatures near UINT_MAX for temperatures below 0°C. This will probably
      immediately shut the machine down due to overtemperature if started below
      'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
      is above the melting point of all known materials.
      Consistently use a plain 'int' for temperatures throughout the thermal code and
      the drivers. This only changes the places in the drivers where the temperature
      is passed around as pointer, when drivers internally use another type this is
      not changed.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Reviewed-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Reviewed-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Reviewed-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Reviewed-by: default avatarPeter Feuerer <peter@piie.net>
      Cc: Punit Agrawal <punit.agrawal@arm.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Cc: linux-pm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Jean Delvare <jdelvare@suse.de>
      Cc: Peter Feuerer <peter@piie.net>
      Cc: Heiko Stuebner <heiko@sntech.de>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: platform-driver-x86@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: lm-sensors@lm-sensors.org
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
    • Javi Merino's avatar
      thermal: power_allocator: trace the real requested power · d5f83109
      Javi Merino authored
      The power allocator governor uses ftrace to output a bunch of internal
      data for debugging and tuning.  Currently, the requested power it
      outputs is the "weighted" requested power, that is, what each cooling
      device has requested multiplied by the cooling device weight.  It is
      more useful to trace the real request, without any weight being
      This commit only affects the data traced, there is no functional change.
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarJavi Merino <javi.merino@arm.com>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
  13. 12 May, 2015 1 commit
    • Javi Merino's avatar
      thermal: power_allocator: round the division when divvying up power · ea54cac9
      Javi Merino authored
      In situations where there is an uneven number of cooling devices, the
      division of power among them can lead to a milliwatt being dropped on
      the floor due to rounding errors.  This doesn't sound like a lot, but
      some devices only grant the lowest cooling device state for their
      maximum power.  So for instance, if the granted_power is the maximum
      power and all devices are getting their maximum power, one would get
      max_power - 1, making it choose cooling device state 1, instead of 0.
      Round the division to make the calculation more accurate.
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarJavi Merino <javi.merino@arm.com>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
  14. 05 May, 2015 2 commits
    • Javi Merino's avatar
      thermal: add trace events to the power allocator governor · 6828a471
      Javi Merino authored
      Add trace events for the power allocator governor and the power actor
      interface of the cpu cooling device.
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarJavi Merino <javi.merino@arm.com>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
    • Javi Merino's avatar
      thermal: introduce the Power Allocator governor · 6b775e87
      Javi Merino authored
      The power allocator governor is a thermal governor that controls system
      and device power allocation to control temperature.  Conceptually, the
      implementation divides the sustainable power of a thermal zone among
      all the heat sources in that zone.
      This governor relies on "power actors", entities that represent heat
      sources.  They can report current and maximum power consumption and
      can set a given maximum power consumption, usually via a cooling
      The governor uses a Proportional Integral Derivative (PID) controller
      driven by the temperature of the thermal zone.  The output of the
      controller is a power budget that is then allocated to each power
      actor that can have bearing on the temperature we are trying to
      control.  It decides how much power to give each cooling device based
      on the performance they are requesting.  The PID controller ensures
      that the total power budget does not exceed the control temperature.
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Signed-off-by: default avatarJavi Merino <javi.merino@arm.com>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>