summaryrefslogtreecommitdiffstats
path: root/drivers/thermal
AgeCommit message (Collapse)AuthorFilesLines
2017-11-17Merge branch 'next' of ↵Linus Torvalds19-320/+1006
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management updates from Zhang Rui: - introduce brcmstb AVS TMON thermal driver (Brian Norris) - add Rockchip RV1108 support in rockchip thermal driver (Rocky Hao) - major rework on HISI driver plus additional support of hisi3660 (Daniel Lezcano) - add nvmem-cells binding on imx6sx (Leonard Crestez) - fix a NULL pointer dereference on ti thermal driver unloading (Tony Lindgren) - improve tmon tool to make it easier to cross-compile tmon (Markus Mayer) - add Coffee Lake and Cannon Lake support for intel processor and pch thermal drivers (Srinivas Pandruvada) - other small fixes and cleanups (Arvind Yadav, Colin Ian King, Allen Wild, Nicolin Chen, Baruch SiachNiklas Söderlund, Arnd Bergmann) * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (44 commits) thermal: pch: Add Cannon Lake support thermal: int340x: processor_thermal: Add Coffee Lake support thermal: int340x: processor_thermal: Add Cannon Lake support thermal: bxt: remove redundant variable trip thermal: cpu_cooling: pr_err() strings should end with newlines thermal: add brcmstb AVS TMON driver Documentation: devicetree: add binding for Broadcom STB AVS TMON thermal/drivers/hisi: Add support for hi3660 SoC thermal/drivers/hisi: Prepare to add support for other hisi platforms thermal/drivers/hisi: Add platform prefix to function name thermal/drivers/hisi: Put platform code together thermal/drivers/qcom-spmi: Use devm_iio_channel_get thermal/drivers/generic-iio-adc: Switch tz request to devm version thermal/drivers/step_wise: Fix temperature regulation misbehavior thermal/drivers/hisi: Use round up step value thermal/drivers/hisi: Move the clk setup in the corresponding functions thermal/drivers/hisi: Remove mutex_lock in the code thermal/drivers/hisi: Remove thermal data back pointer thermal/drivers/hisi: Convert long to int thermal/drivers/hisi: Rename and remove unused field ...
2017-11-16Merge tag 'armsoc-drivers' of ↵Linus Torvalds4-2/+273
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver updates from Arnd Bergmann: "This branch contains platform-related driver updates for ARM and ARM64, these are the areas that bring the changes: New drivers: - driver support for Renesas R-Car V3M (R8A77970) - power management support for Amlogic GX - a new driver for the Tegra BPMP thermal sensor - a new bus driver for Technologic Systems NBUS Changes for subsystems that prefer to merge through arm-soc: - the usual updates for reset controller drivers from Philipp Zabel, with five added drivers for SoCs in the arc, meson, socfpa, uniphier and mediatek families - updates to the ARM SCPI and PSCI frameworks, from Sudeep Holla, Heiner Kallweit and Lorenzo Pieralisi Changes specific to some ARM-based SoC - the Freescale/NXP DPAA QBMan drivers from PowerPC can now work on ARM as well - several changes for power management on Broadcom SoCs - various improvements on Qualcomm, Broadcom, Amlogic, Atmel, Mediatek - minor Cleanups for Samsung, TI OMAP SoCs" [ NOTE! This doesn't work without the previous ARM SoC device-tree pull, because the R8A77970 driver is missing a header file that came from that pull. The fact that this got merged afterwards only fixes it at this point, and bisection of that driver will fail if/when you walk into the history of that driver. - Linus ] * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (96 commits) soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader bus: add driver for the Technologic Systems NBUS memory: omap-gpmc: Remove deprecated gpmc_update_nand_reg() soc: qcom: remove unused label soc: amlogic: gx pm domain: add PM and OF dependencies drivers/firmware: psci_checker: Add missing destroy_timer_on_stack() dt-bindings: power: add amlogic meson power domain bindings soc: amlogic: add Meson GX VPU Domains driver soc: qcom: Remote filesystem memory driver dt-binding: soc: qcom: Add binding for rmtfs memory of: reserved_mem: Accessor for acquiring reserved_mem of/platform: Generalize /reserved-memory handling soc: mediatek: pwrap: fix fatal compiler error soc: mediatek: pwrap: fix compiler errors arm64: mediatek: cleanup message for platform selection soc: Allow test-building of MediaTek drivers soc: mediatek: place Kconfig for all SoC drivers under menu soc: mediatek: pwrap: add support for MT7622 SoC soc: mediatek: pwrap: add common way for setup CS timing extenstion soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap ..
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman5-0/+5
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02Merge branches 'thermal-core', 'thermal-tool', 'thermal-intel' and ↵Zhang Rui19-320/+1006
'thermal-soc' into next
2017-11-02Merge branch 'imx-nvmem' into thermal-socZhang Rui2-30/+75
2017-11-02thermal: pch: Add Cannon Lake supportSrinivas Pandruvada1-0/+11
Added Cannon Lake PCH ids. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-11-02thermal: int340x: processor_thermal: Add Coffee Lake supportSrinivas Pandruvada1-0/+2
Add new PCI id for Coffee lake processor thermal device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-11-02thermal: int340x: processor_thermal: Add Cannon Lake supportSrinivas Pandruvada1-0/+4
Added PCI-ID of Cannon Lake thermal device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-11-02thermal: bxt: remove redundant variable tripColin Ian King1-2/+1
Variable trip is assigned but never read, hence it is redundant and can be removed. Cleans up clang warning: drivers/thermal/intel_bxt_pmic_thermal.c:204:4: warning: Value stored to 'trip' is never read Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-10-31thermal: cpu_cooling: pr_err() strings should end with newlinesArvind Yadav1-1/+1
pr_err() messages should end with a new-line to avoid other messages being concatenated. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Javi Merino <javi.merino@kernel.org> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal: add brcmstb AVS TMON driverBrian Norris4-1/+396
The AVS TMON core provides temperature readings, a pair of configurable high- and low-temperature threshold interrupts, and an emergency over-temperature chip reset. The driver utilizes the first two to provide temperature readings and high-temperature notifications to applications. The over-temperature reset is not exposed to applications; this reset threshold is critical to the system and should be set with care within the bootloader. Applications may choose to utilize the notification mechanism, the temperature reading mechanism (e.g., through polling), or both. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Doug Berger <opendmb@gmail.com> Signed-off-by: Markus Mayer <mmayer@broadcom.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Add support for hi3660 SoCKevin Wangtao1-1/+144
This patch adds the support for thermal sensor on the Hi3660 SoC. Hi3660 tsensor support alarm in alarm threshold, it also has a configurable hysteresis interval, interrupt will be triggered when temperature rise above the alarm threshold or fall below the hysteresis threshold. Signed-off-by: Kevin Wangtao <kevin.wangtao@linaro.org> Tested-by: Daniel Lezcano <daniel.lezcano@linaro.org> # hikey6220 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Prepare to add support for other hisi platformsKevin Wangtao1-45/+87
For platform compatibility, add the tsensor ops to a thermal data structure. Each platform has its own probe function to register proper tsensor ops function to the pointer, platform related resource request are also implemented in the platform probe function. Signed-off-by: Kevin Wangtao <kevin.wangtao@linaro.org> Tested-by: Daniel Lezcano <daniel.lezcano@linaro.org> # hikey6220 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Add platform prefix to function nameKevin Wangtao1-72/+73
As the next patches will provide support for the hikey3660's sensor, several functions with the same purpose but for different platforms will be introduced. In order to make a clear distinction between them, let's prefix the function names with the platform name. This patch has no functional changes, only name changes. Signed-off-by: Kevin Wangtao <kevin.wangtao@linaro.org> Tested-by: Daniel Lezcano <daniel.lezcano@linaro.org> # hikey6220 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Put platform code togetherKevin Wangtao1-38/+38
Reorganize the code for next patches by moving the functions upper in the file which will prevent a forward declaration. There is no functional change here. Signed-off-by: Kevin Wangtao <kevin.wangtao@linaro.org> Tested-by: Daniel Lezcano <daniel.lezcano@linaro.org> # hikey6220 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/qcom-spmi: Use devm_iio_channel_getDaniel Lezcano1-29/+14
The iio_channel_get() function has now its devm_ version. Use it and remove all the rollback code for iio_channel_release() as well as the .remove ops. [Compiled tested only] Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/generic-iio-adc: Switch tz request to devm versionDaniel Lezcano1-20/+4
Everything mentionned here: https://lkml.org/lkml/2016/4/20/850 This driver was added before the devm_iio_channel_get() function version was merged. The sensor should be released before the iio channel, thus we had to use the non-devm version of thermal_zone_of_sensor_register(). Now the devm_iio_channel_get() is available, do the corresponding change in this driver and remove gadc_thermal_remove(). [Compiled tested only] Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/step_wise: Fix temperature regulation misbehaviorDaniel Lezcano1-5/+6
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>
2017-10-31thermal/drivers/hisi: Use round up step valueKevin Wangtao1-14/+8
Use round up division to ensure the programmed value of threshold and the lag are not less than what we set, and in order to keep the accuracy while using round up division, the step value should be a rounded up value. There is no need to use hisi_thermal_round_temp. Signed-off-by: Kevin Wangtao <kevin.wangtao@linaro.org> Tested-by: Daniel Lezcano <daniel.lezcano@linaro.org> # hikey6220 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Move the clk setup in the corresponding functionsKevin Wangtao1-20/+9
The sensor's clock is enabled and disabled outside of the probe and disable function. Moving the corresponding action in the hisi_thermal_setup() and hisi_thermal_disable_sensor(), factors out some lines of code and makes the code more symmetric. Signed-off-by: Kevin Wangtao <kevin.wangtao@linaro.org> Tested-by: Daniel Lezcano <daniel.lezcano@linaro.org> # hikey6220 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Remove mutex_lock in the codeDaniel Lezcano1-6/+0
The mutex is used to protect against writes in the configuration register. That happens at probe time, with no possible race yet. Then when the module is unloaded and at suspend/resume. When the module is unloaded, it is an userspace operation, thus via a process. Suspending the system goes through the freezer to suspend all the tasks synchronously before continuing. So it is not possible to hit the suspend ops in this driver while we are unloading it. The resume is the same situation than the probe. In other words, even if there are several places where we write the configuration register, there is no situation where we can write it at the same time, so far as I can judge 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>
2017-10-31thermal/drivers/hisi: Remove thermal data back pointerDaniel Lezcano1-6/+5
The presence of the thermal data pointer in the sensor structure has the unique purpose of accessing the thermal data in the interrupt handler. The sensor pointer is passed when registering the interrupt handler, replace the cookie by the thermal data pointer, so the back pointer is no longer needed. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Convert long to intDaniel Lezcano1-2/+2
There is no point to specify the temperature as long variable, the int is enough. Replace all long variables to int, so making the code consistent. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Rename and remove unused fieldDaniel Lezcano1-10/+8
Rename the 'sensors' field to 'sensor' as we describe only one sensor. Remove the 'sensor_temp' as it is no longer used. 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>
2017-10-31thermal/drivers/hisi: Remove costly sensor inspectionDaniel Lezcano1-110/+93
The sensor is all setup, bind, resetted, acked, etc... every single second. That was the way to workaround a problem with the interrupt bouncing again and again. With the following changes, we fix all in one: - Do the setup, one time, at probe time - Add the IRQF_ONESHOT, ack the interrupt in the threaded handler - Remove the interrupt handler - Set the correct value for the LAG register - Remove all the irq_enabled stuff in the code as the interruption handling is fixed - Remove the 3ms delay - Reorder the initialization routine to be in the right order It ends up to a nicer code and more efficient, the 3-5ms delay is removed from the get_temp() path. 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>
2017-10-31thermal/drivers/hisi: Fix configuration register settingDaniel Lezcano1-5/+29
The TEMP0_CFG configuration register contains different field to set up the temperature controller. However in the code, nothing prevents a setup to overwrite the previous one: eg. writing the hdak value overwrites the sensor selection, the sensor selection overwrites the hdak value. In order to prevent such thing, use a regmap-like mechanism by reading the value before, set the corresponding bits and write the result. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Encapsulate register writes into helpersDaniel Lezcano1-22/+70
Hopefully, the function name can help to clarify the semantic of the operations when writing in the register. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Remove pointless lockDaniel Lezcano1-5/+1
The threaded interrupt inspect the sensors structure to look in the temp threshold field, but this field is read-only in all the code, except in the probe function before the threaded interrupt is set. In other words there is not race window in the threaded interrupt when reading the field value. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Fix multiple alarm interrupts firingDaniel Lezcano1-2/+8
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>
2017-10-31thermal/drivers/hisi: Simplify the temperature/step computationDaniel Lezcano1-13/+28
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>
2017-10-31thermal/drivers/hisi: Fix kernel panic on alarm interruptDaniel Lezcano1-9/+9
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>
2017-10-31thermal/drivers/hisi: Remove the multiple sensors supportDaniel Lezcano1-56/+19
By essence, the tsensor does not really support multiple sensor at the same time. It allows to set a sensor and use it to get the temperature, another sensor could be switched but with a delay of 3-5ms. It is difficult to read simultaneously several sensors without a big delay. Today, just one sensor is used, it is not necessary to deal with multiple sensors in the code. Remove them and if it is needed in the future add them on top of a code which will be clean up in the meantime. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Leo Yan <leo.yan@linaro.org> Acked-by: Wangtao (Kevin, Kirin) <kevin.wangtao@hisilicon.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal/drivers/hisi: Fix missing interrupt enablementDaniel Lezcano1-2/+3
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>
2017-10-31thermal: ti-soc-thermal: Fix ti_thermal_unregister_cpu_cooling NULL pointer ↵Tony Lindgren1-1/+2
on unload While debugging some PM issues and trying to remove all the loaded modules, I ran across the following when unloading ti-soc-thermal: Unable to handle kernel NULL pointer dereference at virtual address 000000b4 ... [<c08db340>] (kobject_put) from [<bf28954c>] (ti_thermal_unregister_cpu_cooling+0x20/0x28 [ti_soc_thermal]) [<bf28954c>] (ti_thermal_unregister_cpu_cooling [ti_soc_thermal]) from [<bf287c88>] (ti_bandgap_remove+0x3c/0x104 [ti_soc_thermal]) [<bf287c88>] (ti_bandgap_remove [ti_soc_thermal]) from [<c0610d48>] (platform_drv_remove+0x24/0x3c) [<c0610d48>] (platform_drv_remove) from [<c060f114>] (device_release_driver_internal+0x160/0x208) [<c060f114>] (device_release_driver_internal) from [<c060f200>] (driver_detach+0x38/0x6c) [<c060f200>] (driver_detach) from [<c060e2d4>] (bus_remove_driver+0x4c/0xa0) [<c060e2d4>] (bus_remove_driver) from [<c01f2370>] (SyS_delete_module+0x168/0x238) [<c01f2370>] (SyS_delete_module) from [<c0108240>] (ret_fast_syscall+0x0/0x28) Cc: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal: rcar_gen3_thermal: fix initialization sequence for H3 ES2.0Niklas Söderlund1-19/+15
The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796) ES1.0. Fix this by not looking at compatible strings and instead defaulting to the r8a7796 initialization sequence and use soc_device_match() to check for H3 ES1.x. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal: armada: fix formula documentation commentBaruch Siach1-1/+1
The formula implementation at armada_get_temp() indicates that the sign in the formula is inverted. Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal: tegra: remove null check for dev pointerNicolin Chen1-1/+1
The dev pointer is going through a null check after a dereference. So this patch removes that useless check since the driver does not pass a null dev pointer in any case. Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal: enable broadcom menu for arm64 bcm2835Allen Wild1-1/+1
Moving the bcm2835 thermal driver to the broadcom directory prevented it from getting enabled for arm64 builds, since the broadcom directory is only available when 32-bit specific ARCH_BCM is set. Fix this by enabling the Broadcom menu for ARCH_BCM or ARCH_BCM2835. Fixes: 6892cf07e733 ("thermal: bcm2835: move to the broadcom subdirectory") Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Allen Wild <allenwild93@gmail.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-31thermal: rockchip: Support the RV1108 SoC in thermal driverRocky Hao1-0/+67
RV1108 SOC has one Temperature Sensor for CPU. Reviewed-by: Caesar Wang <wxt@rock-chips.com> Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2017-10-19thermal: Add Tegra BPMP thermal sensor driverMikko Perttunen4-2/+273
On Tegra186, the BPMP (Boot and Power Management Processor) exposes an interface to thermal sensors on the system-on-chip. This driver implements access to the interface. It supports reading the temperature, setting trip points and receiving notification of a tripped trip point. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-10-18thermal: imx: add NVMEM dependencyArnd Bergmann1-0/+1
The driver now fails to link into vmlinux when CONFIG_NVMEM is a loadable module: drivers/thermal/imx_thermal.o: In function `imx_thermal_probe': imx_thermal.c:(.text+0x360): undefined reference to `nvmem_cell_read_u32' imx_thermal.c:(.text+0x360): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `nvmem_cell_read_u32' imx_thermal.c:(.text+0x388): undefined reference to `nvmem_cell_read_u32' imx_thermal.c:(.text+0x388): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `nvmem_cell_read_u32' This adds a Kconfig dependency to force it to be a module as well when its dependency is loadable. Fixes: 7fe5ba04fcdc ("thermal: imx: Add support for reading OCOTP through nvmem") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-10-17thermal/intel_powerclamp: pr_err()/pr_info() strings should end with newlinesArvind Yadav1-2/+2
pr_err()/pr_info() messages should end with a new-line to avoid other messages being concatenated. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-09-20thermal: imx: Add support for reading OCOTP through nvmemLeonard Crestez1-30/+74
On newer imx SOCs accessing OCOTP directly is wrong because the ocotp clock needs to be enabled first. Add support for reading those same values through the nvmem API instead. The older path is preserved for compatibility with older dts and because it works correctly on imx6qdl chips. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-09-08Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and ↵Zhang Rui17-90/+635
'const-thermal-zone-structure' into next
2017-09-08Merge branches 'mediatek-mt2712', 'rockchip-rk3328' and 'uniphier-thermal' ↵Zhang Rui4-0/+458
into thermal-soc
2017-09-01Thermal: int3406_thermal: fix thermal sysfs I/FZhang Rui1-59/+37
there are three concepts represent backlight in int3406_thermal driver. 1. the raw brightness value from native graphics driver. 2. the percentage numbers from ACPI _BCL control method. 3. the consecutive numbers represent cooling states. int3406_thermal driver 1. uses value from DDDL/DDPC as the lower/upper limit, which is consistent with ACPI _BCL control methods. 2. reads current and maximum brightness from the native graphics driver. 3. expose them to thermal sysfs I/F This patch fixes the code that switches between the raw brightness value and the cooling state, which results in bogus value in thermal sysfs I/F. Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-08-31thermal: mediatek: minor mtk_thermal.c cleanupsLouis Yu1-4/+4
Move independent thermal module reset in the beginning. Signed-off-by: Louis Yu <louis.yu@mediatek.com> Reviewed-by: Dawei Chien <dawei.chien@mediatek.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-08-31thermal: mediatek: extend calibration data for mt2712 chipLouis Yu1-5/+11
This patch adds support for mt2712 chip thermal calibration data and calculation, and is compatible with the existing chips. Signed-off-by: Louis Yu <louis.yu@mediatek.com> Reviewed-by: Dawei Chien <dawei.chien@mediatek.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-08-31thermal: mediatek: add Mediatek thermal driver for mt2712Louis Yu1-4/+66
This patch adds support for mt2712 chip to mtk_thermal, and integrate mt2712 into the same mediatek thermal driver. MT2712 has only 1 bank and 4 sensors. Signed-off-by: Louis Yu <louis.yu@mediatek.com> Reviewed-by: Dawei Chien <dawei.chien@mediatek.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-08-15thermal: intel_pch_thermal: Fix enable check on Broadwell-DEEd Swierk1-2/+2
Using the TSDSS flag to determine whether the thermal sensor is enabled is problematic. Broadwell-DE (Xeon D-1500) does not support dynamic shutdown and the TSDSS flag always reads 0 (contrary to the current datasheet). Even on hardware supporting dynamic shutdown, the driver does nothing to configure it, and the dynamic shutdown state should not prevent the driver from loading. The ETS flag itself indicates whether the thermal sensor is enabled, so use it instead of the TSDSS flag on all hardware platforms. Signed-off-by: Ed Swierk <eswierk@skyportsystems.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>