summaryrefslogtreecommitdiff
path: root/drivers/thermal
AgeCommit message (Collapse)Author
2018-12-27imx_thermal.c: Use old trip point values from BSP 2.7toradex_4.9-1.0.x-imx-rebasedPhilippe Schenker
In kernel upgrade from 4.1 -> 4.9 trip point values have been changed by NXP. These new values caused a lot of modules to critical shut-down during validation and verification. This commit changes the new imx_thermal.c code to use the old, well verified values. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Max Krummenacher <max.krummenacher@toradex.com> (cherry picked from commit 308edefe57c5c96fad196b6e65fa159857e969f3)
2018-12-09imx_thermal.c: unregister all ressources in error pathMax Krummenacher
This was seen in code inspection. While at it, fix error text. Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2018-02-26Merge tag 'v4.9.84' into 4.9-1.0.x-imx-stable-mergeFabio Estevam
This is the 4.9.84 stable release
2018-02-25thermal: fix INTEL_SOC_DTS_IOSF_CORE dependenciesArnd Bergmann
commit 68fd77cf8a4b045594231f07e5fc92e1a34c0a9e upstream. We get a Kconfig warning when selecting this without also enabling CONFIG_PCI: warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects IOSF_MBI which has unmet direct dependencies (PCI) This adds a new depedency. Fixes: 3a2419f865a6 ("Thermal: Intel SoC: DTS thermal use common APIs") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-24Merge tag 'v4.9.76' into 4.9-1.0.x-imx-stable-mergeStefan Agner
This is the 4.9.76 stable release Resolved conflicts drivers/clk/imx/clk-imx6q.c drivers/net/ethernet/freescale/fec_main.c
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-12-13Merge tag 'v4.9.67' into 4.9-1.0.x-imx-fixes-stable-mergeStefan Agner
This is the 4.9.67 stable release Resolved conflicts: arch/arm/boot/dts/imx6sx-sdb.dts drivers/dma/imx-sdma.c drivers/mmc/core/host.c drivers/usb/chipidea/otg.c sound/soc/fsl/fsl_ssi.c This merge also reverts commit 3a654a85932f ("dmaengine: imx-sdma - correct the dma transfer residue calculation"). The downstream kernel seems to use different structures and already use buf_ptail in its calculation.
2017-09-15MLK-16470 thermal: imx_thermal: fix wrong thermal grade register read for MX7DDong Aisheng
From MX7D Fuse Map v2.9, the thermal grade register is 0x440[7:6], not 0x480[7:6] as before. Fixes: 2045abb4391a ("MLK-11518-01 thermal: imx: add thermal support for imx7") Reviewed-by: Bai Ping <ping.bai@nxp.com> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> (cherry picked from commit add734018577b490840e1d19c2640bcad0e4bda9)
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-06-19MLK-15075 thermal: imx: fix temp read failure on i.mx7dBai Ping
On i.MX7D, if the system enter LPSR mode, the tempmon module will be power down, so the regiter's value is lost, so we need to save the registers before suspend and restore the register after resume back. Signed-off-by: Bai Ping <ping.bai@nxp.com> (cherry picked from commit 72e6a05b52d24b4976c5f012a185c049f0e6ffa6)
2017-06-08MLK-14291 thermal: imx: fix setting passive trip tempIrina Tirdea
When setting passive temperature trip point, it is not allowed to set a higher value than the default. Currently the driver compares the new temperature to set with a constant (0). This comparison wil always be true (temp to set higher than 0) and the driver will return -EINVAL. This is a leftover from rebasing the commit fc4fcd689419 ("MLK-11705 thermal: imx: make the critical trip temp changable for test"). Fix the comparison by using the actual default passive temperature value instead of the wrong constant. Signed-off-by: Irina Tirdea <irina.tirdea@nxp.com>
2017-02-23MLK-12219 thermal: imx: unregister busfreq_notifier in thermal_removeBai Ping
unregister the busfreq_notifier when the thermal driver is removed. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2017-02-23MLK-12072 thermal: imx: enable tempmon finish bit check on imx7d TO1.1Bai Ping
On i.MX7D TO1.0, the finish bit in tempmon module used for verify the temp value is broken, so it can NOT be used for checking the temp value. On TO1.1, this issue has been fixed, so we can use this bit to verify if the temp value is valid. Signed-off-by: Bai Ping <ping.bai@nxp.com>
2017-02-23MLK-11705 thermal: imx: make the critical trip temp changable for testBai Ping
In order to test the critical trip point funtion, the critical trip point temp should be writable from userspace. Signed-off-by: Bai Ping <b51503@freescale.com>
2017-02-23MLK-11600 thermal: imx: notify thermal driver in low_bus_freq_modeBai Ping
As thermal sensor alarm function needs PLL3 to be always on, but low power idle needs all PLLs to be off, they are exclusive. Low power idle is only enabled when system staying at low bus mode which means the overall system power consumption is NOT high, thermal alarm function can be disabled in this mode to allow low power idle to be entered, and thermal sensor will still use polling mechanism to monitor the system temperature. Add busfreq notify to achieve this goal. (this patch is copied from commit dd3d1e6c6ff0) Signed-off-by: Bai Ping <b51503@freescale.com>
2017-02-23MLK-11518-03 thermal: imx enable devfreq coolingBai Ping
Enable devfreq cooling to trigger GPU freq change when hot trip is reached. Make sure thermal driver loaded after cpufreq is loaded, otherwise, cpu_cooling will not get valid cpufreq table, hence cpu_cooling will be not working. Signed-off-by: Bai Ping <b51503@freescale.com>
2017-02-23MLK-11518-02 thermal: imx: add .get_trend callback fn in thermal driverBai Ping
add .get_trend callback to determine the thermal raise/fall trend, when the temp great than a threshold, drop to the lowest trend (THERMAL_TREND_DROP_FULL). Signed-off-by: Bai Ping <b51503@freescale.com>
2017-02-23MLK-11518-01 thermal: imx: add thermal support for imx7Bai Ping
This pacth re-write part of the code the support i.MX6 and i.MX7 in thermal driver. the TEMPMON module in i.MX6 and i.MX7 can provide the same funtion, but has different register offset and bitfield define. Signed-off-by: Bai Ping <b51503@freescale.com>
2017-02-23MLK-11485 thermal: add device cooling for thermal driverAnson Huang
this patch is chery-picked from imx_3.14.y (cherry picked from commit 51e376b469c) ENGR00274056-1 thermal: add device cooling for thermal driver cpu cooling is not enough when temperature is too hot, as some devices may contribute a lot of heat to SOC, such as GPU, so we need to add device cooling as well, when system is too hot, devices can also take their actions to lower SOC temperature. when temperature cross the passive trip, device cooling driver will send out notification, those devices who register this devfreq_cooling notification will take actions to lower SOC temperature. Signed-off-by: Anson Huang <b20788@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@freescale.com> Signed-off-by: Bai Ping <b51503@freescale.com>
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>
generated by cgit v1.2.3 (git 2.0.4) at 2024-04-27 12:43:21 +0000