2014-06-27 08:12:30

by Mikko Perttunen

[permalink] [raw]
Subject: [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver

Hi everyone,

this series adds support for hardware-tracked thermal trip points
for the device tree thermal framework and introduces a new Tegra124 thermal
driver that uses them.

Hardware-tracked trip points are trip points that do not need to be polled;
the hardware gives an interrupt when the trip point is reached. The device
tree thermal framework has not previously given the sensor driver any
information about set trip points, so using these has been impossible.
This series adds a new callback from of-thermal to the driver to allow telling
the driver about trip points. The driver only needs to track two trip points,
the framework ensures that the current temperature lies between those two.
Behavior for drivers that do not include this callback is unchanged.

The Tegra124 SOCTHERM thermal driver that is included exposes four thermal zones
(the thermctl thermal zones) with hardware-tracked trip point support. While the
hardware supports four tracked trip points, only one is used.

Mikko Perttunen (6):
thermal: of: Add support for hardware-tracked trip points
of: Add bindings for nvidia,tegra124-soctherm
ARM: tegra: Add thermal trip points for Jetson TK1
ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table
thermal: Add Tegra SOCTHERM thermal management driver

.../devicetree/bindings/thermal/tegra-soctherm.txt | 32 ++
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 32 ++
arch/arm/boot/dts/tegra124.dtsi | 48 ++
drivers/clk/tegra/clk-tegra124.c | 2 +
drivers/thermal/Kconfig | 7 +
drivers/thermal/Makefile | 1 +
drivers/thermal/of-thermal.c | 97 +++-
drivers/thermal/tegra_soctherm.c | 553 +++++++++++++++++++++
include/dt-bindings/thermal/tegra124-soctherm.h | 15 +
include/linux/thermal.h | 3 +-
10 files changed, 785 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
create mode 100644 drivers/thermal/tegra_soctherm.c
create mode 100644 include/dt-bindings/thermal/tegra124-soctherm.h

--
1.8.1.5


2014-06-27 08:12:34

by Mikko Perttunen

[permalink] [raw]
Subject: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points

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 sensor driver
callback `set_trips' is then called with the temperatures.
If there is no trip point above or below the current temperature,
the passed trip temperature will be LONG_MAX or LONG_MIN 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 the `set_trips' callback is not implemented (is NULL), the framework
behaves as before.

Signed-off-by: Mikko Perttunen <[email protected]>
---
drivers/thermal/of-thermal.c | 97 ++++++++++++++++++++++++++++++++++++++++++--
include/linux/thermal.h | 3 +-
2 files changed, 95 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 04b1be7..bfccea5 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -89,6 +89,7 @@ struct __thermal_zone {
/* trip data */
int ntrips;
struct __thermal_trip *trips;
+ long prev_low_trip, prev_high_trip;

/* cooling binding data */
int num_tbps;
@@ -98,19 +99,66 @@ struct __thermal_zone {
void *sensor_data;
int (*get_temp)(void *, long *);
int (*get_trend)(void *, long *);
+ int (*set_trips)(void *, long, long);
};

+/*** Automatic trip handling ***/
+
+static int of_thermal_set_trips(struct thermal_zone_device *tz, long temp)
+{
+ struct __thermal_zone *data = tz->devdata;
+ long low = LONG_MIN, high = LONG_MAX;
+ int i;
+
+ /* Hardware trip points not supported */
+ if (!data->set_trips)
+ return 0;
+
+ /* No need to change trip points */
+ if (temp > data->prev_low_trip && temp < data->prev_high_trip)
+ return 0;
+
+ for (i = 0; i < data->ntrips; ++i) {
+ struct __thermal_trip *trip = data->trips + i;
+ long trip_low = trip->temperature - trip->hysteresis;
+
+ if (trip_low < temp && trip_low > low)
+ low = trip_low;
+
+ if (trip->temperature > temp && trip->temperature < high)
+ high = trip->temperature;
+ }
+
+ dev_dbg(&tz->device,
+ "temperature %ld, updating trip points to %ld, %ld\n",
+ temp, low, high);
+
+ data->prev_low_trip = low;
+ data->prev_high_trip = high;
+
+ return data->set_trips(data->sensor_data, low, high);
+}
+
/*** DT thermal zone device callbacks ***/

static int of_thermal_get_temp(struct thermal_zone_device *tz,
unsigned long *temp)
{
struct __thermal_zone *data = tz->devdata;
+ int err;

if (!data->get_temp)
return -EINVAL;

- return data->get_temp(data->sensor_data, temp);
+ err = data->get_temp(data->sensor_data, temp);
+ if (err)
+ return err;
+
+ err = of_thermal_set_trips(tz, *temp);
+ if (err)
+ return err;
+
+ return 0;
}

static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
@@ -222,6 +270,22 @@ static int of_thermal_set_mode(struct thermal_zone_device *tz,
return 0;
}

+static int of_thermal_update_trips(struct thermal_zone_device *tz)
+{
+ long temp;
+ int err;
+
+ err = of_thermal_get_temp(tz, &temp);
+ if (err)
+ return err;
+
+ err = of_thermal_set_trips(tz, temp);
+ if (err)
+ return err;
+
+ return 0;
+}
+
static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
enum thermal_trip_type *type)
{
@@ -252,6 +316,7 @@ static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
unsigned long temp)
{
struct __thermal_zone *data = tz->devdata;
+ int err;

if (trip >= data->ntrips || trip < 0)
return -EDOM;
@@ -259,6 +324,10 @@ static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
/* thermal framework should take care of data->mask & (1 << trip) */
data->trips[trip].temperature = temp;

+ err = of_thermal_update_trips(tz);
+ if (err)
+ return err;
+
return 0;
}

@@ -279,6 +348,7 @@ static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
unsigned long hyst)
{
struct __thermal_zone *data = tz->devdata;
+ int err;

if (trip >= data->ntrips || trip < 0)
return -EDOM;
@@ -286,6 +356,10 @@ static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
/* thermal framework should take care of data->mask & (1 << trip) */
data->trips[trip].hysteresis = hyst;

+ err = of_thermal_update_trips(tz);
+ if (err)
+ return err;
+
return 0;
}

@@ -325,10 +399,12 @@ static struct thermal_zone_device *
thermal_zone_of_add_sensor(struct device_node *zone,
struct device_node *sensor, void *data,
int (*get_temp)(void *, long *),
- int (*get_trend)(void *, long *))
+ int (*get_trend)(void *, long *),
+ int (*set_trips)(void *, long, long))
{
struct thermal_zone_device *tzd;
struct __thermal_zone *tz;
+ int err;

tzd = thermal_zone_get_zone_by_name(zone->name);
if (IS_ERR(tzd))
@@ -339,8 +415,15 @@ thermal_zone_of_add_sensor(struct device_node *zone,
mutex_lock(&tzd->lock);
tz->get_temp = get_temp;
tz->get_trend = get_trend;
+ tz->set_trips = set_trips;
tz->sensor_data = data;

+ err = of_thermal_update_trips(tzd);
+ if (err) {
+ mutex_unlock(&tzd->lock);
+ return ERR_PTR(err);
+ }
+
tzd->ops->get_temp = of_thermal_get_temp;
tzd->ops->get_trend = of_thermal_get_trend;
mutex_unlock(&tzd->lock);
@@ -384,7 +467,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
void *data, int (*get_temp)(void *, long *),
- int (*get_trend)(void *, long *))
+ int (*get_trend)(void *, long *),
+ int (*set_trips)(void *, long, long))
{
struct device_node *np, *child, *sensor_np;

@@ -422,7 +506,8 @@ thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
return thermal_zone_of_add_sensor(child, sensor_np,
data,
get_temp,
- get_trend);
+ get_trend,
+ set_trips);
}
}
of_node_put(np);
@@ -466,6 +551,7 @@ void thermal_zone_of_sensor_unregister(struct device *dev,

tz->get_temp = NULL;
tz->get_trend = NULL;
+ tz->set_trips = NULL;
tz->sensor_data = NULL;
mutex_unlock(&tzd->lock);
}
@@ -671,6 +757,9 @@ thermal_of_build_thermal_zone(struct device_node *np)
/* trips */
child = of_get_child_by_name(np, "trips");

+ tz->prev_high_trip = LONG_MIN;
+ tz->prev_low_trip = LONG_MAX;
+
/* No trips provided */
if (!child)
goto finish;
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index f7e11c7..2f8951c 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -248,7 +248,8 @@ struct thermal_genl_event {
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id,
void *data, int (*get_temp)(void *, long *),
- int (*get_trend)(void *, long *));
+ int (*get_trend)(void *, long *),
+ int (*set_trips)(void *, long, long));
void thermal_zone_of_sensor_unregister(struct device *dev,
struct thermal_zone_device *tz);
#else
--
1.8.1.5

2014-06-27 08:12:43

by Mikko Perttunen

[permalink] [raw]
Subject: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree

This adds the soctherm thermal sensing and management unit to the
Tegra124 device tree along with the four thermal zones it exports.

Signed-off-by: Mikko Perttunen <[email protected]>
---
arch/arm/boot/dts/tegra124.dtsi | 48 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index d675186..853627f 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -2,6 +2,7 @@
#include <dt-bindings/gpio/tegra-gpio.h>
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/thermal/tegra124-soctherm.h>

#include "skeleton.dtsi"

@@ -724,6 +725,53 @@
status = "disabled";
};

+ thermal-zones {
+ cpu {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors =
+ <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>;
+ };
+
+ mem {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors =
+ <&soctherm TEGRA124_SOCTHERM_SENSOR_MEM>;
+ };
+
+ gpu {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors =
+ <&soctherm TEGRA124_SOCTHERM_SENSOR_GPU>;
+ };
+
+ pllx {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors =
+ <&soctherm TEGRA124_SOCTHERM_SENSOR_PLLX>;
+ };
+ };
+
+ soctherm: soctherm@0,700e2000 {
+ compatible = "nvidia,tegra124-soctherm";
+ reg = <0x0 0x700e2000 0x0 0x1000>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+ <&tegra_car TEGRA124_CLK_SOC_THERM>;
+ clock-names = "tsensor", "soctherm";
+ resets = <&tegra_car 78>;
+ reset-names = "soctherm";
+
+ #thermal-sensor-cells = <1>;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
--
1.8.1.5

2014-06-27 08:12:39

by Mikko Perttunen

[permalink] [raw]
Subject: [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1

This adds critical trip points to the Jetson TK1 device tree.
The device will do a controlled shutdown when either the CPU, GPU
or MEM thermal zone reaches 101 degrees Celsius.

Signed-off-by: Mikko Perttunen <[email protected]>
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 32 +++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 16082c0..c319443 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1825,4 +1825,36 @@
<&tegra_car TEGRA124_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+ thermal-zones {
+ cpu {
+ trips {
+ cpu-critical {
+ temperature = <101000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ mem {
+ trips {
+ mem-critical {
+ temperature = <101000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu {
+ trips {
+ gpu-critical {
+ temperature = <101000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ };
};
--
1.8.1.5

2014-06-27 08:12:50

by Mikko Perttunen

[permalink] [raw]
Subject: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver

This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. This initial driver supports
the four thermal zones with hardware-tracked trip points.

Signed-off-by: Mikko Perttunen <[email protected]>
---
drivers/thermal/Kconfig | 7 +
drivers/thermal/Makefile | 1 +
drivers/thermal/tegra_soctherm.c | 553 +++++++++++++++++++++++++++++++++++++++
3 files changed, 561 insertions(+)
create mode 100644 drivers/thermal/tegra_soctherm.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f9a1386..cdd1f05 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -175,6 +175,13 @@ config ARMADA_THERMAL
Enable this option if you want to have support for thermal management
controller present in Armada 370 and Armada XP SoC.

+config TEGRA_SOCTHERM
+ bool "Tegra SOCTHERM thermal management"
+ depends on ARCH_TEGRA
+ help
+ Enable this option for integrated thermal management support on NVIDIA
+ Tegra124 systems-on-chip.
+
config DB8500_CPUFREQ_COOLING
tristate "DB8500 cpufreq cooling"
depends on ARCH_U8500
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index de0636a..d5d964b 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
obj-$(CONFIG_INTEL_SOC_DTS_THERMAL) += intel_soc_dts_thermal.o
obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/
obj-$(CONFIG_ACPI_INT3403_THERMAL) += int3403_thermal.o
+obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o
diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
new file mode 100644
index 0000000..41e4dcf
--- /dev/null
+++ b/drivers/thermal/tegra_soctherm.c
@@ -0,0 +1,553 @@
+/*
+ * drivers/thermal/tegra_soctherm.c
+ *
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author:
+ * Mikko Perttunen <[email protected]>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+#include <linux/thermal.h>
+#include <linux/tegra-soc.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+
+#define SENSOR_CONFIG0 0
+#define SENSOR_CONFIG0_STOP BIT(0)
+#define SENSOR_CONFIG0_TALL_SHIFT 8
+#define SENSOR_CONFIG0_TCALC_OVER BIT(4)
+#define SENSOR_CONFIG0_OVER BIT(3)
+#define SENSOR_CONFIG0_CPTR_OVER BIT(2)
+#define SENSOR_CONFIG1 4
+#define SENSOR_CONFIG1_TSAMPLE_SHIFT 0
+#define SENSOR_CONFIG1_TIDDQ_EN_SHIFT 15
+#define SENSOR_CONFIG1_TEN_COUNT_SHIFT 24
+#define SENSOR_CONFIG1_TEMP_ENABLE BIT(31)
+#define SENSOR_CONFIG2 8
+#define SENSOR_CONFIG2_THERMA_SHIFT 16
+#define SENSOR_CONFIG2_THERMB_SHIFT 0
+
+#define THERMCTL_LEVEL0_GROUP_CPU 0x0
+#define THERMCTL_LEVEL0_GROUP_EN BIT(8)
+#define THERMCTL_LEVEL0_GROUP_DN_THRESH_SHIFT 9
+#define THERMCTL_LEVEL0_GROUP_UP_THRESH_SHIFT 17
+
+#define THERMCTL_INTR_STATUS 0x84
+#define THERMCTL_INTR_EN 0x88
+
+#define SENSOR_PDIV 0x1c0
+#define SENSOR_PDIV_T124 0x8888
+#define SENSOR_HOTSPOT_OFF 0x1c4
+#define SENSOR_HOTSPOT_OFF_T124 0x00060600
+#define SENSOR_TEMP1 0x1c8
+#define SENSOR_TEMP1_CPU_TEMP_SHIFT 16
+#define SENSOR_TEMP1_GPU_TEMP_MASK 0xffff
+#define SENSOR_TEMP2 0x1cc
+#define SENSOR_TEMP2_MEM_TEMP_SHIFT 16
+#define SENSOR_TEMP2_PLLX_TEMP_MASK 0xffff
+
+#define FUSE_TSENSOR8_CALIB 0x180
+#define FUSE_SPARE_REALIGNMENT_REG_0 0x1fc
+
+#define NOMINAL_CALIB_FT_T124 105
+
+struct tegra_tsensor_configuration {
+ u32 tall, tsample, tiddq_en, ten_count;
+ u32 pdiv, tsample_ate, pdiv_ate;
+};
+
+struct tegra_tsensor {
+ const char *name;
+ u32 base;
+ struct tegra_tsensor_configuration *config;
+ u32 calib_fuse_offset;
+ s32 fuse_corr_alpha, fuse_corr_beta;
+};
+
+struct tegra_thermctl_zone {
+ struct tegra_soctherm *tegra;
+ int sensor;
+};
+
+static struct tegra_tsensor_configuration t124_tsensor_config = {
+ .tall = 16300,
+ .tsample = 120,
+ .tiddq_en = 1,
+ .ten_count = 1,
+ .pdiv = 8,
+ .tsample_ate = 481,
+ .pdiv_ate = 8
+};
+
+static struct tegra_tsensor t124_tsensors[] = {
+ {
+ .base = 0xc0,
+ .name = "cpu0",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x098,
+ .fuse_corr_alpha = 1135400,
+ .fuse_corr_beta = -6266900,
+ },
+ {
+ .base = 0xe0,
+ .name = "cpu1",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x084,
+ .fuse_corr_alpha = 1122220,
+ .fuse_corr_beta = -5700700,
+ },
+ {
+ .base = 0x100,
+ .name = "cpu2",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x088,
+ .fuse_corr_alpha = 1127000,
+ .fuse_corr_beta = -6768200,
+ },
+ {
+ .base = 0x120,
+ .name = "cpu3",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x12c,
+ .fuse_corr_alpha = 1110900,
+ .fuse_corr_beta = -6232000,
+ },
+ {
+ .base = 0x140,
+ .name = "mem0",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x158,
+ .fuse_corr_alpha = 1122300,
+ .fuse_corr_beta = -5936400,
+ },
+ {
+ .base = 0x160,
+ .name = "mem1",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x15c,
+ .fuse_corr_alpha = 1145700,
+ .fuse_corr_beta = -7124600,
+ },
+ {
+ .base = 0x180,
+ .name = "gpu",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x154,
+ .fuse_corr_alpha = 1120100,
+ .fuse_corr_beta = -6000500,
+ },
+ {
+ .base = 0x1a0,
+ .name = "pllx",
+ .config = &t124_tsensor_config,
+ .calib_fuse_offset = 0x160,
+ .fuse_corr_alpha = 1106500,
+ .fuse_corr_beta = -6729300,
+ },
+ { .name = NULL },
+};
+
+static int t124_thermctl_shifts[] = {
+/* CPU MEM GPU PLLX */
+ 8, 24, 16, 0
+};
+
+struct tegra_soctherm {
+ struct reset_control *reset;
+ struct clk *clock_tsensor;
+ struct clk *clock_soctherm;
+ void __iomem *regs;
+
+ struct thermal_zone_device *thermctl_tzs[4];
+};
+
+struct tsensor_shared_calibration {
+ u32 base_cp, base_ft;
+ u32 actual_temp_cp, actual_temp_ft;
+};
+
+static int calculate_shared_calibration(struct tsensor_shared_calibration *r)
+{
+ u32 val;
+ u32 shifted_cp, shifted_ft;
+ int err;
+
+ err = tegra_fuse_readl(FUSE_TSENSOR8_CALIB, &val);
+ if (err)
+ return err;
+ r->base_cp = val & 0x3ff;
+ r->base_ft = (val & (0x7ff << 10)) >> 10;
+
+ err = tegra_fuse_readl(FUSE_SPARE_REALIGNMENT_REG_0, &val);
+ if (err)
+ return err;
+ /* Sign extend from 6 bits to 32 bits */
+ shifted_cp = (s32)((val & 0x1f) | ((val & 0x20) ? 0xffffffe0 : 0x0));
+ val = ((val & (0x1f << 21)) >> 21);
+ /* Sign extend from 5 bits to 32 bits */
+ shifted_ft = (s32)((val & 0xf) | ((val & 0x10) ? 0xfffffff0 : 0x0));
+
+ r->actual_temp_cp = 2 * 25 + shifted_cp;
+ r->actual_temp_ft = 2 * NOMINAL_CALIB_FT_T124 + shifted_ft;
+
+ return 0;
+}
+
+static int calculate_tsensor_calibration(
+ struct tegra_tsensor *sensor,
+ struct tsensor_shared_calibration shared,
+ u32 *calib
+)
+{
+ u32 val;
+ s32 actual_tsensor_ft, actual_tsensor_cp;
+ s32 delta_sens, delta_temp;
+ s32 mult, div;
+ s16 therma, thermb;
+ int err;
+
+ err = tegra_fuse_readl(sensor->calib_fuse_offset, &val);
+ if (err)
+ return err;
+
+ /* Sign extend from 13 bits to 32 bits */
+ actual_tsensor_cp = (shared.base_cp * 64) +
+ (s32)((val & 0xfff) | ((val & 0x1000) ? 0xfffff000 : 0x0));
+ val = (val & (0x1fff << 13)) >> 13;
+ /* Sign extend from 13 bits to 32 bits */
+ actual_tsensor_ft = (shared.base_ft * 32) +
+ (s32)((val & 0xfff) | ((val & 0x1000) ? 0xfffff000 : 0x0));
+
+ delta_sens = actual_tsensor_ft - actual_tsensor_cp;
+ delta_temp = shared.actual_temp_ft - shared.actual_temp_cp;
+
+ mult = sensor->config->pdiv * sensor->config->tsample_ate;
+ div = sensor->config->tsample * sensor->config->pdiv_ate;
+
+ therma = div_s64((s64) delta_temp * (1LL << 13) * mult,
+ (s64) delta_sens * div);
+ thermb = div_s64(((s64) actual_tsensor_ft * shared.actual_temp_cp) -
+ ((s64) actual_tsensor_cp * shared.actual_temp_ft),
+ (s64) delta_sens);
+
+ therma = div_s64((s64) therma * sensor->fuse_corr_alpha,
+ (s64) 1000000LL);
+ thermb = div_s64((s64) thermb * sensor->fuse_corr_alpha +
+ sensor->fuse_corr_beta,
+ (s64) 1000000LL);
+
+ *calib = ((u16)(therma) << SENSOR_CONFIG2_THERMA_SHIFT) |
+ ((u16)thermb << SENSOR_CONFIG2_THERMB_SHIFT);
+
+ return 0;
+}
+
+static int enable_tsensor(struct tegra_soctherm *tegra,
+ struct tegra_tsensor *sensor,
+ struct tsensor_shared_calibration shared)
+{
+ void * __iomem base = tegra->regs + sensor->base;
+ unsigned int val;
+ u32 calib;
+ int err;
+
+ err = calculate_tsensor_calibration(sensor, shared, &calib);
+ if (err)
+ return err;
+
+ val = 0;
+ val |= sensor->config->tall << SENSOR_CONFIG0_TALL_SHIFT;
+ writel(val, base + SENSOR_CONFIG0);
+
+ val = 0;
+ val |= (sensor->config->tsample - 1) << SENSOR_CONFIG1_TSAMPLE_SHIFT;
+ val |= sensor->config->tiddq_en << SENSOR_CONFIG1_TIDDQ_EN_SHIFT;
+ val |= sensor->config->ten_count << SENSOR_CONFIG1_TEN_COUNT_SHIFT;
+ val |= SENSOR_CONFIG1_TEMP_ENABLE;
+ writel(val, base + SENSOR_CONFIG1);
+
+ writel(calib, base + SENSOR_CONFIG2);
+
+ return 0;
+}
+
+static inline long translate_temp(u32 val)
+{
+ long t;
+
+ t = ((val & 0xff00) >> 8) * 1000;
+ if (val & 0x80)
+ t += 500;
+ if (val & 0x01)
+ t *= -1;
+
+ return t;
+}
+
+static int tegra_thermctl_get_temp(void *data, long *out_temp)
+{
+ struct tegra_thermctl_zone *zone = data;
+ u32 val;
+
+ switch (zone->sensor) {
+ case 0:
+ val = readl(zone->tegra->regs + SENSOR_TEMP1)
+ >> SENSOR_TEMP1_CPU_TEMP_SHIFT;
+ break;
+ case 1:
+ val = readl(zone->tegra->regs + SENSOR_TEMP2)
+ >> SENSOR_TEMP2_MEM_TEMP_SHIFT;
+ break;
+ case 2:
+ val = readl(zone->tegra->regs + SENSOR_TEMP1)
+ & SENSOR_TEMP1_GPU_TEMP_MASK;
+ break;
+ case 3:
+ val = readl(zone->tegra->regs + SENSOR_TEMP2)
+ & SENSOR_TEMP2_PLLX_TEMP_MASK;
+ break;
+ default:
+ BUG();
+ return -EINVAL;
+ }
+
+ *out_temp = translate_temp(val);
+
+ return 0;
+}
+
+static int tegra_thermctl_set_trips(void *data, long low, long high)
+{
+ struct tegra_thermctl_zone *zone = data;
+ u32 val;
+
+ low /= 1000;
+ high /= 1000;
+
+ low = clamp_val(low, -127, 127);
+ high = clamp_val(high, -127, 127);
+
+ val = 0;
+ val |= ((u8) low) << THERMCTL_LEVEL0_GROUP_DN_THRESH_SHIFT;
+ val |= ((u8) high) << THERMCTL_LEVEL0_GROUP_UP_THRESH_SHIFT;
+ val |= THERMCTL_LEVEL0_GROUP_EN;
+
+ writel(val, zone->tegra->regs +
+ THERMCTL_LEVEL0_GROUP_CPU + zone->sensor * 4);
+
+ return 0;
+}
+
+static irqreturn_t soctherm_isr(int irq, void *dev_id)
+{
+ struct tegra_thermctl_zone *zone = dev_id;
+ u32 val;
+ u32 intr_mask = 0x03 << t124_thermctl_shifts[zone->sensor];
+
+ val = readl(zone->tegra->regs + THERMCTL_INTR_STATUS);
+
+ if ((val & intr_mask) == 0)
+ return IRQ_NONE;
+
+ writel(val & intr_mask, zone->tegra->regs + THERMCTL_INTR_STATUS);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t soctherm_isr_thread(int irq, void *dev_id)
+{
+ struct tegra_thermctl_zone *zone = dev_id;
+
+ thermal_zone_device_update(zone->tegra->thermctl_tzs[zone->sensor]);
+
+ return IRQ_HANDLED;
+}
+
+static struct of_device_id tegra_soctherm_of_match[] = {
+ { .compatible = "nvidia,tegra124-soctherm" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_soctherm_of_match);
+
+static int tegra_soctherm_probe(struct platform_device *pdev)
+{
+ struct tegra_soctherm *tegra;
+ struct thermal_zone_device *tz;
+ struct tsensor_shared_calibration shared_calib;
+ int i;
+ int err = 0;
+ int irq;
+
+ struct tegra_tsensor *tsensors = t124_tsensors;
+
+ tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
+ if (!tegra)
+ return -ENOMEM;
+
+ tegra->regs = devm_ioremap_resource(&pdev->dev,
+ platform_get_resource(pdev, IORESOURCE_MEM, 0));
+ if (IS_ERR(tegra->regs)) {
+ dev_err(&pdev->dev, "can't get registers");
+ return PTR_ERR(tegra->regs);
+ }
+
+ tegra->reset = devm_reset_control_get(&pdev->dev, "soctherm");
+ if (IS_ERR(tegra->reset)) {
+ dev_err(&pdev->dev, "can't get soctherm reset\n");
+ return PTR_ERR(tegra->reset);
+ }
+
+ tegra->clock_tsensor = devm_clk_get(&pdev->dev, "tsensor");
+ if (IS_ERR(tegra->clock_tsensor)) {
+ dev_err(&pdev->dev, "can't get clock tsensor\n");
+ return PTR_ERR(tegra->clock_tsensor);
+ }
+
+ tegra->clock_soctherm = devm_clk_get(&pdev->dev, "soctherm");
+ if (IS_ERR(tegra->clock_soctherm)) {
+ dev_err(&pdev->dev, "can't get clock soctherm\n");
+ return PTR_ERR(tegra->clock_soctherm);
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq <= 0) {
+ dev_err(&pdev->dev, "can't get interrupt\n");
+ return -EINVAL;
+ }
+
+ reset_control_assert(tegra->reset);
+
+ err = clk_prepare_enable(tegra->clock_soctherm);
+ if (err) {
+ reset_control_deassert(tegra->reset);
+ return err;
+ }
+
+ err = clk_prepare_enable(tegra->clock_tsensor);
+ if (err) {
+ clk_disable_unprepare(tegra->clock_soctherm);
+ reset_control_deassert(tegra->reset);
+ return err;
+ }
+
+ reset_control_deassert(tegra->reset);
+
+ /* Initialize raw sensors */
+
+ err = calculate_shared_calibration(&shared_calib);
+ if (err)
+ goto disable_clocks;
+
+ for (i = 0; tsensors[i].name; ++i) {
+ err = enable_tsensor(tegra, tsensors + i, shared_calib);
+ if (err)
+ goto disable_clocks;
+ }
+
+ writel(SENSOR_PDIV_T124, tegra->regs + SENSOR_PDIV);
+ writel(SENSOR_HOTSPOT_OFF_T124, tegra->regs + SENSOR_HOTSPOT_OFF);
+
+ /* Wait for sensor data to be ready */
+ usleep_range(1000, 5000);
+
+ /* Initialize thermctl sensors */
+
+ for (i = 0; i < 4; ++i) {
+ struct tegra_thermctl_zone *zone =
+ devm_kzalloc(&pdev->dev, sizeof(*zone), GFP_KERNEL);
+ if (!zone) {
+ err = -ENOMEM;
+ goto unregister_tzs;
+ }
+
+ zone->sensor = i;
+ zone->tegra = tegra;
+
+ tz = thermal_zone_of_sensor_register(
+ &pdev->dev, i, zone, tegra_thermctl_get_temp, NULL,
+ tegra_thermctl_set_trips);
+ if (IS_ERR(tz)) {
+ err = PTR_ERR(tz);
+ dev_err(&pdev->dev, "failed to register sensor: %d\n",
+ err);
+ --i;
+ goto unregister_tzs;
+ }
+
+ tegra->thermctl_tzs[i] = tz;
+
+ err = devm_request_threaded_irq(&pdev->dev, irq, soctherm_isr,
+ soctherm_isr_thread,
+ IRQF_SHARED, "tegra_soctherm",
+ zone);
+ if (err) {
+ dev_err(&pdev->dev, "unable to register isr: %d\n",
+ err);
+ goto unregister_tzs;
+ }
+
+ writel(0x3 << t124_thermctl_shifts[i],
+ tegra->regs + THERMCTL_INTR_EN);
+ }
+
+ return 0;
+
+unregister_tzs:
+ for (; i >= 0; i--)
+ thermal_zone_of_sensor_unregister(&pdev->dev,
+ tegra->thermctl_tzs[i]);
+
+disable_clocks:
+ clk_disable_unprepare(tegra->clock_tsensor);
+ clk_disable_unprepare(tegra->clock_soctherm);
+
+ return err;
+}
+
+static int tegra_soctherm_remove(struct platform_device *pdev)
+{
+ struct tegra_soctherm *tegra = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(tegra->thermctl_tzs); ++i) {
+ thermal_zone_of_sensor_unregister(&pdev->dev,
+ tegra->thermctl_tzs[i]);
+ }
+
+ clk_disable_unprepare(tegra->clock_tsensor);
+ clk_disable_unprepare(tegra->clock_soctherm);
+
+ return 0;
+}
+
+static struct platform_driver tegra_soctherm_driver = {
+ .probe = tegra_soctherm_probe,
+ .remove = tegra_soctherm_remove,
+ .driver = {
+ .name = "tegra_soctherm",
+ .owner = THIS_MODULE,
+ .of_match_table = tegra_soctherm_of_match,
+ },
+};
+module_platform_driver(tegra_soctherm_driver);
+
+MODULE_AUTHOR("Mikko Perttunen <[email protected]>");
+MODULE_DESCRIPTION("Tegra SOCTHERM thermal management driver");
+MODULE_LICENSE("GPL v2");
--
1.8.1.5

2014-06-27 08:13:20

by Mikko Perttunen

[permalink] [raw]
Subject: [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table

This adds the two clocks, soctherm and tsensor, to the T124 initialization table.
They are required for soctherm-based thermal sensing.

Signed-off-by: Mikko Perttunen <[email protected]>
---
Peter, one more zero for TSENSOR, please :)
drivers/clk/tegra/clk-tegra124.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index 80efe51..abeec63 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -1369,6 +1369,8 @@ static struct tegra_clk_init_table init_table[] __initdata = {
{TEGRA124_CLK_XUSB_HS_SRC, TEGRA124_CLK_PLL_U_60M, 60000000, 0},
{TEGRA124_CLK_XUSB_FALCON_SRC, TEGRA124_CLK_PLL_RE_OUT, 224000000, 0},
{TEGRA124_CLK_XUSB_HOST_SRC, TEGRA124_CLK_PLL_RE_OUT, 112000000, 0},
+ {TEGRA124_CLK_SOC_THERM, TEGRA124_CLK_PLL_P, 51000000, 0},
+ {TEGRA124_CLK_TSENSOR, TEGRA124_CLK_CLK_M, 400000, 0},
/* This MUST be the last entry. */
{TEGRA124_CLK_CLK_MAX, TEGRA124_CLK_CLK_MAX, 0, 0},
};
--
1.8.1.5

2014-06-27 08:14:24

by Mikko Perttunen

[permalink] [raw]
Subject: [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm

This adds binding documentation and headers for the Tegra124
SOCTHERM device tree node.

Signed-off-by: Mikko Perttunen <[email protected]>
---
.../devicetree/bindings/thermal/tegra-soctherm.txt | 32 ++++++++++++++++++++++
include/dt-bindings/thermal/tegra124-soctherm.h | 15 ++++++++++
2 files changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
create mode 100644 include/dt-bindings/thermal/tegra124-soctherm.h

diff --git a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
new file mode 100644
index 0000000..dc5588e
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
@@ -0,0 +1,32 @@
+Tegra124 SOCTHERM thermal management system
+
+Required properties :
+- compatible : "nvidia,tegra124-soctherm".
+- reg : Should contain 1 entry:
+ - SOCTHERM register set
+- interrupts : Defines the interrupt used by SOCTHERM
+- clocks : Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+ - tsensor
+ - soctherm
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+ - soctherm
+- #thermal-sensor-cells : For thermctl sensors. Should be 1.
+
+Example :
+
+ soctherm@0,700e2000 {
+ compatible = "nvidia,tegra124-soctherm";
+ reg = <0x0 0x700e2000 0x0 0x1000>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+ <&tegra_car TEGRA124_CLK_SOC_THERM>;
+ clock-names = "tsensor", "soctherm";
+ resets = <&tegra_car 78>;
+ reset-names = "soctherm";
+
+ #thermal-sensor-cells = <1>;
+ };
diff --git a/include/dt-bindings/thermal/tegra124-soctherm.h b/include/dt-bindings/thermal/tegra124-soctherm.h
new file mode 100644
index 0000000..cbef15d
--- /dev/null
+++ b/include/dt-bindings/thermal/tegra124-soctherm.h
@@ -0,0 +1,15 @@
+/*
+ * This header provides constants for binding nvidia,tegra124-soctherm.
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_TEGRA124_SOCTHERM_H
+#define _DT_BINDINGS_THERMAL_TEGRA124_SOCTHERM_H
+
+#define TEGRA124_SOCTHERM_SENSOR_CPU 0
+#define TEGRA124_SOCTHERM_SENSOR_MEM 1
+#define TEGRA124_SOCTHERM_SENSOR_GPU 2
+#define TEGRA124_SOCTHERM_SENSOR_PLLX 3
+
+#endif
+
+
--
1.8.1.5

2014-06-27 12:18:38

by Peter De Schrijver

[permalink] [raw]
Subject: Re: [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table

On Fri, Jun 27, 2014 at 10:11:38AM +0200, Mikko Perttunen wrote:
> This adds the two clocks, soctherm and tsensor, to the T124 initialization table.
> They are required for soctherm-based thermal sensing.
>
> Signed-off-by: Mikko Perttunen <[email protected]>
> ---
> Peter, one more zero for TSENSOR, please :)

Ah :) I will take this into clk-tegra-3.17

Cheers,

Peter.

2014-06-30 20:40:49

by Stephen Warren

[permalink] [raw]
Subject: Re: [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm

On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
> This adds binding documentation and headers for the Tegra124
> SOCTHERM device tree node.

> diff --git a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt

> +Required properties :
...
> +- #thermal-sensor-cells : For thermctl sensors. Should be 1.

I'd prefer a tiny bit more information here: A link to whatever other
document defines the meaning of #thermal-sensor-cells, and a link to the
header that defines the meaning of the data in the cell. Perhaps:

#thermal-sensor-cells : Should be 1. See ./thermal.txt for a description
of this property. See <dt-bindings/thermal/tegra124-soctherm.h> for a
list of valid values.

> diff --git a/include/dt-bindings/thermal/tegra124-soctherm.h b/include/dt-bindings/thermal/tegra124-soctherm.h
> +#endif
> +
> +

There are a couple of blank lines at the end of that file.

2014-06-30 20:45:34

by Stephen Warren

[permalink] [raw]
Subject: Re: [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1

On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
> This adds critical trip points to the Jetson TK1 device tree.
> The device will do a controlled shutdown when either the CPU, GPU
> or MEM thermal zone reaches 101 degrees Celsius.

It would be more typical to order the patches with changes to
tegra124.dtsi first, then changes to board files (that build on the core
SoC support) second.

> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts

> + thermal-zones {
> + cpu {
> + trips {
> + cpu-critical {

Can we name that simply "critical"? DT node names are supposed to
represent type of object more than identity of object. Even "critical"
is a bit of an identity, and "trip@0" would be better, but I imagine the
core thermal DT bindings precluded that?

2014-06-30 20:48:37

by Stephen Warren

[permalink] [raw]
Subject: Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree

On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
> This adds the soctherm thermal sensing and management unit to the
> Tegra124 device tree along with the four thermal zones it exports.

> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi

> + thermal-zones {
> + cpu {
> + polling-delay-passive = <0>;
> + polling-delay = <0>;

I think we should still define a polling delay so that if there's SW
that doesn't support HW trip points/interrupts, it still knows how often
it should reasonably check the sensor.

Perhaps a delay of 0 is used to determine whether to use HW trip points
vs polling (I haven't read patch 1 yet)? If so, I'd prefer not to do
that. Rather, the driver should advertize its ability to provide HW trip
points, and it would be up to the core to then make use of them. The DT
should just describe the HW, not assume it can influence SW's choice of
whether to use HW trip points.

> + soctherm: soctherm@0,700e2000 {
...
> + reset-names = "soctherm";
> +
> + #thermal-sensor-cells = <1>;

I don't see any real need for that blank line. If there was, there would
probably be more blank lines in the big list of properties above.

2014-06-30 21:08:29

by Stephen Warren

[permalink] [raw]
Subject: Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points

On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
> 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 sensor driver
> callback `set_trips' is then called with the temperatures.
> If there is no trip point above or below the current temperature,
> the passed trip temperature will be LONG_MAX or LONG_MIN 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 the `set_trips' callback is not implemented (is NULL), the framework
> behaves as before.

Is there no "core thermal" code? I would have expected this new feature
to be implemented in "core" code rather than of/dt "support" code.
Perhaps there would also be some additions to the of/dt code, but I'd
still expect the bulk of the feature to be complete independant of
of/dt. Systems still using board files or ACPI or ... would surely
benefit from this too?

> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c

> +static int of_thermal_set_trips(struct thermal_zone_device *tz, long temp)

s/tz/tzd/ or s/tz/tzdev/ ? Since "tz" says "thermal zone" to me, but
it's actually a "thermal zone device".

> + struct __thermal_zone *data = tz->devdata;

s/data/tz/ ? "data" is a rather generic term, and "tz" seems like a good
abbreviation for a __thermal_zone.

> + for (i = 0; i < data->ntrips; ++i) {
> + struct __thermal_trip *trip = data->trips + i;
> + long trip_low = trip->temperature - trip->hysteresis;
> +
> + if (trip_low < temp && trip_low > low)
> + low = trip_low;
> +
> + if (trip->temperature > temp && trip->temperature < high)
> + high = trip->temperature;
> + }

That seems to always apply hysteresis to the low end of a trip object.
Don't you need to apply the hysteresis to either the low or high end of
the range, depending on whether the temperature is currently below/above
the range, and hence which direction the edge will be crossed?

Similar comments elsewhere. Perhaps the patch is consistent with some
existing confusing naming style though?

> +static int of_thermal_update_trips(struct thermal_zone_device *tz)
> +{
> + long temp;
> + int err;
> +
> + err = of_thermal_get_temp(tz, &temp);
> + if (err)
> + return err;
> +
> + err = of_thermal_set_trips(tz, temp);

Doesn't this patch modify of_thermal_get_temp() to call
of_thermal_set_trips() itself?

> @@ -384,7 +467,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
> struct thermal_zone_device *
> thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
> void *data, int (*get_temp)(void *, long *),
> - int (*get_trend)(void *, long *))
> + int (*get_trend)(void *, long *),
> + int (*set_trips)(void *, long, long))

Passing in a struct containing fields for all the ops seem better than
forever extending this function with more and more function pointers.

2014-06-30 21:23:09

by Stephen Warren

[permalink] [raw]
Subject: Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver

On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
> This adds support for the Tegra SOCTHERM thermal sensing and management
> system found in the Tegra124 system-on-chip. This initial driver supports
> the four thermal zones with hardware-tracked trip points.

> diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c

> +static struct tegra_tsensor t124_tsensors[] = {
> + {
> + .base = 0xc0,
> + .name = "cpu0",
> + .config = &t124_tsensor_config,
> + .calib_fuse_offset = 0x098,
> + .fuse_corr_alpha = 1135400,
> + .fuse_corr_beta = -6266900,
> + },

I wonder why some of those fields are named "fuse_xxx" when the values
are hard-coded in these tables rather than read from fuses? These values
don't seem to be used to adjust values read from fuses.

> +static int tegra_thermctl_get_temp(void *data, long *out_temp)

> + switch (zone->sensor) {
> + case 0:
> + val = readl(zone->tegra->regs + SENSOR_TEMP1)
> + >> SENSOR_TEMP1_CPU_TEMP_SHIFT;

Can't the register offset and shift be stored in *zone, so that this
whole switch can be replaced with something generic:

val = readl(zone->tegra->regs + zone->reg_offset) >> zone->value_shift;

> +static int tegra_soctherm_probe(struct platform_device *pdev)

> + irq = platform_get_irq(pdev, 0);
> + if (irq <= 0) {
> + dev_err(&pdev->dev, "can't get interrupt\n");
> + return -EINVAL;
> + }

irq is assigned once here ... (see later)

> + for (i = 0; i < 4; ++i) {

Why "4"? Should the loop count be the ARRAY_SIZE(some array)? At the
very least, a named constant that describes the value would be useful...

> + err = devm_request_threaded_irq(&pdev->dev, irq, soctherm_isr,
> + soctherm_isr_thread,
> + IRQF_SHARED, "tegra_soctherm",
> + zone);

Why request the same IRQ 4 times here. Rather, shouldn't the IRQ be
requested once, and the ISR simply loop over the status register (or
whatever there are 4 of)?

2014-07-01 07:27:43

by Mikko Perttunen

[permalink] [raw]
Subject: Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points

Inline.

On 01/07/14 00:08, Stephen Warren wrote:
> On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
>> 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 sensor driver
>> callback `set_trips' is then called with the temperatures.
>> If there is no trip point above or below the current temperature,
>> the passed trip temperature will be LONG_MAX or LONG_MIN 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 the `set_trips' callback is not implemented (is NULL), the framework
>> behaves as before.
>
> Is there no "core thermal" code? I would have expected this new feature
> to be implemented in "core" code rather than of/dt "support" code.
> Perhaps there would also be some additions to the of/dt code, but I'd
> still expect the bulk of the feature to be complete independant of
> of/dt. Systems still using board files or ACPI or ... would surely
> benefit from this too?

The thermal core only supports a fixed number of trip points for each
driver and the core informs the driver of any changes to those, so
drivers using the core framework can already have hardware trip points,
but just a fixed number of them.

The way of-thermal works, is it reads all the trip points from the
device tree, registers a new thermal_zone_device with that number of
trip points and then handles the trip points completely independently.
Of course, if we're just polling, this is fine, since the thermal core
also knows about those trip points and will trigger cooling when polling
the each zone. However, the driver doesn't, so it cannot setup any
interrupts to call thermal_zone_device_update.

>
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>
>> +static int of_thermal_set_trips(struct thermal_zone_device *tz, long temp)
>
> s/tz/tzd/ or s/tz/tzdev/ ? Since "tz" says "thermal zone" to me, but
> it's actually a "thermal zone device".

I followed the existing convention; "tz" is the name used most often by
both the core and the of-thermal framework.

>
>> + struct __thermal_zone *data = tz->devdata;
>
> s/data/tz/ ? "data" is a rather generic term, and "tz" seems like a good
> abbreviation for a __thermal_zone.

Same, though here both "data" and "tz" seem to be used..

>
>> + for (i = 0; i < data->ntrips; ++i) {
>> + struct __thermal_trip *trip = data->trips + i;
>> + long trip_low = trip->temperature - trip->hysteresis;
>> +
>> + if (trip_low < temp && trip_low > low)
>> + low = trip_low;
>> +
>> + if (trip->temperature > temp && trip->temperature < high)
>> + high = trip->temperature;
>> + }
>
> That seems to always apply hysteresis to the low end of a trip object.
> Don't you need to apply the hysteresis to either the low or high end of
> the range, depending on whether the temperature is currently below/above
> the range, and hence which direction the edge will be crossed?

I believe applying only to the low end is correct. Say that we have a
trip point at 40C and hysteresis of 2C. When we exceed 40C cooling will
start immediately, but it will only be stopped when we cool down to 38C.
At that point there is again a 2C gap between the current temperature
and the trip point. It would seem that this is the interpretation used
by our downstream kernel and also some people on the Internet (however
trustworthy they may be..)

If you don't feel this is right, please elaborate.

>
> Similar comments elsewhere. Perhaps the patch is consistent with some
> existing confusing naming style though?
>
>> +static int of_thermal_update_trips(struct thermal_zone_device *tz)
>> +{
>> + long temp;
>> + int err;
>> +
>> + err = of_thermal_get_temp(tz, &temp);
>> + if (err)
>> + return err;
>> +
>> + err = of_thermal_set_trips(tz, temp);
>
> Doesn't this patch modify of_thermal_get_temp() to call
> of_thermal_set_trips() itself?

You're right. I suppose this function is unneeded.

>
>> @@ -384,7 +467,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
>> struct thermal_zone_device *
>> thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
>> void *data, int (*get_temp)(void *, long *),
>> - int (*get_trend)(void *, long *))
>> + int (*get_trend)(void *, long *),
>> + int (*set_trips)(void *, long, long))
>
> Passing in a struct containing fields for all the ops seem better than
> forever extending this function with more and more function pointers.
>

Very true.

2014-07-01 07:49:53

by Mikko Perttunen

[permalink] [raw]
Subject: Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree

Inline.

On 30/06/14 23:48, Stephen Warren wrote:
> On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
>> This adds the soctherm thermal sensing and management unit to the
>> Tegra124 device tree along with the four thermal zones it exports.
>
>> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
>
>> + thermal-zones {
>> + cpu {
>> + polling-delay-passive = <0>;
>> + polling-delay = <0>;
>
> I think we should still define a polling delay so that if there's SW
> that doesn't support HW trip points/interrupts, it still knows how often
> it should reasonably check the sensor.
>
> Perhaps a delay of 0 is used to determine whether to use HW trip points
> vs polling (I haven't read patch 1 yet)? If so, I'd prefer not to do
> that. Rather, the driver should advertize its ability to provide HW trip
> points, and it would be up to the core to then make use of them. The DT
> should just describe the HW, not assume it can influence SW's choice of
> whether to use HW trip points.

Yes, a delay of 0 disables polling in the thermal core. (The hw trip
code doesn't do anything with it) One way to fix this would be to export
a rate changing function in the thermal core and have of-thermal set the
polling rate to 0 or the value from device tree depending on if hw trip
point programming succeeded or not. This would also be good for error
handling, since if hw trip poing programming failed for whatever reason,
we could still fall back to polling.

>
>> + soctherm: soctherm@0,700e2000 {
> ...
>> + reset-names = "soctherm";
>> +
>> + #thermal-sensor-cells = <1>;
>
> I don't see any real need for that blank line. If there was, there would
> probably be more blank lines in the big list of properties above.
>

The reasoning was that #thermal-sensor-cells as a cells-property is a
bit different from the rest, so separate them. But I can remove the
blank line just as well.

2014-07-01 08:06:36

by Mikko Perttunen

[permalink] [raw]
Subject: Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver

Inline.

On 01/07/14 00:23, Stephen Warren wrote:
> On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
>> This adds support for the Tegra SOCTHERM thermal sensing and management
>> system found in the Tegra124 system-on-chip. This initial driver supports
>> the four thermal zones with hardware-tracked trip points.
>
>> diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
>
>> +static struct tegra_tsensor t124_tsensors[] = {
>> + {
>> + .base = 0xc0,
>> + .name = "cpu0",
>> + .config = &t124_tsensor_config,
>> + .calib_fuse_offset = 0x098,
>> + .fuse_corr_alpha = 1135400,
>> + .fuse_corr_beta = -6266900,
>> + },
>
> I wonder why some of those fields are named "fuse_xxx" when the values
> are hard-coded in these tables rather than read from fuses? These values
> don't seem to be used to adjust values read from fuses.

They are used to when calculating the thermal calibration in
calculate_tsensor_calibration, which is based on the value read from the
fuse. Downstream calls them fuse correction values, so I kept that. (I
guess the meaning of corr might not be obvious..) On downstream there is
another set of these correction values used depending on the fuse
revision, but I believe the older revision is only found internally.

>
>> +static int tegra_thermctl_get_temp(void *data, long *out_temp)
>
>> + switch (zone->sensor) {
>> + case 0:
>> + val = readl(zone->tegra->regs + SENSOR_TEMP1)
>> + >> SENSOR_TEMP1_CPU_TEMP_SHIFT;
>
> Can't the register offset and shift be stored in *zone, so that this
> whole switch can be replaced with something generic:
>
> val = readl(zone->tegra->regs + zone->reg_offset) >> zone->value_shift;

Yes, certainly doable.

>
>> +static int tegra_soctherm_probe(struct platform_device *pdev)
>
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq <= 0) {
>> + dev_err(&pdev->dev, "can't get interrupt\n");
>> + return -EINVAL;
>> + }
>
> irq is assigned once here ... (see later)
>
>> + for (i = 0; i < 4; ++i) {
>
> Why "4"? Should the loop count be the ARRAY_SIZE(some array)? At the
> very least, a named constant that describes the value would be useful...

The thermctl sensors have been unchanged for a few chip generations, so
I was thinking that just hardcoding this wouldn't be so bad. But I guess
an array would look nicer here. Will fix.

>
>> + err = devm_request_threaded_irq(&pdev->dev, irq, soctherm_isr,
>> + soctherm_isr_thread,
>> + IRQF_SHARED, "tegra_soctherm",
>> + zone);
>
> Why request the same IRQ 4 times here. Rather, shouldn't the IRQ be
> requested once, and the ISR simply loop over the status register (or
> whatever there are 4 of)?
>

I had that variant as well, but since we need to pass the list of
tripped sensors to soctherm_isr_thread somehow, I guess some kind of
locking or atomic is needed. This version doesn't need that, so I went
with it.

2014-07-01 18:16:03

by Stephen Warren

[permalink] [raw]
Subject: Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points

On 07/01/2014 01:27 AM, Mikko Perttunen wrote:
> Inline.
>
> On 01/07/14 00:08, Stephen Warren wrote:
>> On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
>>> 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 sensor driver
>>> callback `set_trips' is then called with the temperatures.
>>> If there is no trip point above or below the current temperature,
>>> the passed trip temperature will be LONG_MAX or LONG_MIN 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 the `set_trips' callback is not implemented (is NULL), the framework
>>> behaves as before.
>>
>> Is there no "core thermal" code? I would have expected this new feature
>> to be implemented in "core" code rather than of/dt "support" code.
>> Perhaps there would also be some additions to the of/dt code, but I'd
>> still expect the bulk of the feature to be complete independant of
>> of/dt. Systems still using board files or ACPI or ... would surely
>> benefit from this too?
>
> The thermal core only supports a fixed number of trip points for each
> driver and the core informs the driver of any changes to those, so
> drivers using the core framework can already have hardware trip points,
> but just a fixed number of them.
>
> The way of-thermal works, is it reads all the trip points from the
> device tree, registers a new thermal_zone_device with that number of
> trip points and then handles the trip points completely independently.
> Of course, if we're just polling, this is fine, since the thermal core
> also knows about those trip points and will trigger cooling when polling
> the each zone. However, the driver doesn't, so it cannot setup any
> interrupts to call thermal_zone_device_update.

Is there any possibility of cleaning that up? It's obviously horribly
inconsistent if core driver functionality works completely differently
simply because the list of trip-points comes from DT rather than a
static table in the driver. of_thermal should be limited to DT parsing
and related device instantiation/lookup, not introducing a completely
different functionality model.

>>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c

>>> + for (i = 0; i < data->ntrips; ++i) {
>>> + struct __thermal_trip *trip = data->trips + i;
>>> + long trip_low = trip->temperature - trip->hysteresis;
>>> +
>>> + if (trip_low < temp && trip_low > low)
>>> + low = trip_low;
>>> +
>>> + if (trip->temperature > temp && trip->temperature < high)
>>> + high = trip->temperature;
>>> + }
>>
>> That seems to always apply hysteresis to the low end of a trip object.
>> Don't you need to apply the hysteresis to either the low or high end of
>> the range, depending on whether the temperature is currently below/above
>> the range, and hence which direction the edge will be crossed?
>
> I believe applying only to the low end is correct. Say that we have a
> trip point at 40C and hysteresis of 2C. When we exceed 40C cooling will
> start immediately, but it will only be stopped when we cool down to 38C.
> At that point there is again a 2C gap between the current temperature
> and the trip point. It would seem that this is the interpretation used
> by our downstream kernel and also some people on the Internet (however
> trustworthy they may be..)
>
> If you don't feel this is right, please elaborate.

Ah, the point I was missing is that each trip point is a single
temperature, not a temperature range. As such, the code in your patch is
correct.

2014-07-01 18:26:48

by Stephen Warren

[permalink] [raw]
Subject: Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver

On 07/01/2014 02:06 AM, Mikko Perttunen wrote:
> Inline.
>
> On 01/07/14 00:23, Stephen Warren wrote:
>> On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
>>> This adds support for the Tegra SOCTHERM thermal sensing and management
>>> system found in the Tegra124 system-on-chip. This initial driver
>>> supports
>>> the four thermal zones with hardware-tracked trip points.
>>
>>> diff --git a/drivers/thermal/tegra_soctherm.c
>>> b/drivers/thermal/tegra_soctherm.c
>>
>>> +static struct tegra_tsensor t124_tsensors[] = {
>>> + {
>>> + .base = 0xc0,
>>> + .name = "cpu0",
>>> + .config = &t124_tsensor_config,
>>> + .calib_fuse_offset = 0x098,
>>> + .fuse_corr_alpha = 1135400,
>>> + .fuse_corr_beta = -6266900,
>>> + },
>>
>> I wonder why some of those fields are named "fuse_xxx" when the values
>> are hard-coded in these tables rather than read from fuses? These values
>> don't seem to be used to adjust values read from fuses.
>
> They are used to when calculating the thermal calibration in
> calculate_tsensor_calibration, which is based on the value read from the
> fuse. Downstream calls them fuse correction values, so I kept that. (I
> guess the meaning of corr might not be obvious..) On downstream there is
> another set of these correction values used depending on the fuse
> revision, but I believe the older revision is only found internally.

Ah, so there's some manufacturing calibration process that sets some
fuse value, and the HW uses a combination of that fuse value, and some
parameters of the manufacturing process as represented by the
SENSOR_CONFIG2 register, to apply the calibration? I wonder why
SENSOR_CONFIG2 is a register not a fuse in that case, but anyway...

Perhaps some comments or kerneldoc in the definition of struct
tegra_tsensor would be useful?

I did notice some inconsistency in bracketing at:

> + *calib = ((u16)(therma) << SENSOR_CONFIG2_THERMA_SHIFT) |
> + ((u16)thermb << SENSOR_CONFIG2_THERMB_SHIFT);

>>> + err = devm_request_threaded_irq(&pdev->dev, irq, soctherm_isr,
>>> + soctherm_isr_thread,
>>> + IRQF_SHARED, "tegra_soctherm",
>>> + zone);
>>
>> Why request the same IRQ 4 times here. Rather, shouldn't the IRQ be
>> requested once, and the ISR simply loop over the status register (or
>> whatever there are 4 of)?
>
> I had that variant as well, but since we need to pass the list of
> tripped sensors to soctherm_isr_thread somehow, I guess some kind of
> locking or atomic is needed. This version doesn't need that, so I went
> with it.

Why not read THERMCTL_INTR_STATUS inside the IRQ thread. IIRC, if the
ISR wakes an IRQ thread, the interrupt remains disable until the thread
has run its course, so there's no issue deferring the register read
until the thread runs, at which point, the thread can simply loop over
all the sensors.

2014-07-01 23:48:18

by Tuomas Tynkkynen

[permalink] [raw]
Subject: Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver

On 27/06/14 11:11, Mikko Perttunen wrote:
> + /* Sign extend from 6 bits to 32 bits */
> + shifted_cp = (s32)((val & 0x1f) | ((val & 0x20) ? 0xffffffe0 : 0x0));
> + val = ((val & (0x1f << 21)) >> 21);
> + /* Sign extend from 5 bits to 32 bits */
> + shifted_ft = (s32)((val & 0xf) | ((val & 0x10) ? 0xfffffff0 : 0x0));

There's sign_extend32 in bitops.h

2014-07-03 13:51:37

by Mikko Perttunen

[permalink] [raw]
Subject: Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver



On 01/07/14 21:26, Stephen Warren wrote:
>
> Ah, so there's some manufacturing calibration process that sets some
> fuse value, and the HW uses a combination of that fuse value, and some
> parameters of the manufacturing process as represented by the
> SENSOR_CONFIG2 register, to apply the calibration? I wonder why
> SENSOR_CONFIG2 is a register not a fuse in that case, but anyway...
>
> Perhaps some comments or kerneldoc in the definition of struct
> tegra_tsensor would be useful?

Yes, I'll add some comments.

>
> Why not read THERMCTL_INTR_STATUS inside the IRQ thread. IIRC, if the
> ISR wakes an IRQ thread, the interrupt remains disable until the thread
> has run its course, so there's no issue deferring the register read
> until the thread runs, at which point, the thread can simply loop over
> all the sensors.
>

If that's the case, then that's definitely a better way to do it.

2014-07-03 14:15:47

by Mikko Perttunen

[permalink] [raw]
Subject: Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points

On 01/07/14 21:15, Stephen Warren wrote:
>> The thermal core only supports a fixed number of trip points for each
>> driver and the core informs the driver of any changes to those, so
>> drivers using the core framework can already have hardware trip points,
>> but just a fixed number of them.
>>
>> The way of-thermal works, is it reads all the trip points from the
>> device tree, registers a new thermal_zone_device with that number of
>> trip points and then handles the trip points completely independently.
>> Of course, if we're just polling, this is fine, since the thermal core
>> also knows about those trip points and will trigger cooling when polling
>> the each zone. However, the driver doesn't, so it cannot setup any
>> interrupts to call thermal_zone_device_update.
>
> Is there any possibility of cleaning that up? It's obviously horribly
> inconsistent if core driver functionality works completely differently
> simply because the list of trip-points comes from DT rather than a
> static table in the driver. of_thermal should be limited to DT parsing
> and related device instantiation/lookup, not introducing a completely
> different functionality model.

I guess the smallest possible change would be to add a
#hardware-trip-cells property to the thermal driver node (this would
need to designate both the thermal zone and the trip point) and a
hardware-trip-point phandle node to trip points. Then trip points could
point to a hardware trip point that would get programmed. Since this is
just adding properties, it would be backwards-compatible as well.
This is starting to sound like a good idea. Will have to give think
about it some more.

2014-07-04 08:42:35

by Wei Ni

[permalink] [raw]
Subject: Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver

On 06/27/2014 04:11 PM, Mikko Perttunen wrote:
> This adds support for the Tegra SOCTHERM thermal sensing and management
> system found in the Tegra124 system-on-chip. This initial driver supports
> the four thermal zones with hardware-tracked trip points.

> diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c

> +static int calculate_shared_calibration(struct tsensor_shared_calibration *r)
> +{
> + u32 val;
> + u32 shifted_cp, shifted_ft;
> + int err;
> +
> + err = tegra_fuse_readl(FUSE_TSENSOR8_CALIB, &val);
> + if (err)
> + return err;
> + r->base_cp = val & 0x3ff;
> + r->base_ft = (val & (0x7ff << 10)) >> 10;
> +
> + err = tegra_fuse_readl(FUSE_SPARE_REALIGNMENT_REG_0, &val);
> + if (err)
> + return err;
> + /* Sign extend from 6 bits to 32 bits */
> + shifted_cp = (s32)((val & 0x1f) | ((val & 0x20) ? 0xffffffe0 : 0x0));
> + val = ((val & (0x1f << 21)) >> 21);
> + /* Sign extend from 5 bits to 32 bits */
> + shifted_ft = (s32)((val & 0xf) | ((val & 0x10) ? 0xfffffff0 : 0x0));
> +
> + r->actual_temp_cp = 2 * 25 + shifted_cp;
Do we need to define the "25" as constant, just like below line.

> + r->actual_temp_ft = 2 * NOMINAL_CALIB_FT_T124 + shifted_ft;
> +
> + return 0;
> +}

> +
> +static irqreturn_t soctherm_isr(int irq, void *dev_id)
> +{
> + struct tegra_thermctl_zone *zone = dev_id;
> + u32 val;
> + u32 intr_mask = 0x03 << t124_thermctl_shifts[zone->sensor];
> +
> + val = readl(zone->tegra->regs + THERMCTL_INTR_STATUS);
> +
> + if ((val & intr_mask) == 0)
> + return IRQ_NONE;
> +
> + writel(val & intr_mask, zone->tegra->regs + THERMCTL_INTR_STATUS);
I think we need to disable the interrupt here, and enable it again after
updating the high/low limited values. If not, there will trigger mass of
interrupts.

> +
> +static struct platform_driver tegra_soctherm_driver = {
> + .probe = tegra_soctherm_probe,
> + .remove = tegra_soctherm_remove,
> + .driver = {
> + .name = "tegra_soctherm",
> + .owner = THIS_MODULE,
> + .of_match_table = tegra_soctherm_of_match,
> + },
> +};
Will you consider to add suspend/resume support?

Thanks.
Wei.

2014-07-04 11:52:55

by Mikko Perttunen

[permalink] [raw]
Subject: Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver

On 04/07/14 11:43, Wei Ni wrote:
> On 06/27/2014 04:11 PM, Mikko Perttunen wrote:
>> This adds support for the Tegra SOCTHERM thermal sensing and management
>> system found in the Tegra124 system-on-chip. This initial driver supports
>> the four thermal zones with hardware-tracked trip points.
>
>> diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
>
>> +static int calculate_shared_calibration(struct tsensor_shared_calibration *r)
>> +{
>> + u32 val;
>> + u32 shifted_cp, shifted_ft;
>> + int err;
>> +
>> + err = tegra_fuse_readl(FUSE_TSENSOR8_CALIB, &val);
>> + if (err)
>> + return err;
>> + r->base_cp = val & 0x3ff;
>> + r->base_ft = (val & (0x7ff << 10)) >> 10;
>> +
>> + err = tegra_fuse_readl(FUSE_SPARE_REALIGNMENT_REG_0, &val);
>> + if (err)
>> + return err;
>> + /* Sign extend from 6 bits to 32 bits */
>> + shifted_cp = (s32)((val & 0x1f) | ((val & 0x20) ? 0xffffffe0 : 0x0));
>> + val = ((val & (0x1f << 21)) >> 21);
>> + /* Sign extend from 5 bits to 32 bits */
>> + shifted_ft = (s32)((val & 0xf) | ((val & 0x10) ? 0xfffffff0 : 0x0));
>> +
>> + r->actual_temp_cp = 2 * 25 + shifted_cp;
> Do we need to define the "25" as constant, just like below line.

I believe downstream just uses "25" which is the reason I used it, but
yes, a constant would be nicer.

>
>> + r->actual_temp_ft = 2 * NOMINAL_CALIB_FT_T124 + shifted_ft;
>> +
>> + return 0;
>> +}
>
>> +
>> +static irqreturn_t soctherm_isr(int irq, void *dev_id)
>> +{
>> + struct tegra_thermctl_zone *zone = dev_id;
>> + u32 val;
>> + u32 intr_mask = 0x03 << t124_thermctl_shifts[zone->sensor];
>> +
>> + val = readl(zone->tegra->regs + THERMCTL_INTR_STATUS);
>> +
>> + if ((val & intr_mask) == 0)
>> + return IRQ_NONE;
>> +
>> + writel(val & intr_mask, zone->tegra->regs + THERMCTL_INTR_STATUS);
> I think we need to disable the interrupt here, and enable it again after
> updating the high/low limited values. If not, there will trigger mass of
> interrupts.
>

Good point. It works now because of-thermal will set up the new trip
points during soctherm_thread_isr, and apparently the interrupt is kept
disabled until after that.

>> +
>> +static struct platform_driver tegra_soctherm_driver = {
>> + .probe = tegra_soctherm_probe,
>> + .remove = tegra_soctherm_remove,
>> + .driver = {
>> + .name = "tegra_soctherm",
>> + .owner = THIS_MODULE,
>> + .of_match_table = tegra_soctherm_of_match,
>> + },
>> +};
> Will you consider to add suspend/resume support?

I guess for this one it should be simple; same driver probe and teardown
as normally. Although currently suspend doesn't support LP0 so no-op is
enough.

>
> Thanks.
> Wei.
>

Thanks

2014-07-21 07:42:38

by Zhang, Rui

[permalink] [raw]
Subject: Re: [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver

Hi, Eduardo,

what do you think of this patch set?

thanks,
rui

On Fri, 2014-06-27 at 11:11 +0300, Mikko Perttunen wrote:
> Hi everyone,
>
> this series adds support for hardware-tracked thermal trip points
> for the device tree thermal framework and introduces a new Tegra124 thermal
> driver that uses them.
>
> Hardware-tracked trip points are trip points that do not need to be polled;
> the hardware gives an interrupt when the trip point is reached. The device
> tree thermal framework has not previously given the sensor driver any
> information about set trip points, so using these has been impossible.
> This series adds a new callback from of-thermal to the driver to allow telling
> the driver about trip points. The driver only needs to track two trip points,
> the framework ensures that the current temperature lies between those two.
> Behavior for drivers that do not include this callback is unchanged.
>
> The Tegra124 SOCTHERM thermal driver that is included exposes four thermal zones
> (the thermctl thermal zones) with hardware-tracked trip point support. While the
> hardware supports four tracked trip points, only one is used.
>
> Mikko Perttunen (6):
> thermal: of: Add support for hardware-tracked trip points
> of: Add bindings for nvidia,tegra124-soctherm
> ARM: tegra: Add thermal trip points for Jetson TK1
> ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree
> clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table
> thermal: Add Tegra SOCTHERM thermal management driver
>
> .../devicetree/bindings/thermal/tegra-soctherm.txt | 32 ++
> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 32 ++
> arch/arm/boot/dts/tegra124.dtsi | 48 ++
> drivers/clk/tegra/clk-tegra124.c | 2 +
> drivers/thermal/Kconfig | 7 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/of-thermal.c | 97 +++-
> drivers/thermal/tegra_soctherm.c | 553 +++++++++++++++++++++
> include/dt-bindings/thermal/tegra124-soctherm.h | 15 +
> include/linux/thermal.h | 3 +-
> 10 files changed, 785 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
> create mode 100644 drivers/thermal/tegra_soctherm.c
> create mode 100644 include/dt-bindings/thermal/tegra124-soctherm.h
>

2014-07-21 23:12:58

by Matt Longnecker

[permalink] [raw]
Subject: Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree

On 6/27/2014 1:11 AM, Mikko Perttunen wrote:
> This adds the soctherm thermal sensing and management unit to the
> Tegra124 device tree along with the four thermal zones it exports.

Mikko, soctherm doesn't "export thermal zones". I would rewrite your
desription like this:

Extend the Tegra124 device tree by adding the soctherm thermal
sensing and management unit and by defining four thermal zones --
one for each temperature sensor in soctherm.

System integrators have some flexibility in deciding how many thermal
zones to define for their platform. For example, an integrator could
define a single zone for the entire Tegra chip (giving a simple system
at runtime) or with multiple zones (giving potentially higher
performance near thermal limits). That's why I don't like the
implication that soctherm dictates the existence of particular thermal
zones.

-Matt

2014-07-21 23:20:07

by Matt Longnecker

[permalink] [raw]
Subject: Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree

On 6/27/2014 1:11 AM, Mikko Perttunen wrote:
> This adds the soctherm thermal sensing and management unit to the
> Tegra124 device tree along with the four thermal zones it exports.

Mikko, soctherm doesn't "export thermal zones". I would rewrite your
desription like this:

Extend the Tegra124 device tree by adding the soctherm thermal
sensing and management unit and by defining four thermal zones --
one for each temperature sensor in soctherm.

System integrators have some flexibility in deciding how many thermal
zones to define for their platform. For example, an integrator could
define a single zone for the entire Tegra chip (giving a simple system
at runtime) or with multiple zones (giving potentially higher
performance near thermal limits). That's why I don't like the
implication that soctherm dictates the existence of particular thermal
zones.

-Matt

2014-07-30 14:16:55

by Eduardo Valentin

[permalink] [raw]
Subject: Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points

Terve Mikko,

On Fri, Jun 27, 2014 at 11:11:34AM +0300, Mikko Perttunen wrote:
> 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 sensor driver

One thing I don't follow on your proposal is the groundings you need to
'set_trips' whenever temperature changes. Given your intention is to add
support to interrupt driven devices, shouldn't we 'set_trips' just when
we cross the previously set trips range?

> callback `set_trips' is then called with the temperatures.
> If there is no trip point above or below the current temperature,
> the passed trip temperature will be LONG_MAX or LONG_MIN 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 the `set_trips' callback is not implemented (is NULL), the framework
> behaves as before.

As already mentioned by swarren, the proposal must be wider. We shall
keep the same support in case the device is used in a system without
device tree. In other words, if you want to see extra functionality for
interrupt driven devices, you shall update the core part too, and draft
a common messaging path.

In general, interrupt driven devices are not mapped in the current
thermal framework. That is, the current code is timer interrupt driven.
Other interrupt updates from devices are propagated to
the framework using thermal_zone_device_update(). In other words, you would
reprogram your hardware trips from your interrupt handler/workqueue then
just let the framework know what is going on with temperature, via a simple
thermal_zone_device_update().

The way I see this going forward it would be a common interface to
configure the thermal zones to be monitored:
a. via polling only
b. via interrupt only
c. both a + b

obviously, the above shall be informative only for userland.

keep in mind also that changing interrupt configuration for high and low
temperature thresholds can be racy.

This feature was kept in the TODO list of the of-thermal.c because the
we lack a proper support from the thermal framework (never came out of
the TODO list, I know, I apologize for this). And this missing feature
was spotted by the hwmon folks also, as they do have such support. So,
the major missing improvements on interrupt driven devices shall come in
three steps: (i) thermal framework, (ii) of-thermal (iii) thermal
framework and hwmon interface.


Cheers,


>
> Signed-off-by: Mikko Perttunen <[email protected]>
> ---
> drivers/thermal/of-thermal.c | 97 ++++++++++++++++++++++++++++++++++++++++++--
> include/linux/thermal.h | 3 +-
> 2 files changed, 95 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 04b1be7..bfccea5 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -89,6 +89,7 @@ struct __thermal_zone {
> /* trip data */
> int ntrips;
> struct __thermal_trip *trips;
> + long prev_low_trip, prev_high_trip;
>
> /* cooling binding data */
> int num_tbps;
> @@ -98,19 +99,66 @@ struct __thermal_zone {
> void *sensor_data;
> int (*get_temp)(void *, long *);
> int (*get_trend)(void *, long *);
> + int (*set_trips)(void *, long, long);
> };
>
> +/*** Automatic trip handling ***/
> +
> +static int of_thermal_set_trips(struct thermal_zone_device *tz, long temp)
> +{
> + struct __thermal_zone *data = tz->devdata;
> + long low = LONG_MIN, high = LONG_MAX;
> + int i;
> +
> + /* Hardware trip points not supported */
> + if (!data->set_trips)
> + return 0;
> +
> + /* No need to change trip points */
> + if (temp > data->prev_low_trip && temp < data->prev_high_trip)
> + return 0;
> +
> + for (i = 0; i < data->ntrips; ++i) {
> + struct __thermal_trip *trip = data->trips + i;
> + long trip_low = trip->temperature - trip->hysteresis;
> +
> + if (trip_low < temp && trip_low > low)
> + low = trip_low;
> +
> + if (trip->temperature > temp && trip->temperature < high)
> + high = trip->temperature;
> + }
> +
> + dev_dbg(&tz->device,
> + "temperature %ld, updating trip points to %ld, %ld\n",
> + temp, low, high);
> +
> + data->prev_low_trip = low;
> + data->prev_high_trip = high;
> +
> + return data->set_trips(data->sensor_data, low, high);
> +}
> +
> /*** DT thermal zone device callbacks ***/
>
> static int of_thermal_get_temp(struct thermal_zone_device *tz,
> unsigned long *temp)
> {
> struct __thermal_zone *data = tz->devdata;
> + int err;
>
> if (!data->get_temp)
> return -EINVAL;
>
> - return data->get_temp(data->sensor_data, temp);
> + err = data->get_temp(data->sensor_data, temp);
> + if (err)
> + return err;
> +
> + err = of_thermal_set_trips(tz, *temp);

Here, if you update trips whenever you get_temp, you are possibly
reprogramming your trips on every poll. Remember, this function will be
called on every poll, in the current implementation.

> + if (err)
> + return err;
> +
> + return 0;
> }
>
> static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
> @@ -222,6 +270,22 @@ static int of_thermal_set_mode(struct thermal_zone_device *tz,
> return 0;
> }
>
> +static int of_thermal_update_trips(struct thermal_zone_device *tz)
> +{
> + long temp;
> + int err;
> +
> + err = of_thermal_get_temp(tz, &temp);
> + if (err)
> + return err;
> +
> + err = of_thermal_set_trips(tz, temp);
> + if (err)
> + return err;
> +
> + return 0;
> +}
> +
> static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
> enum thermal_trip_type *type)
> {
> @@ -252,6 +316,7 @@ static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
> unsigned long temp)
> {
> struct __thermal_zone *data = tz->devdata;
> + int err;
>
> if (trip >= data->ntrips || trip < 0)
> return -EDOM;
> @@ -259,6 +324,10 @@ static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
> /* thermal framework should take care of data->mask & (1 << trip) */
> data->trips[trip].temperature = temp;
>
> + err = of_thermal_update_trips(tz);
> + if (err)
> + return err;
> +
> return 0;
> }
>
> @@ -279,6 +348,7 @@ static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
> unsigned long hyst)
> {
> struct __thermal_zone *data = tz->devdata;
> + int err;
>
> if (trip >= data->ntrips || trip < 0)
> return -EDOM;
> @@ -286,6 +356,10 @@ static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
> /* thermal framework should take care of data->mask & (1 << trip) */
> data->trips[trip].hysteresis = hyst;
>
> + err = of_thermal_update_trips(tz);
> + if (err)
> + return err;
> +
> return 0;
> }
>
> @@ -325,10 +399,12 @@ static struct thermal_zone_device *
> thermal_zone_of_add_sensor(struct device_node *zone,
> struct device_node *sensor, void *data,
> int (*get_temp)(void *, long *),
> - int (*get_trend)(void *, long *))
> + int (*get_trend)(void *, long *),
> + int (*set_trips)(void *, long, long))

we need to clean the above arguments. they should become a .ops.

> {
> struct thermal_zone_device *tzd;
> struct __thermal_zone *tz;
> + int err;
>
> tzd = thermal_zone_get_zone_by_name(zone->name);
> if (IS_ERR(tzd))
> @@ -339,8 +415,15 @@ thermal_zone_of_add_sensor(struct device_node *zone,
> mutex_lock(&tzd->lock);
> tz->get_temp = get_temp;
> tz->get_trend = get_trend;
> + tz->set_trips = set_trips;
> tz->sensor_data = data;
>
> + err = of_thermal_update_trips(tzd);
> + if (err) {
> + mutex_unlock(&tzd->lock);
> + return ERR_PTR(err);
> + }
> +
> tzd->ops->get_temp = of_thermal_get_temp;
> tzd->ops->get_trend = of_thermal_get_trend;
> mutex_unlock(&tzd->lock);
> @@ -384,7 +467,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
> struct thermal_zone_device *
> thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
> void *data, int (*get_temp)(void *, long *),
> - int (*get_trend)(void *, long *))
> + int (*get_trend)(void *, long *),
> + int (*set_trips)(void *, long, long))

ditto.

> {
> struct device_node *np, *child, *sensor_np;
>
> @@ -422,7 +506,8 @@ thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
> return thermal_zone_of_add_sensor(child, sensor_np,
> data,
> get_temp,
> - get_trend);
> + get_trend,
> + set_trips);

ditto.

> }
> }
> of_node_put(np);
> @@ -466,6 +551,7 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
>
> tz->get_temp = NULL;
> tz->get_trend = NULL;
> + tz->set_trips = NULL;
> tz->sensor_data = NULL;
> mutex_unlock(&tzd->lock);
> }
> @@ -671,6 +757,9 @@ thermal_of_build_thermal_zone(struct device_node *np)
> /* trips */
> child = of_get_child_by_name(np, "trips");
>
> + tz->prev_high_trip = LONG_MIN;
> + tz->prev_low_trip = LONG_MAX;
> +
> /* No trips provided */
> if (!child)
> goto finish;
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index f7e11c7..2f8951c 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -248,7 +248,8 @@ struct thermal_genl_event {
> struct thermal_zone_device *
> thermal_zone_of_sensor_register(struct device *dev, int id,
> void *data, int (*get_temp)(void *, long *),
> - int (*get_trend)(void *, long *));
> + int (*get_trend)(void *, long *),
> + int (*set_trips)(void *, long, long));
> void thermal_zone_of_sensor_unregister(struct device *dev,
> struct thermal_zone_device *tz);
> #else
> --
> 1.8.1.5
>