* [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang-ral2JQCrhuEAvxtiuMwx3w, edubezval-Re5JQEeQqe8AvxtiuMwx3w, swarren-3lzwWm7+Weoh9ZMKESR00Q, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, mlongnecker-DDmLM1+adcrQT0dZR+AlfA Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-27 8:11 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-06-27 8:11 ` Mikko Perttunen @ 2014-06-30 21:08 ` Stephen Warren -1 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 21:08 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang, edubezval, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-06-30 21:08 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 21:08 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-06-30 21:08 ` Stephen Warren @ 2014-07-01 7:27 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-01 7:27 UTC (permalink / raw) To: Stephen Warren, rui.zhang@intel.com, edubezval@gmail.com, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-07-01 7:27 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-01 7:27 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-07-01 7:27 ` Mikko Perttunen @ 2014-07-01 18:15 ` Stephen Warren -1 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-07-01 18:15 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang@intel.com, edubezval@gmail.com, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-07-01 18:15 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-07-01 18:15 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-07-01 18:15 ` Stephen Warren @ 2014-07-03 14:15 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-03 14:15 UTC (permalink / raw) To: Stephen Warren, rui.zhang@intel.com, edubezval@gmail.com, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-07-03 14:15 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-03 14:15 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-07-01 18:15 ` Stephen Warren (?) (?) @ 2014-07-21 23:53 ` Matthew Longnecker -1 siblings, 0 replies; 72+ messages in thread From: Matthew Longnecker @ 2014-07-21 23:53 UTC (permalink / raw) To: linux-pm; +Cc: linux-tegra, linux-kernel, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-06-27 8:11 ` Mikko Perttunen @ 2014-07-30 14:16 ` Eduardo Valentin -1 siblings, 0 replies; 72+ messages in thread From: Eduardo Valentin @ 2014-07-30 14:16 UTC (permalink / raw) To: Mikko Perttunen Cc: rui.zhang, swarren, thierry.reding, pdeschrijver, mlongnecker, linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-07-30 14:16 ` Eduardo Valentin 0 siblings, 0 replies; 72+ messages in thread From: Eduardo Valentin @ 2014-07-30 14:16 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-07-30 14:16 ` Eduardo Valentin (?) @ 2014-08-01 11:42 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-08-01 11:42 UTC (permalink / raw) To: Eduardo Valentin Cc: rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Peter De Schrijver, Matthew Longnecker, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org 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 >> > ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-08-01 11:42 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-08-01 11:42 UTC (permalink / raw) To: Eduardo Valentin Cc: rui.zhang@intel.com, swarren@wwwdotorg.org, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker, linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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@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 >> > ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-08-01 11:42 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-08-01 11:42 UTC (permalink / raw) To: linux-arm-kernel 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@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 >> > ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <53DB7D0D.1070508-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points 2014-08-01 11:42 ` Mikko Perttunen (?) @ 2014-08-01 13:15 ` edubezval at gmail.com -1 siblings, 0 replies; 72+ messages in thread From: edubezval-Re5JQEeQqe8AvxtiuMwx3w @ 2014-08-01 13:15 UTC (permalink / raw) To: Mikko Perttunen Cc: rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Peter De Schrijver, Matthew Longnecker, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-08-01 13:15 ` edubezval at gmail.com 0 siblings, 0 replies; 72+ messages in thread From: edubezval @ 2014-08-01 13:15 UTC (permalink / raw) To: Mikko Perttunen Cc: rui.zhang@intel.com, swarren@wwwdotorg.org, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker, linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Moro, On Fri, Aug 1, 2014 at 7:42 AM, Mikko Perttunen <mperttunen@nvidia.com> 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@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 >>> >> > -- Eduardo Bezerra Valentin ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points @ 2014-08-01 13:15 ` edubezval at gmail.com 0 siblings, 0 replies; 72+ messages in thread From: edubezval at gmail.com @ 2014-08-01 13:15 UTC (permalink / raw) To: linux-arm-kernel Moro, On Fri, Aug 1, 2014 at 7:42 AM, Mikko Perttunen <mperttunen@nvidia.com> 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@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 >>> >> > -- Eduardo Bezerra Valentin ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-27 8:11 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-tegra, Mikko Perttunen, linux-kernel, linux-arm-kernel, linux-pm 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
[parent not found: <1403856699-2140-3-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-30 20:40 ` Stephen Warren -1 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:40 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang-ral2JQCrhuEAvxtiuMwx3w, edubezval-Re5JQEeQqe8AvxtiuMwx3w, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, mlongnecker-DDmLM1+adcrQT0dZR+AlfA Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm @ 2014-06-30 20:40 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:40 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang, edubezval, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm @ 2014-06-30 20:40 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:40 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-27 8:11 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-tegra, Mikko Perttunen, linux-kernel, linux-arm-kernel, linux-pm 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1 @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1 @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1 2014-06-27 8:11 ` Mikko Perttunen @ 2014-06-30 20:45 ` Stephen Warren -1 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:45 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang, edubezval, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1 @ 2014-06-30 20:45 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:45 UTC (permalink / raw) To: linux-arm-kernel 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 at 0" would be better, but I imagine the core thermal DT bindings precluded that? ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-27 8:11 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
[parent not found: <1403856699-2140-5-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-30 20:48 ` Stephen Warren -1 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:48 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang-ral2JQCrhuEAvxtiuMwx3w, edubezval-Re5JQEeQqe8AvxtiuMwx3w, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, mlongnecker-DDmLM1+adcrQT0dZR+AlfA Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree @ 2014-06-30 20:48 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:48 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang, edubezval, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree @ 2014-06-30 20:48 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 20:48 UTC (permalink / raw) To: linux-arm-kernel 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 at 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree 2014-06-30 20:48 ` Stephen Warren @ 2014-07-01 7:49 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-01 7:49 UTC (permalink / raw) To: Stephen Warren, rui.zhang@intel.com, edubezval@gmail.com, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree @ 2014-07-01 7:49 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-01 7:49 UTC (permalink / raw) To: linux-arm-kernel 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 at 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree 2014-06-27 8:11 ` Mikko Perttunen ` (2 preceding siblings ...) (?) @ 2014-07-21 23:12 ` Matthew Longnecker -1 siblings, 0 replies; 72+ messages in thread From: Matthew Longnecker @ 2014-07-21 23:12 UTC (permalink / raw) To: linux-kernel; +Cc: linux-pm, linux-tegra, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-07-21 23:13 ` Matthew Longnecker -1 siblings, 0 replies; 72+ messages in thread From: Matthew Longnecker @ 2014-07-21 23:13 UTC (permalink / raw) Cc: linux-tegra, linux-kernel, linux-arm-kernel, linux-pm 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree @ 2014-07-21 23:13 ` Matthew Longnecker 0 siblings, 0 replies; 72+ messages in thread From: Matthew Longnecker @ 2014-07-21 23:13 UTC (permalink / raw) To: linux-kernel; +Cc: linux-pm, linux-tegra, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree @ 2014-07-21 23:13 ` Matthew Longnecker 0 siblings, 0 replies; 72+ messages in thread From: Matthew Longnecker @ 2014-07-21 23:13 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <1403856699-2140-1-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-27 8:11 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang-ral2JQCrhuEAvxtiuMwx3w, edubezval-Re5JQEeQqe8AvxtiuMwx3w, swarren-3lzwWm7+Weoh9ZMKESR00Q, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, mlongnecker-DDmLM1+adcrQT0dZR+AlfA Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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@nvidia.com> --- 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: linux-arm-kernel 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 :) 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table 2014-06-27 8:11 ` Mikko Perttunen @ 2014-06-27 12:18 ` Peter De Schrijver -1 siblings, 0 replies; 72+ messages in thread From: Peter De Schrijver @ 2014-06-27 12:18 UTC (permalink / raw) To: Mikko Perttunen Cc: rui.zhang@intel.com, edubezval@gmail.com, swarren@wwwdotorg.org, thierry.reding@gmail.com, Matthew Longnecker, linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table @ 2014-06-27 12:18 ` Peter De Schrijver 0 siblings, 0 replies; 72+ messages in thread From: Peter De Schrijver @ 2014-06-27 12:18 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-06-27 8:11 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-06-27 8:11 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-06-27 8:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-06-27 8:11 ` Mikko Perttunen @ 2014-06-30 21:23 ` Stephen Warren -1 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 21:23 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang, edubezval, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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)? ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-06-30 21:23 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-06-30 21:23 UTC (permalink / raw) To: linux-arm-kernel 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)? ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-06-30 21:23 ` Stephen Warren @ 2014-07-01 8:06 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-01 8:06 UTC (permalink / raw) To: Stephen Warren, rui.zhang@intel.com, edubezval@gmail.com, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-01 8:06 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-01 8:06 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <53B26BF2.7090009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-07-01 8:06 ` Mikko Perttunen (?) @ 2014-07-01 18:26 ` Stephen Warren -1 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-07-01 18:26 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Peter De Schrijver, Matthew Longnecker Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-01 18:26 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-07-01 18:26 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang@intel.com, edubezval@gmail.com, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-01 18:26 ` Stephen Warren 0 siblings, 0 replies; 72+ messages in thread From: Stephen Warren @ 2014-07-01 18:26 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-07-01 18:26 ` Stephen Warren @ 2014-07-03 13:51 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-03 13:51 UTC (permalink / raw) To: Stephen Warren, rui.zhang@intel.com, edubezval@gmail.com, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-03 13:51 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-03 13:51 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <1403856699-2140-7-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-06-27 8:11 ` Mikko Perttunen (?) @ 2014-07-01 23:47 ` Tuomas Tynkkynen -1 siblings, 0 replies; 72+ messages in thread From: Tuomas Tynkkynen @ 2014-07-01 23:47 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang-ral2JQCrhuEAvxtiuMwx3w, edubezval-Re5JQEeQqe8AvxtiuMwx3w, swarren-3lzwWm7+Weoh9ZMKESR00Q, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, mlongnecker-DDmLM1+adcrQT0dZR+AlfA Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-01 23:47 ` Tuomas Tynkkynen 0 siblings, 0 replies; 72+ messages in thread From: Tuomas Tynkkynen @ 2014-07-01 23:47 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang, edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker Cc: linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-01 23:47 ` Tuomas Tynkkynen 0 siblings, 0 replies; 72+ messages in thread From: Tuomas Tynkkynen @ 2014-07-01 23:47 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-06-27 8:11 ` Mikko Perttunen @ 2014-07-04 8:43 ` Wei Ni -1 siblings, 0 replies; 72+ messages in thread From: Wei Ni @ 2014-07-04 8:43 UTC (permalink / raw) To: Mikko Perttunen, rui.zhang@intel.com, edubezval@gmail.com, swarren@wwwdotorg.org, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-04 8:43 ` Wei Ni 0 siblings, 0 replies; 72+ messages in thread From: Wei Ni @ 2014-07-04 8:43 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver 2014-07-04 8:43 ` Wei Ni @ 2014-07-04 11:52 ` Mikko Perttunen -1 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-04 11:52 UTC (permalink / raw) To: Wei Ni, rui.zhang@intel.com, edubezval@gmail.com, swarren@wwwdotorg.org, thierry.reding@gmail.com, Peter De Schrijver, Matthew Longnecker Cc: linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver @ 2014-07-04 11:52 ` Mikko Perttunen 0 siblings, 0 replies; 72+ messages in thread From: Mikko Perttunen @ 2014-07-04 11:52 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver 2014-06-27 8:11 ` Mikko Perttunen @ 2014-07-21 7:42 ` Zhang Rui -1 siblings, 0 replies; 72+ messages in thread From: Zhang Rui @ 2014-07-21 7:42 UTC (permalink / raw) To: Mikko Perttunen Cc: edubezval, swarren, thierry.reding, pdeschrijver, mlongnecker, linux-pm, linux-tegra, linux-kernel, linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver @ 2014-07-21 7:42 ` Zhang Rui 0 siblings, 0 replies; 72+ messages in thread From: Zhang Rui @ 2014-07-21 7:42 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 72+ messages in thread
end of thread, other threads:[~2014-08-01 13:15 UTC | newest]
Thread overview: 72+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-27 8:11 [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-30 21:08 ` Stephen Warren
2014-06-30 21:08 ` Stephen Warren
2014-07-01 7:27 ` Mikko Perttunen
2014-07-01 7:27 ` Mikko Perttunen
2014-07-01 18:15 ` Stephen Warren
2014-07-01 18:15 ` Stephen Warren
2014-07-03 14:15 ` Mikko Perttunen
2014-07-03 14:15 ` Mikko Perttunen
2014-07-21 23:53 ` Matthew Longnecker
2014-07-30 14:16 ` Eduardo Valentin
2014-07-30 14:16 ` Eduardo Valentin
2014-08-01 11:42 ` Mikko Perttunen
2014-08-01 11:42 ` Mikko Perttunen
2014-08-01 11:42 ` Mikko Perttunen
[not found] ` <53DB7D0D.1070508-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-01 13:15 ` edubezval-Re5JQEeQqe8AvxtiuMwx3w
2014-08-01 13:15 ` edubezval
2014-08-01 13:15 ` edubezval at gmail.com
2014-06-27 8:11 ` [PATCH 2/6] of: Add bindings for nvidia,tegra124-soctherm Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
[not found] ` <1403856699-2140-3-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-30 20:40 ` Stephen Warren
2014-06-30 20:40 ` Stephen Warren
2014-06-30 20:40 ` Stephen Warren
2014-06-27 8:11 ` [PATCH 3/6] ARM: tegra: Add thermal trip points for Jetson TK1 Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-30 20:45 ` Stephen Warren
2014-06-30 20:45 ` Stephen Warren
2014-06-27 8:11 ` [PATCH 4/6] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
[not found] ` <1403856699-2140-5-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-30 20:48 ` Stephen Warren
2014-06-30 20:48 ` Stephen Warren
2014-06-30 20:48 ` Stephen Warren
2014-07-01 7:49 ` Mikko Perttunen
2014-07-01 7:49 ` Mikko Perttunen
2014-07-21 23:12 ` Matthew Longnecker
2014-07-21 23:13 ` Matthew Longnecker
2014-07-21 23:13 ` Matthew Longnecker
2014-07-21 23:13 ` Matthew Longnecker
[not found] ` <1403856699-2140-1-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-27 8:11 ` [PATCH 5/6] clk: tegra: Add soctherm and tsensor clocks to Tegra124 init table Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 12:18 ` Peter De Schrijver
2014-06-27 12:18 ` Peter De Schrijver
2014-06-27 8:11 ` [PATCH 6/6] thermal: Add Tegra SOCTHERM thermal management driver Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-27 8:11 ` Mikko Perttunen
2014-06-30 21:23 ` Stephen Warren
2014-06-30 21:23 ` Stephen Warren
2014-07-01 8:06 ` Mikko Perttunen
2014-07-01 8:06 ` Mikko Perttunen
[not found] ` <53B26BF2.7090009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-07-01 18:26 ` Stephen Warren
2014-07-01 18:26 ` Stephen Warren
2014-07-01 18:26 ` Stephen Warren
2014-07-03 13:51 ` Mikko Perttunen
2014-07-03 13:51 ` Mikko Perttunen
[not found] ` <1403856699-2140-7-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-07-01 23:47 ` Tuomas Tynkkynen
2014-07-01 23:47 ` Tuomas Tynkkynen
2014-07-01 23:47 ` Tuomas Tynkkynen
2014-07-04 8:43 ` Wei Ni
2014-07-04 8:43 ` Wei Ni
2014-07-04 11:52 ` Mikko Perttunen
2014-07-04 11:52 ` Mikko Perttunen
2014-07-21 7:42 ` [PATCH 0/6] of-thermal hardware trip points + Tegra124 SOCTHERM driver Zhang Rui
2014-07-21 7:42 ` Zhang Rui
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.