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

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

[Mikko Perttunen]

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

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

[Mikko Perttunen]

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 <mperttunen@nvidia.com>
---
 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

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

[Stephen Warren]

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.

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

[Mikko Perttunen]

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.

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

[Stephen Warren]

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.

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

[Mikko Perttunen]

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.

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

[Matthew Longnecker]

On 7/1/2014 11:15 AM, Stephen Warren wrote:
> 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?

Stephen, the "core thermal code" defined two major object types:
  * a thermal zone
  * a cooling device

Each thermal zone corresponds to a physical region in space within a 
device. A sane person might expect there to be one physical temperature 
sensor associated with each zone. But, that's not always the case.

Because the thermal core did not expose the concept of a "sensor" 
separately from a "zone", many drivers which register thermal zones are 
messy -- they include a mix of device driver code (i.e. poking at 
register for a thermal sensor IP block) and device-agnostic code for 
implementing behaviors required of a thermal zone.

of-thermal does more than just parse device tree. It registers thermal 
zones using its own implementation of that device-agnostic code. Having 
that centralized implementation of the thermal zone code allows thermal 
sensor device drivers which talk to of-thermal to be simpler than 
drivers which try to talk directly to the thermal core.

The fact that you need to use DT to make use of the simpler sensor 
driver interface doesn't seem like a good reason to push back on Mikko's 
change.

-Matt

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

[Eduardo Valentin]

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 <mperttunen@nvidia.com>
> ---
>  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
> 

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

[Mikko Perttunen]

Moi Eduardo :)

On 30/07/14 17:16, Eduardo Valentin wrote:
> 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?

I think the reasoning for this was that I didn't want to make changes to 
thermal_core and thermal_zone_device_update only calls get_temp on the 
zone, so I had to add this code to get_temp. set_trips would anyway only 
be called if we had crossed a trip point.

>
>> 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.

Yeah, this is sensible. A simpler solution would be to just tell 
of-thermal drivers about the trip points and let the driver do whatever 
it wants. That would mirror the way normal thermal_core drivers are 
done. What is your opinion on that?

>
> 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.

For now, I think I'll submit a driver with just polling support so that 
we can get some support in.

>
>
> Cheers,
>
>

Thanks, Mikko

>>
>> Signed-off-by: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>>   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
>>
>

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

[edubezval-Re5JQEeQqe8AvxtiuMwx3w]

Moro,

On Fri, Aug 1, 2014 at 7:42 AM, Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Moi Eduardo :)
>
>
> On 30/07/14 17:16, Eduardo Valentin wrote:
>>
>> 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?
>
>
> I think the reasoning for this was that I didn't want to make changes to
> thermal_core and thermal_zone_device_update only calls get_temp on the zone,
> so I had to add this code to get_temp. set_trips would anyway only be called
> if we had crossed a trip point.
>
>

I see.

>>
>>> 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.
>
>
> Yeah, this is sensible. A simpler solution would be to just tell of-thermal
> drivers about the trip points and let the driver do whatever it wants. That
> would mirror the way normal thermal_core drivers are done. What is your
> opinion on that?
>
>

In fact, with the current implementation in the thermal framework,
there is nothing else left than coding the feature in the driver
itself. The framework would know only about the existance of the
trips. This approach would need to be cleaned whenever we write the
fix in the core though.

For this reason, I would prefer to clean the core first, then write
the driver as a proof that the changes in core are properly covering
the existing drivers and interrupt driven drivers.

>>
>> 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.
>
>
> For now, I think I'll submit a driver with just polling support so that we
> can get some support in.


I see. I will be looking into the changes in core. Whenever I have a
working RFC I will share with the list.

Terveydeksi!,

>
>>
>>
>> Cheers,
>>
>>
>
> Thanks, Mikko
>
>
>>>
>>> Signed-off-by: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>   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
>>>
>>
>



-- 
Eduardo Bezerra Valentin

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

[Mikko Perttunen]

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

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
 .../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

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

[Stephen Warren]

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.

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

[Mikko Perttunen]

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 <mperttunen@nvidia.com>
---
 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

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

[Stephen Warren]

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?

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

[Mikko Perttunen]

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 <mperttunen@nvidia.com>
---
 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

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

[Stephen Warren]

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.

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

[Mikko Perttunen]

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.

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

[Matthew Longnecker]

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

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

[Matthew Longnecker]

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

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

[Mikko Perttunen]

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 <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
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

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

[Peter De Schrijver]

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 <mperttunen@nvidia.com>
> ---
> Peter, one more zero for TSENSOR, please :)

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

Cheers,

Peter.

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

[Mikko Perttunen]

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 <mperttunen@nvidia.com>
---
 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 <mperttunen@nvidia.com>
+ *
+ * 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 <mperttunen@nvidia.com>");
+MODULE_DESCRIPTION("Tegra SOCTHERM thermal management driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.1.5

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

[Stephen Warren]

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)?

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

[Mikko Perttunen]

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.

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

[Stephen Warren]

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.

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

[Mikko Perttunen]

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.

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

[Tuomas Tynkkynen]

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

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

[Wei Ni]

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.

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

[Mikko Perttunen]

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

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

[Zhang Rui]

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
>