From ca3de46b50809000b5ba708634e26ad979a4a63a Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Mon, 24 Jun 2013 14:30:44 +0800 Subject: thermal: add imx thermal driver support This is based on the initial imx thermal work done by Rob Lee (Not sure if the email address is still valid). Since he is no longer interested in the work and I have rewritten a significant amount of the code, I just took the authorship over from him. It adds the imx thermal support using Temperature Monitor (TEMPMON) block found on some Freescale i.MX SoCs. The driver uses syscon regmap interface to access TEMPMON control registers and calibration data, and supports cpufreq as the cooling device. Signed-off-by: Shawn Guo Signed-off-by: Eduardo Valentin --- .../devicetree/bindings/thermal/imx-thermal.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt b/Documentation/devicetree/bindings/thermal/imx-thermal.txt new file mode 100644 index 000000000000..541c25e49abf --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt @@ -0,0 +1,17 @@ +* Temperature Monitor (TEMPMON) on Freescale i.MX SoCs + +Required properties: +- compatible : "fsl,imx6q-thermal" +- fsl,tempmon : phandle pointer to system controller that contains TEMPMON + control registers, e.g. ANATOP on imx6q. +- fsl,tempmon-data : phandle pointer to fuse controller that contains TEMPMON + calibration data, e.g. OCOTP on imx6q. The details about calibration data + can be found in SoC Reference Manual. + +Example: + +tempmon { + compatible = "fsl,imx6q-tempmon"; + fsl,tempmon = <&anatop>; + fsl,tempmon-data = <&ocotp>; +}; -- cgit v1.2.3 From 0e97194bcfa09fc835016e3aa12b932827a9e2a6 Mon Sep 17 00:00:00 2001 From: Amit Daniel Kachhap Date: Mon, 24 Jun 2013 16:20:48 +0530 Subject: ARM: dts: thermal: exynos: Add documentation for Exynos SoC thermal bindings Proper description for Exynos4 bindings added to Documentation/devicetree/ bindings. It adds description to use multiple TMU instances, optional voltage supply node and optional shared register across multiple TMU's. Acked-by: Jonghwa Lee Signed-off-by: Lukasz Majewski Signed-off-by: Kyungmin Park Signed-off-by: Amit Daniel Kachhap Acked-by: Eduardo Valentin Signed-off-by: Eduardo Valentin --- .../devicetree/bindings/thermal/exynos-thermal.txt | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/exynos-thermal.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt new file mode 100644 index 000000000000..284f5300fd8b --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -0,0 +1,55 @@ +* Exynos Thermal Management Unit (TMU) + +** Required properties: + +- compatible : One of the following: + "samsung,exynos4412-tmu" + "samsung,exynos4210-tmu" + "samsung,exynos5250-tmu" + "samsung,exynos5440-tmu" +- interrupt-parent : The phandle for the interrupt controller +- reg : Address range of the thermal registers. For soc's which has multiple + instances of TMU and some registers are shared across all TMU's like + interrupt related then 2 set of register has to supplied. First set + belongs to each instance of TMU and second set belongs to common TMU + registers. +- interrupts : Should contain interrupt for thermal system +- clocks : The main clock for TMU device +- clock-names : Thermal system clock name +- vtmu-supply: This entry is optional and provides the regulator node supplying + voltage to TMU. If needed this entry can be placed inside + board/platform specific dts file. + +Example 1): + + tmu@100C0000 { + compatible = "samsung,exynos4412-tmu"; + interrupt-parent = <&combiner>; + reg = <0x100C0000 0x100>; + interrupts = <2 4>; + clocks = <&clock 383>; + clock-names = "tmu_apbif"; + status = "disabled"; + vtmu-supply = <&tmu_regulator_node>; + }; + +Example 2): + + tmuctrl_0: tmuctrl@160118 { + compatible = "samsung,exynos5440-tmu"; + reg = <0x160118 0x230>, <0x160368 0x10>; + interrupts = <0 58 0>; + clocks = <&clock 21>; + clock-names = "tmu_apbif"; + }; + +Note: For multi-instance tmu each instance should have an alias correctly +numbered in "aliases" node. + +Example: + +aliases { + tmuctrl0 = &tmuctrl_0; + tmuctrl1 = &tmuctrl_1; + tmuctrl2 = &tmuctrl_2; +}; -- cgit v1.2.3 From beb70b2d2fe211fc98ec13cf769f331243f5221a Mon Sep 17 00:00:00 2001 From: Amit Daniel Kachhap Date: Mon, 24 Jun 2013 16:20:49 +0530 Subject: Documentation: thermal: Explain the exynos thermal driver model This patch updates the documentation to explain the driver model and file layout. Acked-by: Jonghwa Lee Acked-by: Kukjin Kim Acked-by: Eduardo Valentin Signed-off-by: Amit Daniel Kachhap Signed-off-by: Eduardo Valentin --- Documentation/thermal/exynos_thermal | 43 ++++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/thermal/exynos_thermal b/Documentation/thermal/exynos_thermal index 2b46f67b1ccb..9010c4416967 100644 --- a/Documentation/thermal/exynos_thermal +++ b/Documentation/thermal/exynos_thermal @@ -1,17 +1,17 @@ -Kernel driver exynos4_tmu +Kernel driver exynos_tmu ================= Supported chips: -* ARM SAMSUNG EXYNOS4 series of SoC - Prefix: 'exynos4-tmu' +* ARM SAMSUNG EXYNOS4, EXYNOS5 series of SoC Datasheet: Not publicly available Authors: Donggeun Kim +Authors: Amit Daniel -Description ------------ +TMU controller Description: +--------------------------- -This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC. +This driver allows to read temperature inside SAMSUNG EXYNOS4/5 series of SoC. The chip only exposes the measured 8-bit temperature code value through a register. @@ -34,9 +34,9 @@ The three equations are: TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register) Temperature code measured at 85 degree Celsius which is unchanged -TMU(Thermal Management Unit) in EXYNOS4 generates interrupt +TMU(Thermal Management Unit) in EXYNOS4/5 generates interrupt when temperature exceeds pre-defined levels. -The maximum number of configurable threshold is four. +The maximum number of configurable threshold is five. The threshold levels are defined as follows: Level_0: current temperature > trigger_level_0 + threshold Level_1: current temperature > trigger_level_1 + threshold @@ -47,6 +47,31 @@ The threshold levels are defined as follows: through the corresponding registers. When an interrupt occurs, this driver notify kernel thermal framework -with the function exynos4_report_trigger. +with the function exynos_report_trigger. Although an interrupt condition for level_0 can be set, it can be used to synchronize the cooling action. + +TMU driver description: +----------------------- + +The exynos thermal driver is structured as, + + Kernel Core thermal framework + (thermal_core.c, step_wise.c, cpu_cooling.c) + ^ + | + | +TMU configuration data -------> TMU Driver <------> Exynos Core thermal wrapper +(exynos_tmu_data.c) (exynos_tmu.c) (exynos_thermal_common.c) +(exynos_tmu_data.h) (exynos_tmu.h) (exynos_thermal_common.h) + +a) TMU configuration data: This consist of TMU register offsets/bitfields + described through structure exynos_tmu_registers. Also several + other platform data (struct exynos_tmu_platform_data) members + are used to configure the TMU. +b) TMU driver: This component initialises the TMU controller and sets different + thresholds. It invokes core thermal implementation with the call + exynos_report_trigger. +c) Exynos Core thermal wrapper: This provides 3 wrapper function to use the + Kernel core thermal framework. They are exynos_unregister_thermal, + exynos_register_thermal and exynos_report_trigger. -- cgit v1.2.3 From ccba4ffd9eff6120a20cc7656458ac554aec4b0c Mon Sep 17 00:00:00 2001 From: Eduardo Valentin Date: Thu, 15 Aug 2013 11:34:17 -0400 Subject: drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional When registering a new thermal_device, the thermal framework will always add a hwmon sysfs interface. This patch adds a flag to make this behavior optional. Now when registering a new thermal device, the caller can optionally inform if hwmon interface is desirable. This can be done by means of passing a thermal_zone_params.no_hwmon == true. In order to keep same behavior as of today, all current calls will by default create the hwmon interface. Cc: David Woodhouse Cc: linux-acpi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Zhang Rui Suggested-by: Wei Ni Signed-off-by: Eduardo Valentin --- Documentation/thermal/sysfs-api.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index a71bd5b90fe8..37c54863f611 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -142,6 +142,11 @@ temperature) and throttle appropriate devices. This is an optional feature where some platforms can choose not to provide this data. .governor_name: Name of the thermal governor used for this zone + .no_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface + is required. when no_hwmon == false, a hwmon sysfs interface + will be created. when no_hwmon == true, nothing will be done. + In case the thermal_zone_params is NULL, the hwmon interface + will be created (for backward compatibility). .num_tbps: Number of thermal_bind_params entries for this zone .tbp: thermal_bind_params entries -- cgit v1.2.3 From a8892d83894bcbd2717846cfa85955152b73453f Mon Sep 17 00:00:00 2001 From: Eduardo Valentin Date: Tue, 16 Jul 2013 15:26:28 -0400 Subject: thermal: thermal_core: allow binding with limits on bind_params When registering a thermal zone device using platform information via bind_params, the thermal framework will always perform the cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT). This patch changes the data structures so that it is possible to inform what are the desired limits for each trip point inside a bind_param. The way the binding is performed is also changed so that it uses the new data structure. Cc: Zhang Rui Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- Documentation/thermal/sysfs-api.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 37c54863f611..87519cb379ee 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -134,6 +134,13 @@ temperature) and throttle appropriate devices. this thermal zone and cdev, for a particular trip point. If nth bit is set, then the cdev and thermal zone are bound for trip point n. + .limits: This is an array of cooling state limits. Must have exactly + 2 * thermal_zone.number_of_trip_points. It is an array consisting + of tuples of state limits. Each trip + will be associated with one state limit tuple when binding. + A NULL pointer means + on all trips. These limits are used when binding a cdev to a + trip point. .match: This call back returns success(0) if the 'tz and cdev' need to be bound, as per platform data. 1.4.2 struct thermal_zone_params -- cgit v1.2.3