kernel/git/next/linux-next.git/drivers/thermal/fair_share.c, branch master

thermal/governors: Prefix all source files with gov_

2020-05-22T16:48:54+00:00

Bang-bang governor source file is prefixed with gov_. Do the same for other governors for consistency so they're easy to find in the sources. Signed-off-by: Amit Kucheria Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/b9a85d3204712f14e320504948c12712dc0b291b.1589199124.git.amit.kucheria@linaro.org

thermal: step_wise: Appease the kernel-doc deity

2020-01-27T09:24:32+00:00

Replace - with : to appease the kernel-doc gods and fix warnings such as the following when compiled with make W=1: linux-amit.git/drivers/thermal/step_wise.c:187: warning: Function parameter or member 'tz' not described in 'step_wise_throttle' linux-amit.git/drivers/thermal/step_wise.c:187: warning: Function parameter or member 'trip' not described in 'step_wise_throttle' linux.git/drivers/thermal/fair_share.c:79: warning: Function parameter or member 'tz' not described in 'fair_share_throttle' linux.git/drivers/thermal/fair_share.c:79: warning: Function parameter or member 'trip' not described in 'fair_share_throttle' Signed-off-by: Amit Kucheria Reviewed-by: Viresh Kumar Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/5d48ac6f85667a53902092ad5bbfef8cc89a7162.1574242756.git.amit.kucheria@linaro.org

thermal/drivers/core: Use governor table to initialize

2019-06-27T13:22:14+00:00

Now that the governor table is in place and the macro allows to browse the table, declare the governor so the entry is added in the governor table in the init section. The [un]register_thermal_governors function does no longer need to use the exported [un]register thermal governor's specific function which in turn call the [un]register_thermal_governor. The governors are fully self-encapsulated. The cyclic dependency is no longer needed, remove it. Reviewed-by: Amit Kucheria Signed-off-by: Daniel Lezcano Signed-off-by: Zhang Rui

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 167

2019-05-30T18:26:39+00:00

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 of the license this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 83 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Richard Fontana Reviewed-by: Kate Stewart Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.021731668@linutronix.de Signed-off-by: Greg Kroah-Hartman

thermal: fix source code documentation for parameters

2017-06-29T02:46:31+00:00

Some parameters are not documented, or not present at all, in thermal governors code. Signed-off-by: Willy Wolff Signed-off-by: Zhang Rui

thermal: fix race condition when updating cooling device

2016-08-08T02:57:39+00:00

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; || \/ time 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 CC: Eduardo Valentin CC: Peter Feuerer Reported-by: Toby Huang Signed-off-by: Michele Di Giorgio Reviewed-by: Javi Merino Signed-off-by: Zhang Rui

thermal: consistently use int for temperatures

2015-08-03T15:15:50+00:00

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 0°C. '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: Sascha Hauer Acked-by: Geert Uytterhoeven Reviewed-by: Jean Delvare Reviewed-by: Lukasz Majewski Reviewed-by: Darren Hart Reviewed-by: Heiko Stuebner Reviewed-by: Peter Feuerer Cc: Punit Agrawal Cc: Zhang Rui Cc: Eduardo Valentin Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Jean Delvare Cc: Peter Feuerer Cc: Heiko Stuebner Cc: Lukasz Majewski Cc: Stephen Warren Cc: Thierry Reding 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 Cc: Rafael J. Wysocki Cc: Maxime Ripard Cc: Darren Hart Cc: lm-sensors@lm-sensors.org Signed-off-by: Zhang Rui

thermal: fair_share: generalize the weight concept

2015-05-05T04:27:51+00:00

The fair share governor has the concept of weights, which is the influence of each cooling device in a thermal zone. The current implementation forces the weights of all cooling devices in a thermal zone to add up to a 100. This complicates setups, as you need to know in advance how many cooling devices you are going to have. If you bind a new cooling device, you have to modify all the other cooling devices weights, which is error prone. Furthermore, you can't specify a "default" weight for platforms since that default value depends on the number of cooling devices in the platform. This patch generalizes the concept of weight by allowing any number to be a "weight". Weights are now relative to each other. Platforms that don't specify weights get the same default value for all their cooling devices, so all their cdevs are considered to be equally influential. It's important to note that previous users of the weights don't need to alter the code: percentages continue to work as they used to. This patch just removes the constraint of all the weights in a thermal zone having to add up to a 100. If they do, you get the same behavior as before. If they don't, fair share now works for that platform. Cc: Zhang Rui Cc: Eduardo Valentin Cc: Durgadoss R Acked-by: Durgadoss R Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin

thermal: fair_share: fix typo

2015-05-05T04:27:51+00:00

s/asscciated/associated/ Cc: Zhang Rui Cc: Eduardo Valentin Cc: Durgadoss R Reviewed-by: Durgadoss R Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin

thermal: fair_share: use the weight from the thermal instance

2015-05-05T04:27:51+00:00

The fair share governor is not usable with thermal zones that use the bind op and don't populate thermal_zone_parameters, the majority of them. Now that the weight is in the thermal instance, we can use that in the fair share governor to allow every thermal zone to trivially use this governor. Furthermore, this simplifies the code. Cc: Zhang Rui Cc: Eduardo Valentin Cc: Durgadoss R Reviewed-by: Durgadoss R Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin