summaryrefslogtreecommitdiff
path: root/drivers/thermal
AgeCommit message (Collapse)Author
2017-12-25thermal/drivers/hisi: Fix multiple alarm interrupts firingDaniel Lezcano
commit db2b0332608c8e648ea1e44727d36ad37cdb56cb upstream. The DT specifies a threshold of 65000, we setup the register with a value in the temperature resolution for the controller, 64656. When we reach 64656, the interrupt fires, the interrupt is disabled. Then the irq thread runs and calls thermal_zone_device_update() which will call in turn hisi_thermal_get_temp(). The function will look if the temperature decreased, assuming it was more than 65000, but that is not the case because the current temperature is 64656 (because of the rounding when setting the threshold). This condition being true, we re-enable the interrupt which fires immediately after exiting the irq thread. That happens again and again until the temperature goes to more than 65000. Potentially, there is here an interrupt storm if the temperature stabilizes at this temperature. A very unlikely case but possible. In any case, it does not make sense to handle dozens of alarm interrupt for nothing. Fix this by rounding the threshold value to the controller resolution so the check against the threshold is consistent with the one set in the controller. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Leo Yan <leo.yan@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-25thermal/drivers/hisi: Simplify the temperature/step computationDaniel Lezcano
commit 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 upstream. The step and the base temperature are fixed values, we can simplify the computation by converting the base temperature to milli celsius and use a pre-computed step value. That saves us a lot of mult + div for nothing at runtime. Take also the opportunity to change the function names to be consistent with the rest of the code. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Leo Yan <leo.yan@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-25thermal/drivers/hisi: Fix kernel panic on alarm interruptDaniel Lezcano
commit 2cb4de785c40d4a2132cfc13e63828f5a28c3351 upstream. The threaded interrupt for the alarm interrupt is requested before the temperature controller is setup. This one can fire an interrupt immediately leading to a kernel panic as the sensor data is not initialized. In order to prevent that, move the threaded irq after the Tsensor is setup. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Leo Yan <leo.yan@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-25thermal/drivers/hisi: Fix missing interrupt enablementDaniel Lezcano
commit c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 upstream. The interrupt for the temperature threshold is not enabled at the end of the probe function, enable it after the setup is complete. On the other side, the irq_enabled is not correctly set as we are checking if the interrupt is masked where 'yes' means irq_enabled=false. irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED, &data->irq_enabled); As we are always enabling the interrupt, it is pointless to check if the interrupt is masked or not, just set irq_enabled to 'true'. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Leo Yan <leo.yan@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-25thermal: hisilicon: Handle return value of clk_prepare_enableArvind Yadav
commit 919054fdfc8adf58c5512fe9872eb53ea0f5525d upstream. clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-20thermal/drivers/step_wise: Fix temperature regulation misbehaviorDaniel Lezcano
[ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ] There is a particular situation when the cooling device is cpufreq and the heat dissipation is not efficient enough where the temperature increases little by little until reaching the critical threshold and leading to a SoC reset. The behavior is reproducible on a hikey6220 with bad heat dissipation (eg. stacked with other boards). Running a simple C program doing while(1); for each CPU of the SoC makes the temperature to reach the passive regulation trip point and ends up to the maximum allowed temperature followed by a reset. This issue has been also reported by running the libhugetlbfs test suite. What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz while the temperature continues to grow. It appears the step wise governor calls get_target_state() the first time with the throttle set to true and the trend to 'raising'. The code selects logically the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so good. The temperature decreases immediately but still stays greater than the trip point, then get_target_state() is called again, this time with the throttle set to true *and* the trend to 'dropping'. From there the algorithm assumes we have to step down the state and the cpu frequency jumps back to 1.2GHz. But the temperature is still higher than the trip point, so get_target_state() is called with throttle=1 and trend='raising' again, we jump to 900MHz, then get_target_state() is called with throttle=1 and trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not stabilizes and continues to increase. [ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 237.922690] thermal cooling_device0: cur_state=0 [ 237.922701] thermal cooling_device0: old_target=0, target=1 [ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 238.026694] thermal cooling_device0: cur_state=1 [ 238.026707] thermal cooling_device0: old_target=1, target=0 [ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 238.134679] thermal cooling_device0: cur_state=0 [ 238.134690] thermal cooling_device0: old_target=0, target=1 In this situation the temperature continues to increase while the trend is oscillating between 'dropping' and 'raising'. We need to keep the current state untouched if the throttle is set, so the temperature can decrease or a higher state could be selected, thus preventing this oscillation. Keeping the next_target untouched when 'throttle' is true at 'dropping' time fixes the issue. The following traces show the governor does not change the next state if trend==2 (dropping) and throttle==1. [ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2306.128021] thermal cooling_device0: cur_state=0 [ 2306.128031] thermal cooling_device0: old_target=0, target=1 [ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1 [ 2306.232030] thermal cooling_device0: cur_state=1 [ 2306.232042] thermal cooling_device0: old_target=1, target=1 [ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1 [ 2306.336021] thermal cooling_device0: cur_state=1 [ 2306.336034] thermal cooling_device0: old_target=1, target=1 [ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2306.440022] thermal cooling_device0: cur_state=1 [ 2306.440034] thermal cooling_device0: old_target=1, target=0 [ ... ] After a while, if the temperature continues to increase, the next state becomes 2 which is 720MHz on the hikey. That results in the temperature stabilizing around the trip point. [ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0 [ 2455.832019] thermal cooling_device0: cur_state=1 [ 2455.832032] thermal cooling_device0: old_target=1, target=1 [ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2455.936027] thermal cooling_device0: cur_state=1 [ 2455.936040] thermal cooling_device0: old_target=1, target=1 [ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1 [ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0 [ 2456.044023] thermal cooling_device0: cur_state=1 [ 2456.044036] thermal cooling_device0: old_target=1, target=1 [ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1 [ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1 [ 2456.148042] thermal cooling_device0: cur_state=1 [ 2456.148055] thermal cooling_device0: old_target=1, target=2 [ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1 [ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0 [ 2456.252058] thermal cooling_device0: cur_state=2 [ 2456.252075] thermal cooling_device0: old_target=2, target=1 IOW, this change is needed to keep the state for a cooling device if the temperature trend is oscillating while the temperature increases slightly. Without this change, the situation above leads to a catastrophic crash by a hardware reset on hikey. This issue has been reported to happen on an OMAP dra7xx also. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Keerthy <j-keerthy@ti.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Leo Yan <leo.yan@linaro.org> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-27thermal: cpu_cooling: Avoid accessing potentially freed structuresViresh Kumar
commit 289d72afddf83440117c35d864bf0c6309c1d011 upstream. After the lock is dropped, it is possible that the cpufreq_dev gets freed before we call get_level() and that can cause kernel to crash. Drop the lock after we are done using the structure. Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-27thermal: max77620: fix device-node reference imbalanceJohan Hovold
commit c592fafbdbb6b1279b76a54722d1465ca77e5bde upstream. The thermal child device reuses the parent MFD-device device-tree node when registering a thermal zone, but did not take a reference to the node. This leads to a reference imbalance, and potential use-after-free, when the node reference is dropped by the platform-bus device destructor (once for the child and later again for the parent). Fix this by dropping any reference already held to a device-tree node and getting a reference to the parent's node which will be balanced on reprobe or on platform-device release, whichever comes first. Note that simply clearing the of_node pointer on probe errors and on driver unbind would not allow the use of device-managed resources as specifically thermal_zone_of_sensor_unregister() claims that a valid device-tree node pointer is needed during deregistration (even if it currently does not seem to use it). Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting junction temp") Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-09thermal: hwmon: Properly report critical temperature in sysfsKrzysztof Kozlowski
commit f37fabb8643eaf8e3b613333a72f683770c85eca upstream. In the critical sysfs entry the thermal hwmon was returning wrong temperature to the user-space. It was reporting the temperature of the first trip point instead of the temperature of critical trip point. For example: /sys/class/hwmon/hwmon0/temp1_crit:50000 /sys/class/thermal/thermal_zone0/trip_point_0_temp:50000 /sys/class/thermal/thermal_zone0/trip_point_0_type:active /sys/class/thermal/thermal_zone0/trip_point_3_temp:120000 /sys/class/thermal/thermal_zone0/trip_point_3_type:critical Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver have been registering a sysfs entry if get_crit_temp() callback was provided. However when accessed, it was calling get_trip_temp() instead of the get_crit_temp(). Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-21thermal/powerclamp: add back module device tableJacob Pan
Commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 replaced module cpu id table with a cpu feature check, which is logically correct. But we need the module device table to allow module auto loading. Cc: stable@vger.kernel.org # 4.8 Fixes:3105f234 thermal/powerclamp: correct cpu support check Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-10-20thermal/powerclamp: correct cpu support checkEric Ernst
Initial logic for checking CPU match resulted in OR of CPU features rather than the intended AND. Updated to use boot_cpu_has macro rather than x86_match_cpu. In addition, MWAIT is the only required CPU feature for idle injection to work. Drop other feature requirements since they are only needed for optimal efficiency. CC: stable@vger.kernel.org #v4.7 Signed-off-by: Eric Ernst <eric.ernst@linux.intel.com> Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-10-20thermal: intel_pch_thermal: Enable Haswell PCHSrinivas Pandruvada
Added missing support for Haswell PCH thermal sensor. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-10-20thermal: intel_pch_thermal: Add an ACPI passive tripSrinivas Pandruvada
On the platforms which has an ACPI companion device associated with PCH thermal device, read passive trip temperature via ACPI _PSV control method. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-10-12Merge branch 'next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal managament updates from Zhang Rui: - Enhance thermal "userspace" governor to export the reason when a thermal event is triggered and delivered to user space. From Srinivas Pandruvada - Introduce a single TSENS thermal driver for the different versions of the TSENS IP that exist, on different qcom msm/apq SoCs'. Support for msm8916, msm8960, msm8974 and msm8996 families is also added. From Rajendra Nayak - Introduce hardware-tracked trip points support to the device tree thermal sensor framework. The framework supports an arbitrary number of trip points. Whenever the current temperature is changed, the trip points immediately below and above the current temperature are found, driver callback is invoked to program the hardware to get notified when either of the two trip points are triggered. Hardware-tracked trip points support for rockchip thermal driver is also added at the same time. From Sascha Hauer, Caesar Wang - Introduce a new thermal driver, which enables TMU (Thermal Monitor Unit) on QorIQ platform. From Jia Hongtao - Introduce a new thermal driver for Maxim MAX77620. From Laxman Dewangan - Introduce a new thermal driver for Intel platforms using WhiskeyCove PMIC. From Bin Gao - Add mt2701 chip support to MTK thermal driver. From Dawei Chien - Enhance Tegra thermal driver to enable soctherm node and set "critical", "hot" trips, for Tegra124, Tegra132, Tegra210. From Wei Ni - Add resume support for tango thermal driver. From Marc Gonzalez - several small fixes and improvements for rockchip, qcom, imx, rcar, mtk thermal drivers and thermal core code. From Caesar Wang, Keerthy, Rocky Hao, Wei Yongjun, Peter Robinson, Bui Duc Phuc, Axel Lin, Hugh Kang * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (48 commits) thermal: int3403: Process trip change notification thermal: int340x: New Interface to read trip and notify thermal: user_space gov: Add additional information in uevent thermal: Enhance thermal_zone_device_update for events arm64: tegra: set hot trips for Tegra210 arm64: tegra: set critical trips for Tegra210 arm64: tegra: add soctherm node for Tegra210 arm64: tegra: set hot trips for Tegra132 arm64: tegra: set critical trips for Tegra132 arm64: tegra: use tegra132-soctherm for Tegra132 arm: tegra: set hot trips for Tegra124 arm: tegra: set critical trips for Tegra124 thermal: tegra: add hw-throttle for Tegra132 thermal: tegra: add hw-throttle function of: Add bindings of hw throttle for Tegra soctherm thermal: mtk_thermal: Check return value of devm_thermal_zone_of_sensor_register thermal: Add Mediatek thermal driver for mt2701. dt-bindings: thermal: Add binding document for Mediatek thermal controller thermal: max77620: Add thermal driver for reporting junction temp thermal: max77620: Add DT binding doc for thermal driver ...
2016-09-27thermal: int3403: Process trip change notificationSrinivas Pandruvada
When ACPI sends notification for trip point change re-read trips and notify thermal core, so that this can be passed to user space thermal controller. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: int340x: New Interface to read trip and notifySrinivas Pandruvada
Separated the code for reading trip points from int340x_thermal_zone_add to a standalone function int340x_thermal_read_trips. This standlone interface to read is exported so that int340x drivers can re-read trips on ACPI notification for trip point change. Also the appropriate notification events are sent by int340x driver based on the acpi event using int340x_thermal_zone_device_update(). Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: user_space gov: Add additional information in ueventSrinivas Pandruvada
Add additional properties: NAME= Thermal zone type TEMP= Temperature sample value TRIP= Violated trip index EVENT= The notification event (new temperature sample, trip violation trip changed) This is the additional information to what kobject_uevent already provides. So it will not impact existing user spaces. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: Enhance thermal_zone_device_update for eventsSrinivas Pandruvada
Added one additional parameter to thermal_zone_device_update() to provide caller with an optional capability to specify reason. Currently this event is used by user space governor to trigger different processing based on event code. Also it saves an additional call to read temperature when the event is received. The following events are cuurently defined: - Unspecified event - New temperature sample - Trip point violated - Trip point changed - thermal device up and down - thermal device power capability changed Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27Merge branches 'thermal-soc', 'thermal-core', 'thermal-intel' and ↵Zhang Rui
'thermal-tegra-hw-throttle' into next
2016-09-27thermal: tegra: add hw-throttle for Tegra132Wei Ni
Tegra132 use CCROC throttle registers to configure pulse skiper, set these registers to enable throttle function for Tegra132. Signed-off-by: Wei Ni <wni@nvidia.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: tegra: add hw-throttle functionWei Ni
Tegra soctherm support HW throttle, when the soctherm snesors' temperature is above the throttle trip point, it will trigger pulse skiper to tune clocks accroding to the throttle depth. Add this function for Tegra124 and Tegra210. Since Tegra132 use different registers to configure pulse skiper, will support it in next patch. Signed-off-by: Wei Ni <wni@nvidia.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: mtk_thermal: Check return value of devm_thermal_zone_of_sensor_registerAxel Lin
devm_thermal_zone_of_sensor_register can fail, so check it's return value. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: Add Mediatek thermal driver for mt2701.dawei.chien@mediatek.com
This patch adds support for mt2701 chip to mtk_thermal, and integrate both mt8173 and mt2701 on the same driver. MT8173 has four banks and five sensors, and MT2701 has only one bank and three sensors. Signed-off-by: Dawei Chien <dawei.chien@mediatek.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: max77620: Add thermal driver for reporting junction tempLaxman Dewangan
Maxim Semiconductor Max77620 supports alarm interrupts when its die temperature crosses 120C and 140C. These threshold temperatures are not configurable. Add thermal driver to register PMIC die temperature as thermal zone sensor and capture the die temperature warning interrupts to notifying the client. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: tango: add resume supportMarc Gonzalez
When this platform is suspended, firmware powers the entire SoC down, except a few hardware blocks waiting for wakeup events. There is no context to save for this particular block. Therefore, there is nothing useful for the driver to do on suspend; so we define a NULL suspend hook. On resume, the driver initializes the block exactly as is done in the probe callback. Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27devfreq_cooling: no need to check state with negative numberShawn Lin
We could see that state is defined as unsigned type, so it should never be less than zero. Let' remove this check. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: rcar_thermal: don't call thermal_zone_device_unregister when ↵Bui Duc Phuc
USE_OF_THERMAL devm_thermal_zone_of_sensor_register() case doesn't need to call thermal_zone_device_unregister(). Otherwise, rcar-thermal can't register thermal zone again after rebind. This patch fixes it. Signed-off-by: Bui Duc Phuc <bd-phuc@jinso.co.jp> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27Thermal: of thermal: typo fixZhang Rui
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: imx: depend on imx SoC archPeter Robinson
Not much use unless the SoC is selected so depend on the ARCH_MXC and COMPILE_TEST like all the other thermal drivers. v2: drop extraneous OF Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: tsens: Fix return value check in init_common()Wei Yongjun
In case of error, the function of_iomap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. And the function devm_regmap_init_mmio() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com> Acked-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: rockchip: optimize sensor auto accessing periodRocky Hao
In less than 10 ms, the temperature of soc will arise 10 degree. 250 ms is too big for soc tempeture control. Setting 2.5 ms will speed up temperature accessing speed but introduce no more cpu's computing overhead. We set AUTO_PERIOD_TIME and TSADCV3_AUTO_PERIOD_HT_TIME the same value, because normal temperature update speed is also our consern in IPA. Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-pm@vger.kernel.org Tested-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: rockchip: enhance the tsadc's bandgap feature for rk3399Rocky Hao
Due to the voltage ripple, the sensing data of the tsadc is not accurate. And in this patch, the bandgap feature is enhanced to remove the voltage ripple, and then the tsadc can sense the temperature more precisely. Obsolete codes are removed as well. Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-pm@vger.kernel.org Tested-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: tsens-8916: mark PM functions __maybe_unusedArnd Bergmann
The newly added tsens-8916 driver produces warnings when CONFIG_PM is disabled: drivers/thermal/qcom/tsens.c:53:12: error: 'tsens_resume' defined but not used [-Werror=unused-function] static int tsens_resume(struct device *dev) ^~~~~~~~~~~~ drivers/thermal/qcom/tsens.c:43:12: error: 'tsens_suspend' defined but not used [-Werror=unused-function] static int tsens_suspend(struct device *dev) ^~~~~~~~~~~~~ This marks both functions __maybe_unused to let the compiler know that they might be used in other configurations, without adding ugly #ifdef logic. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qoriq: Add thermal management supportJia Hongtao
This driver add thermal management support by enabling TMU (Thermal Monitoring Unit) on QorIQ platform. It's based on thermal of framework: - Trip points defined in device tree. - Cpufreq as cooling device registered in qoriq cpufreq driver. Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: rcar-thermal: enable hwmon when thermal_zone_of_sensor_register is usedKuninori Morimoto
rcar-thermal is supporting both thermal_zone_of_sensor_register() and thermal_zone_device_register(). But thermal_zone_of_sensor_register() doesn't enable hwmon as default. This patch enables it to keep compatibility Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: of-thermal: Fix setting of set_emul_temp hookKeerthy
Currently thermal zone set_emul_temp is set unconditionally with of_thermal_set_emul_temp function. Set this only if the set_emul_temp hook is provided for thermal_zone_of_device_ops. This fixes emul_temp failures on platforms for which set_emul_temp hook is not populated. Fixes: "184a4bf623f (thermal: of: Extend current of-thermal.c code to allow setting emulated temp)" Suggested-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Conflicts: drivers/thermal/of-thermal.c Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: rockchip: fixes the exception interruptsCaesar Wang
The hardware-tracked trips will set the alarm interrupt value for registers. Then when the thermal zone has no trips to be set, That make the thermal trips callback a over range value. The root cause is the rk_tsadcv2_temp_to_code() function to handle the invalid temperature range is indeed incorrect, let's fix it on now. Otherwise, the thermal alarm interrupt will be triggered all the time on some SoCs. Fox example: localhost tmp # grep thermal /proc/interrupts; sleep 5; grep thermal /proc/interrupts 23: 994830 .. GICv3 129 Level rockchip_thermal 23: 1003423 .. GICv3 129 Level rockchip_thermal Reported-by: Rocky Hao <rocky.hao@rock-chips.com> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-pm@vger.kernel.org Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: rockchip: fixes the period time for tsadcCaesar Wang
We should increase the period cycles to save power since the rk3399 has the high frequency for tsadc clock. Fixes commit b0d70338bca22cb14 ("thermal: rockchip: Support the RK3399 SoCs in thermal driver") Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-pm@vger.kernel.org Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: rockchip: add the set_trips functionCaesar Wang
Whenever the current temperature is updated, the trip points immediately below and above the current temperature are found. A sensor driver callback `set_trips' is then called with the temperatures. Lastly, The sensor will trigger the hardware high temperature interrupts to increase the sampleing rate and throttle frequency to limit the temperature rising When performing passive cooling. Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: linux-pm@vger.kernel.org Tested-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: bang-bang governor: act on lower trip boundarySascha Hauer
With interrupt driven thermal zones we pass the lower and upper temperature on which shall be acted, so in the governor we have to act on the exact lower temperature to be consistent. Otherwise an interrupt maybe generated on the exact lower temperature, but the bang bang governor does not react since The polling driven zones have to be one step cooler before the governor reacts. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: linux-pm@vger.kernel.org Acked-by: Peter Feuerer <peter@piie.net> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: streamline get_trend callbacksSascha Hauer
The .get_trend callback in struct thermal_zone_device_ops has the prototype: int (*get_trend) (struct thermal_zone_device *, int, enum thermal_trend *); whereas the .get_trend callback in struct thermal_zone_of_device_ops has: int (*get_trend)(void *, long *); Streamline both prototypes and add the trip argument to the OF callback aswell and use enum thermal_trend * instead of an integer pointer. While the OF prototype may be the better one, this should be decided at framework level and not on OF level. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: linux-pm@vger.kernel.org Reviewed-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: of: implement .set_trips for device tree thermal zonesSascha Hauer
This patch implements .set_trips for device tree thermal zones. As the hardware-tracked trip points is supported by thermal core patch[0]. patch[0] "thermal: Add support for hardware-tracked trip points". Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Reviewed-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: Add support for hardware-tracked trip pointsSascha Hauer
This adds support for hardware-tracked trip points to the device tree thermal sensor framework. The framework supports an arbitrary number of trip points. Whenever the current temperature is updated, the trip points immediately below and above the current temperature are found. A .set_trips callback is then called with the temperatures. If there is no trip point above or below the current temperature, the passed trip temperature will be -INT_MAX or INT_MAX respectively. In this callback, the driver should program the hardware such that it is notified when either of these trip points are triggered. When a trip point is triggered, the driver should call `thermal_zone_device_update' for the respective thermal zone. This will cause the trip points to be updated again. If .set_trips is not implemented, the framework behaves as before. This patch is based on an earlier version from Mikko Perttunen <mikko.perttunen@kapsi.fi> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: linux-pm@vger.kernel.org Reviewed-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: remove declare local symbols as staticEduardo Valentin
Trivial: remove the following: drivers/thermal/qcom/tsens-8916.c:103:24: warning: symbol 'ops_8916' was not declared. Should it be static? drivers/thermal/qcom/tsens-8996.c:76:24: warning: symbol 'ops_8996' was not declared. Should it be static? drivers/thermal/qcom/tsens-8974.c:235:24: warning: symbol 'ops_8974' was not declared. Should it be static? drivers/thermal/qcom/tsens-8960.c:279:24: warning: symbol 'ops_8960' was not declared. Should it be static? Cc: Zhang Rui <rui.zhang@intel.com> Cc: Rajendra Nayak <rnayak@codeaurora.org> Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: tsens-8996: Add support for 8996 family of SoCsRajendra Nayak
The TSENS controller in 8996 family of SoCs is capable of converting the ADC code outputs to real temperature values (in decidegree Celsius). It can also be programmed to provide raw ADC code, but the secure software on 8996 programs it to provide real temperatures and also does the needed calibrations. We check the valid bit to ensure valid data is read by the AHB master. And the spec recommends the below algorithm to read data 3 consecutive times, which takes care of the worst case delay taken to propagate the updated data to the register. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: tsens-8960: Add support for 8960 family of SoCsRajendra Nayak
8960 family of SoCs have the TSENS device as part of GCC, hence the driver probes the virtual child device created by GCC and uses the parent to extract all DT properties and reuses the GCC regmap. Also GCC/TSENS are part of a domain thats not always ON. Hence add .suspend and .resume hooks to save and restore some of the inited register context. Also 8960 family have some of the TSENS init sequence thats required to be done by the HLOS driver (some later versions of TSENS do not export these registers to non-secure world, and hence need these initializations to be done by secure bootloaders) 8660 from the same family has just one sensor and hence some register offset/layout differences which need special handling in the driver. Based on the original code from Siddartha Mohanadoss, Stephen Boyd and Narendran Rajan. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: core: export apis to get slope and offsetRajendra Nayak
Add apis for platform thermal drivers to query for slope and offset attributes, which might be needed for temperature calculations. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: tsens-8974: Add support for 8974 family of SoCsRajendra Nayak
Add .calibrate support for 8974 family as part of tsens_ops. Based on the original code by Siddartha Mohanadoss and Stephen Boyd. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: tsens-8916: Add support for 8916 family of SoCsRajendra Nayak
Add support to calibrate sensors on 8916 family and also add common functions to read temperature from sensors (This can be reused on other SoCs having similar TSENS device) The calibration data is read from eeprom using the generic nvmem framework apis. Based on the original code by Siddartha Mohanadoss and Stephen Boyd. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-09-27thermal: qcom: tsens: Add a skeletal TSENS driversRajendra Nayak
TSENS is Qualcomms' thermal temperature sensor device. It supports reading temperatures from multiple thermal sensors present on various QCOM SoCs. Calibration data is generally read from a non-volatile memory (eeprom) device. Add a skeleton driver with all the necessary abstractions so a variety of qcom device families which support TSENS can add driver extensions. Also add the required device tree bindings which can be used to describe the TSENS device in DT. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Lina Iyer <lina.iyer@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-11-15 06:26:06 +0000