All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
@ 2013-09-27  3:13 ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

Hello all,

Here is the continuation of work of representing hardware thermal properties
in device tree infrastructure. The present patch series is the fourth version
of this work. Previous versions were sent as RFCs and can be found here:
V3: 
RFCv2: http://lkml.org/lkml/2013/8/23/594
RFCv1: http://lkml.org/lkml/2013/7/22/319

Major difference from V3 is on the parser itself. I have updated the binding
documentation and improved the code accordingly to previous comments mainly
from Mark R. and Joe P.

The changes on hwmon drivers have been accepted by Guenter, and in this
series I am including his Acked-by, as I didn't change anything on that side.

I also found a bug while using all involved code built as modules, thus
I have reworked a bit the cooling device registration part. This is why
there are two new patches in this series (patches 02 and 04).

Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7,
although this series is not including the DRA7 part (I will be sending separately).

Thanks all who have been contributing reviewing this code.

All best,

Eduardo Valentin (18):
  thermal: allow registering without .get_temp
  thermal: core: allow binding via .bind when tzp is present
  thermal: introduce device tree parser
  thermal: core: introduce thermal_of_cooling_device_register
  thermal: cpu_cooling: introduce of_cpufreq_cooling_register
  cpufreq: cpufreq-cpu0: add dt node parsing for cooling device
    properties
  hwmon: lm75: expose to thermal fw via DT nodes
  hwmon: tmp102: expose to thermal fw via DT nodes
  thermal: ti-soc-thermal: use thermal DT infrastructure
  arm: dts: add omap4 CPU thermal data
  arm: dts: add omap4430 thermal data
  arm: dts: add omap4460 thermal data
  arm: dts: add cooling properties on omap4430 cpu node
  arm: dts: add cooling properties on omap4460 cpu node
  arm: dts: add omap5 GPU thermal data
  arm: dts: add omap5 CORE thermal data
  arm: dts: add omap5 thermal data
  arm: dts: add cooling properties on omap5 cpu node

 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   7 +
 .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi           |  41 +
 arch/arm/boot/dts/omap443x.dtsi                    |  15 +-
 arch/arm/boot/dts/omap4460.dtsi                    |  15 +-
 arch/arm/boot/dts/omap5-core-thermal.dtsi          |  28 +
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi           |  28 +
 arch/arm/boot/dts/omap5.dtsi                       |  15 +-
 drivers/cpufreq/Kconfig                            |   2 +-
 drivers/cpufreq/cpufreq-cpu0.c                     |  16 +
 drivers/hwmon/lm75.c                               |  35 +-
 drivers/hwmon/tmp102.c                             |  19 +
 drivers/thermal/Kconfig                            |  14 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/cpu_cooling.c                      |  56 +-
 drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |  79 +-
 drivers/thermal/thermal_core.h                     |   9 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  77 +-
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/cpu_cooling.h                        |  25 +
 include/linux/thermal.h                            |  32 +-
 22 files changed, 1880 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
@ 2013-09-27  3:13 ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren-3lzwWm7+Weoh9ZMKESR00Q, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eduardo Valentin

Hello all,

Here is the continuation of work of representing hardware thermal properties
in device tree infrastructure. The present patch series is the fourth version
of this work. Previous versions were sent as RFCs and can be found here:
V3: 
RFCv2: http://lkml.org/lkml/2013/8/23/594
RFCv1: http://lkml.org/lkml/2013/7/22/319

Major difference from V3 is on the parser itself. I have updated the binding
documentation and improved the code accordingly to previous comments mainly
from Mark R. and Joe P.

The changes on hwmon drivers have been accepted by Guenter, and in this
series I am including his Acked-by, as I didn't change anything on that side.

I also found a bug while using all involved code built as modules, thus
I have reworked a bit the cooling device registration part. This is why
there are two new patches in this series (patches 02 and 04).

Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7,
although this series is not including the DRA7 part (I will be sending separately).

Thanks all who have been contributing reviewing this code.

All best,

Eduardo Valentin (18):
  thermal: allow registering without .get_temp
  thermal: core: allow binding via .bind when tzp is present
  thermal: introduce device tree parser
  thermal: core: introduce thermal_of_cooling_device_register
  thermal: cpu_cooling: introduce of_cpufreq_cooling_register
  cpufreq: cpufreq-cpu0: add dt node parsing for cooling device
    properties
  hwmon: lm75: expose to thermal fw via DT nodes
  hwmon: tmp102: expose to thermal fw via DT nodes
  thermal: ti-soc-thermal: use thermal DT infrastructure
  arm: dts: add omap4 CPU thermal data
  arm: dts: add omap4430 thermal data
  arm: dts: add omap4460 thermal data
  arm: dts: add cooling properties on omap4430 cpu node
  arm: dts: add cooling properties on omap4460 cpu node
  arm: dts: add omap5 GPU thermal data
  arm: dts: add omap5 CORE thermal data
  arm: dts: add omap5 thermal data
  arm: dts: add cooling properties on omap5 cpu node

 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   7 +
 .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi           |  41 +
 arch/arm/boot/dts/omap443x.dtsi                    |  15 +-
 arch/arm/boot/dts/omap4460.dtsi                    |  15 +-
 arch/arm/boot/dts/omap5-core-thermal.dtsi          |  28 +
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi           |  28 +
 arch/arm/boot/dts/omap5.dtsi                       |  15 +-
 drivers/cpufreq/Kconfig                            |   2 +-
 drivers/cpufreq/cpufreq-cpu0.c                     |  16 +
 drivers/hwmon/lm75.c                               |  35 +-
 drivers/hwmon/tmp102.c                             |  19 +
 drivers/thermal/Kconfig                            |  14 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/cpu_cooling.c                      |  56 +-
 drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |  79 +-
 drivers/thermal/thermal_core.h                     |   9 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  77 +-
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/cpu_cooling.h                        |  25 +
 include/linux/thermal.h                            |  32 +-
 22 files changed, 1880 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
@ 2013-09-27  3:13 ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

Hello all,

Here is the continuation of work of representing hardware thermal properties
in device tree infrastructure. The present patch series is the fourth version
of this work. Previous versions were sent as RFCs and can be found here:
V3: 
RFCv2: http://lkml.org/lkml/2013/8/23/594
RFCv1: http://lkml.org/lkml/2013/7/22/319

Major difference from V3 is on the parser itself. I have updated the binding
documentation and improved the code accordingly to previous comments mainly
from Mark R. and Joe P.

The changes on hwmon drivers have been accepted by Guenter, and in this
series I am including his Acked-by, as I didn't change anything on that side.

I also found a bug while using all involved code built as modules, thus
I have reworked a bit the cooling device registration part. This is why
there are two new patches in this series (patches 02 and 04).

Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7,
although this series is not including the DRA7 part (I will be sending separately).

Thanks all who have been contributing reviewing this code.

All best,

Eduardo Valentin (18):
  thermal: allow registering without .get_temp
  thermal: core: allow binding via .bind when tzp is present
  thermal: introduce device tree parser
  thermal: core: introduce thermal_of_cooling_device_register
  thermal: cpu_cooling: introduce of_cpufreq_cooling_register
  cpufreq: cpufreq-cpu0: add dt node parsing for cooling device
    properties
  hwmon: lm75: expose to thermal fw via DT nodes
  hwmon: tmp102: expose to thermal fw via DT nodes
  thermal: ti-soc-thermal: use thermal DT infrastructure
  arm: dts: add omap4 CPU thermal data
  arm: dts: add omap4430 thermal data
  arm: dts: add omap4460 thermal data
  arm: dts: add cooling properties on omap4430 cpu node
  arm: dts: add cooling properties on omap4460 cpu node
  arm: dts: add omap5 GPU thermal data
  arm: dts: add omap5 CORE thermal data
  arm: dts: add omap5 thermal data
  arm: dts: add cooling properties on omap5 cpu node

 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   7 +
 .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi           |  41 +
 arch/arm/boot/dts/omap443x.dtsi                    |  15 +-
 arch/arm/boot/dts/omap4460.dtsi                    |  15 +-
 arch/arm/boot/dts/omap5-core-thermal.dtsi          |  28 +
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi           |  28 +
 arch/arm/boot/dts/omap5.dtsi                       |  15 +-
 drivers/cpufreq/Kconfig                            |   2 +-
 drivers/cpufreq/cpufreq-cpu0.c                     |  16 +
 drivers/hwmon/lm75.c                               |  35 +-
 drivers/hwmon/tmp102.c                             |  19 +
 drivers/thermal/Kconfig                            |  14 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/cpu_cooling.c                      |  56 +-
 drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |  79 +-
 drivers/thermal/thermal_core.h                     |   9 +
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  77 +-
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/cpu_cooling.h                        |  25 +
 include/linux/thermal.h                            |  32 +-
 22 files changed, 1880 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 01/18] thermal: allow registering without .get_temp
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch changes the thermal core driver to allow
registration of thermal zones without the .get_temp callback.

The idea behind this change is to allow lazy registration
of sensor callbacks.

The thermal zone will be disabled whenever the ops
does not contain a .get_temp callback. The sysfs interface
will be returning -EINVAL on any temperature read operation.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 4962a6a..8a94300 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -402,7 +402,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long *temp)
 	enum thermal_trip_type type;
 #endif
 
-	if (!tz || IS_ERR(tz))
+	if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
 		goto exit;
 
 	mutex_lock(&tz->lock);
@@ -455,6 +455,9 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
 	int count;
 
+	if (!tz->ops->get_temp)
+		return;
+
 	update_temperature(tz);
 
 	for (count = 0; count < tz->trips; count++)
@@ -1384,7 +1387,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	if (trips > THERMAL_MAX_TRIPS || trips < 0 || mask >> trips)
 		return ERR_PTR(-EINVAL);
 
-	if (!ops || !ops->get_temp)
+	if (!ops)
 		return ERR_PTR(-EINVAL);
 
 	if (trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp))
@@ -1488,6 +1491,9 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
 
 	INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
 
+	if (!tz->ops->get_temp)
+		thermal_zone_device_set_polling(tz, 0);
+
 	thermal_zone_device_update(tz);
 
 	if (!result)
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 01/18] thermal: allow registering without .get_temp
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch changes the thermal core driver to allow
registration of thermal zones without the .get_temp callback.

The idea behind this change is to allow lazy registration
of sensor callbacks.

The thermal zone will be disabled whenever the ops
does not contain a .get_temp callback. The sysfs interface
will be returning -EINVAL on any temperature read operation.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 4962a6a..8a94300 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -402,7 +402,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long *temp)
 	enum thermal_trip_type type;
 #endif
 
-	if (!tz || IS_ERR(tz))
+	if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
 		goto exit;
 
 	mutex_lock(&tz->lock);
@@ -455,6 +455,9 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
 	int count;
 
+	if (!tz->ops->get_temp)
+		return;
+
 	update_temperature(tz);
 
 	for (count = 0; count < tz->trips; count++)
@@ -1384,7 +1387,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	if (trips > THERMAL_MAX_TRIPS || trips < 0 || mask >> trips)
 		return ERR_PTR(-EINVAL);
 
-	if (!ops || !ops->get_temp)
+	if (!ops)
 		return ERR_PTR(-EINVAL);
 
 	if (trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp))
@@ -1488,6 +1491,9 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
 
 	INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
 
+	if (!tz->ops->get_temp)
+		thermal_zone_device_set_polling(tz, 0);
+
 	thermal_zone_device_update(tz);
 
 	if (!result)
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 01/18] thermal: allow registering without .get_temp
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch changes the thermal core driver to allow
registration of thermal zones without the .get_temp callback.

The idea behind this change is to allow lazy registration
of sensor callbacks.

The thermal zone will be disabled whenever the ops
does not contain a .get_temp callback. The sysfs interface
will be returning -EINVAL on any temperature read operation.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 4962a6a..8a94300 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -402,7 +402,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long *temp)
 	enum thermal_trip_type type;
 #endif
 
-	if (!tz || IS_ERR(tz))
+	if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
 		goto exit;
 
 	mutex_lock(&tz->lock);
@@ -455,6 +455,9 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
 	int count;
 
+	if (!tz->ops->get_temp)
+		return;
+
 	update_temperature(tz);
 
 	for (count = 0; count < tz->trips; count++)
@@ -1384,7 +1387,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	if (trips > THERMAL_MAX_TRIPS || trips < 0 || mask >> trips)
 		return ERR_PTR(-EINVAL);
 
-	if (!ops || !ops->get_temp)
+	if (!ops)
 		return ERR_PTR(-EINVAL);
 
 	if (trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp))
@@ -1488,6 +1491,9 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
 
 	INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
 
+	if (!tz->ops->get_temp)
+		thermal_zone_device_set_polling(tz, 0);
+
 	thermal_zone_device_update(tz);
 
 	if (!result)
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 02/18] thermal: core: allow binding via .bind when tzp is present
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch allows drivers register thermal zone devices
with thermal zone params and .bind callbacks. In this case,
it will use the .bind callback.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..f7a9f4f 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -247,7 +247,7 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
 		if (!pos->tzp && !pos->ops->bind)
 			continue;
 
-		if (!pos->tzp && pos->ops->bind) {
+		if (pos->ops->bind) {
 			ret = pos->ops->bind(pos, cdev);
 			if (ret)
 				print_bind_err_msg(pos, cdev, ret);
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 02/18] thermal: core: allow binding via .bind when tzp is present
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch allows drivers register thermal zone devices
with thermal zone params and .bind callbacks. In this case,
it will use the .bind callback.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..f7a9f4f 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -247,7 +247,7 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
 		if (!pos->tzp && !pos->ops->bind)
 			continue;
 
-		if (!pos->tzp && pos->ops->bind) {
+		if (pos->ops->bind) {
 			ret = pos->ops->bind(pos, cdev);
 			if (ret)
 				print_bind_err_msg(pos, cdev, ret);
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 02/18] thermal: core: allow binding via .bind when tzp is present
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch allows drivers register thermal zone devices
with thermal zone params and .bind callbacks. In this case,
it will use the .bind callback.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..f7a9f4f 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -247,7 +247,7 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
 		if (!pos->tzp && !pos->ops->bind)
 			continue;
 
-		if (!pos->tzp && pos->ops->bind) {
+		if (pos->ops->bind) {
 			ret = pos->ops->bind(pos, cdev);
 			if (ret)
 				print_bind_err_msg(pos, cdev, ret);
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv7 03/18] thermal: introduce device tree parser
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---

Hello folks,

For those interested on this work, here is a short changelog from v6:
- Reviewed binding documentation and added type and size on all properties
- Described 'thermal-zones' node in binding documentation
- Using now cooling state terminology instead of cooling level
- Renamed milliCelsius to millicelsius
- Renamed cooling-attachments to 'cooling-maps'
- Renamed sensor to thermal sensor
- Renamed #sensor-cells to #thermal-sensor-cells
- #thermal-sensor-cells now is allowed to be 0
- Renamed 'sensors' property to 'thermal-sensors'
- Changed trip type property to be now string and documented possible values
- Described better the cooling properties
- Now parses 'contribution' instead of 'usage'
- Renamed cdev to cooling device
- Renamed 'passive-delay' property to 'polling-delay-passive'
- Fixed a couple of error messages to match the property name
- Fixed a binding issue while using cpufreq as module
- Reworked thermal_of_build_thermal_zone function so that it frees
requested memory if something goes wrong and checks for sub-nodes
with zero children.

---
 .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |   9 +-
 drivers/thermal/thermal_core.h                     |   9 +
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/thermal.h                            |  28 +-
 8 files changed, 1466 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..3dbc017
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,537 @@
+* Thermal Framework Device Tree descriptor
+
+Generic binding to provide a way of defining hardware thermal
+structure using device tree. A thermal structure includes thermal
+zones and their components, such as trip points, polling intervals,
+sensors and cooling devices binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling maps: used to describe links between trip points and
+cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+Note: This binding is a working in progress.
+
+* Thermal sensor devices
+
+Thermal sensor devices are nodes providing temperature sensing capabilities on
+thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
+nodes providing temperature data to thermal zones. Thermal sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #thermal-sensor-cells: Used to provide sensor device specific information
+  Type: unsigned	 while referring to it. Typically 0, on thermal sensor
+  Size: one cell	 nodes with only one sensor, and at least 1 on nodes
+			 with several internal sensors, in order
+			 to identify uniquely the sensor instances within
+			 the IC. See thermal zone binding for more details
+			 on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. A typical passive cooling is a CPU that has dynamic voltage and
+frequency scaling, and uses lower frequencies as cooling states.
+Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the state of cooling in which the device is.
+
+Required property:
+- cooling-min-state:	An integer indicating the smallest
+  Type: unsigned	cooling state accepted. Typically 0.
+  Size: one cell
+
+- cooling-max-state:	An integer indicating the largest
+  Type: unsigned	cooling state accepted.
+  Size: one cell
+
+- #cooling-cells:	Used to provide cooling device specific information
+  Type: unsigned	while referring to it. Must be at least 2, in order
+  Size: one cell      	to specify minimum and maximum cooling state used
+			in the reference. The first cell is the minimum
+			cooling state requested and the second cell is
+			the maximum cooling state requested in the reference.
+			See Cooling device maps section below for more details
+			on how consumers refer to cooling devices.
+
+* Trip points
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+Required properties:
+- temperature:		An integer indicating the trip temperature level,
+  Type: signed		in millicelsius.
+  Size: one cell
+
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+  Type: unsigned	relative value, in millicelsius.
+  Size: one cell
+
+- type:			a string containing the trip type. Supported values are:
+	"active":	A trip point to enable active cooling
+	"passive":	A trip point to enable passive cooling
+	"hot":		A trip point to notify emergency
+	"critical":	Hardware not reliable.
+  Type: string
+
+There are also string constants defined at
+include/dt-bindings/thermal/thermal.h.
+
+* Cooling device maps
+
+The cooling device maps node is a node to describe how cooling devices
+get assigned to trip points of the zone. The cooling devices are expected
+to be loaded in the target system.
+
+Required properties:
+- cooling-device:	A phandle of a cooling device with its specifier,
+  Type: phandle		referring to which cooling device is used in this
+			binding. The required specifiers are: the minimum
+			cooling state and the maximum cooling level used
+			in this map.
+- trip:			A phandle of a trip point node within the same thermal
+  Type: phandle		zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+  Type: unsigned	referred cooling device at the referred trip point.
+  Size: one cell      	The contribution is a ratio of the sum
+			of all cooling contributions within a thermal zone.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit specifier means:
+(i)   - minimum state allowed for minimum cooling level used in the reference.
+(ii)  - maximum state allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zone nodes
+
+The thermal zone node is the node containing all the required info
+for describing a thermal zone, including its cooling device bindings. The
+thermal zone node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone cooling maps.
+
+Required properties:
+- polling-delay-passive:	The maximum number of milliseconds to wait
+  Type: unsigned		between polls when performing passive cooling.
+  Size: one cell
+
+- polling-delay:	The maximum number of milliseconds to wait between polls
+  Type: unsigned	when checking this thermal zone.
+  Size: one cell
+
+- thermal-sensors:		A list of sensor phandles and sensor specifier
+  Type: list of phandles	used while monitoring the thermal zone.
+
+- trips:		A sub-node which is a container of only trip point nodes
+  Type: sub-node	required to describe the thermal zone.
+
+- cooling-maps:		A sub-node which is a container of only cooling device
+  Type: sub-node	map nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- thermal-sensors-names:	List of thermal sensor name strings sorted
+  Type: list of strings		in the same order as the thermal-sensors
+				property.
+
+- coefficients:		An array of integers (one signed cell) containing
+  Type: array		coefficients to compose a linear relation between
+  Elem size: one cell	the sensors described in the thermal-sensors property.
+  Elem type: signed	Coefficients defaults to 1, in case this property
+			is not specified. A simple linear polynomial is used:
+			Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
+
+			The coefficients are ordered and they match with sensors
+			by means of sensor ID. Additional coefficients are
+			interpreted as constant offsets.
+
+Note: The delay properties are bound to the maximum dT/dt (temperature
+derivative over time) in two situations for a thermal zone:
+(i)  - when active cooling is activated (polling-delay-passive); and
+(ii) - when the zone just needs to be monitored (polling-delay).
+The maximum dT/dt is highly bound to hardware power consumption and dissipation
+capability.
+The delays are chosen to account for said max dT/dt, such that a device
+does not cross several trip boundaries unexpectedly between polls. Choosing
+the right polling delays shall avoid having the device in temperature ranges
+that may damage the silicon structures and reduce silicon lifetime.
+
+* The thermal-zones node
+
+The "thermal-zones" node is a container for all thermal zone nodes. It shall
+contain only sub-nodes describing thermal zones as in the section
+"Thermal zone nodes".
+
+* Examples
+
+Below are several examples on how to use thermal data descriptors
+using device tree bindings:
+
+(a) - CPU thermal zone
+
+The CPU thermal zone example below describes how to setup one thermal zone
+using one single sensor as temperature source and many cooling devices and
+power dissipation control sources.
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpus {
+	cpu0: cpu@0 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <0>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0>;
+
+        trips {
+                cpu-alert0: cpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_ACTIVE;
+                };
+                cpu-alert1: cpu-alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu-crit: cpu-crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		map1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		map2 {
+			trip = <&cpu-alert1>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+		};
+	};
+};
+
+In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
+the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
+via I2C bus 1, at adress 0x48, which has ten different cooling states.
+It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
+cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
+at 90C, as an example of active cooling. The same cooling device is used at
+'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
+using all its cooling states at trip point 'cpu-alert1',
+which is a trip point at 100C.
+
+(b) - IC with several internal sensors
+
+The example below describes how to deploy several thermal zones based off a
+single sensor IC, assuming it has several internal sensors. This is a common
+case on SoC designs with several internal IPs that may need different thermal
+requirements, and thus may have their own sensor to monitor or detect internal
+hotspots in their silicon.
+
+#include <dt-bindings/thermal/thermal.h>
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        thermal-sensors = <&bandgap0     0>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                cpu-alert: cpu-alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu-crit: cpu-crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	polling-delay-passive = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0     1>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                gpu-alert: gpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                gpu-crit: gpu-crit {
+                        temperature = <105000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	polling-delay-passive = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        thermal-sensors = <&bandgap0     2>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                dsp-alert: gpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                dsp-crit: gpu-crit {
+                        temperature = <135000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+In the example above there is one bandgap IC which has the capability to
+monitor three sensors. The hardware has been designed so that sensors are
+placed on different places in the DIE to monitor different temperature
+hotspots: one for CPU thermal zone, one for GPU thermal zone and the
+other to monitor a DSP thermal zone.
+
+Thus, there is a need to assign each sensor provided by the bandgap IC
+to different thermal zones. This is achieved by means of using the
+#thermal-sensor-cells property and using the first specifier as sensor ID.
+In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,
+bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
+is used to monitor DSP thermal zone. Each zone may be uncorrelated,
+having its own dT/dt requirements, trips and cooling maps.
+
+
+(c) - Several sensors within one single thermal zone
+
+The example below illustrates how to use more than one sensor within
+one thermal zone.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	adc: sensor@0x49 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <0>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0>,
+			  <&adc>;
+	thermal-sensors-names = "cpu", "pcb north";
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-maps {
+		...
+	};
+};
+
+In some cases, there is a need to use more than one sensor to extrapolate
+a thermal hotspot in the silicon. The above example illustrate this situation.
+For instance, it may be the case that a sensor external to CPU IP may be place
+close to CPU hotspot and together with internal CPU sensor, it is used
+to determine the hotspot. The hyppotetical extrapolation rule would be:
+		hotspot = 100 * bandgap - 120 * adc + 484
+
+The same idea can be used to add fixed offset:
+	polling-delay-passive = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+		hotspot = 1 * adc + 6000
+
+In the above equation, the hotspot is always 6C higher than what is read
+from the sensor ADC. The binding would be then:
+			/* sensor       ID */
+        thermal-sensors =  <&adc	0>;
+
+		/* hotspot = 1 * adc + 6000 */
+	coefficients = 		<1	6000>;
+
+(d) - Board thermal
+
+The board thermal example below illustrates how to setup one thermal zone
+with many sensors and many cooling devices.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	adc-dummy: sensor@0x50 {
+		...
+		#thermal-sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	polling-delay-passive = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-maps {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	polling-delay-passive = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&adc-dummy     0>,
+			  <&adc-dummy     1>,
+			  <&adc-dymmy     2>;
+	thermal-sensors-names = "pcb top edge", "lcd", "back cover";
+			/*
+			 * An array of coefficients describing the sensor
+			 * linear relation. E.g.:
+			 * z = c1*x1 + c2*x2 + c3*x3
+			 */
+	coefficients =		<1200	-345	890>;
+
+	trips {
+		/* Trips are based on resulting linear equation */
+		cpu-trip: cpu-trip {
+			temperature = <60000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		};
+		gpu-trip: gpu-trip {
+			temperature = <55000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		}
+		lcd-trip: lcp-trip {
+			temperature = <53000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		};
+		crit-trip: crit-trip {
+			temperature = <68000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		map1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		map2 {
+			trip = <&lcd-trip>;
+			cooling-device = <&lcd0 5 10>;
+			contribution = <15>;
+		};
+	};
+};
+
+The above example is a mix of previous examples, a sensor IP with several internal
+sensors used to monitor different zones, one of them is composed by several sensors and
+with different cooling devices.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dbfc390..dd81eb8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,6 +29,19 @@ config THERMAL_HWMON
 	  Say 'Y' here if you want all thermal sensors to
 	  have hwmon sysfs interface too.
 
+config THERMAL_OF
+	bool
+	prompt "APIs to parse thermal data out of device tree"
+	depends on OF
+	default y
+	help
+	  This options provides helpers to add the support to
+	  read and parse thermal data definitions out of the
+	  device tree blob.
+
+	  Say 'Y' here if you need to build thermal infrastructure
+	  based on device tree.
+
 choice
 	prompt "Default Thermal governor"
 	default THERMAL_DEFAULT_GOV_STEP_WISE
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 584b363..4b03956 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,6 +7,7 @@ thermal_sys-y			+= thermal_core.o
 
 # interface to/from other layers providing sensors
 thermal_sys-$(CONFIG_THERMAL_HWMON)		+= thermal_hwmon.o
+thermal_sys-$(CONFIG_THERMAL_OF)		+= of-thermal.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)	+= fair_share.o
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
new file mode 100644
index 0000000..0464eaf
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,845 @@
+/*
+ *  of-thermal.c - Generic Thermal Management device tree support.
+ *
+ *  Copyright (C) 2013 Texas Instruments
+ *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ *
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/thermal.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/string.h>
+
+#include "thermal_core.h"
+
+/***   Private data structures to represent thermal device tree data ***/
+
+/**
+ * struct __thermal_trip - representation of a point in temperature domain
+ * @np: pointer to struct device_node that this trip point was created from
+ * @temperature: temperature value in miliCelsius
+ * @hysteresis: relative hysteresis in miliCelsius
+ * @type: trip point type
+ */
+
+struct __thermal_trip {
+	struct device_node *np;
+	unsigned long int temperature;
+	unsigned long int hysteresis;
+	enum thermal_trip_type type;
+};
+
+/**
+ * struct __thermal_bind_param - a match between trip and cooling device
+ * @cooling_device: a pointer to identify the referred cooling device
+ * @trip_id: the trip point index
+ * @usage: the percentage (from 0 to 100) of cooling contribution
+ * @min: minimum cooling state used at this trip point
+ * @max: maximum cooling state used at this trip point
+ */
+
+struct __thermal_bind_params {
+	struct device_node *cooling_device;
+	unsigned int trip_id;
+	unsigned int usage;
+	unsigned long min;
+	unsigned long max;
+};
+
+/**
+ * struct __thermal_zone - internal representation of a thermal zone
+ * @mode: current thermal zone device mode (enabled/disabled)
+ * @passive_delay: polling interval while passive cooling is activated
+ * @polling_delay: zone polling interval
+ * @ntrips: number of trip points
+ * @trips: an array of trip points (0..ntrips - 1)
+ * @num_tbps: number of thermal bind params
+ * @tbps: an array of thermal bind params (0..num_tbps - 1)
+ * @sensor_data: sensor private data used while reading temperature and trend
+ * @get_temp: sensor callback to read temperature
+ * @get_trend: sensor callback to read temperature trend
+ */
+
+struct __thermal_zone {
+	enum thermal_device_mode mode;
+	int passive_delay;
+	int polling_delay;
+
+	/* trip data */
+	int ntrips;
+	struct __thermal_trip *trips;
+
+	/* cooling binding data */
+	int num_tbps;
+	struct __thermal_bind_params *tbps;
+
+	/* sensor interface */
+	void *sensor_data;
+	int (*get_temp)(void *, long *);
+	int (*get_trend)(void *, long *);
+};
+
+/***   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;
+
+	if (!data->get_temp)
+		return -EINVAL;
+
+	return data->get_temp(data->sensor_data, temp);
+}
+
+static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
+				enum thermal_trend *trend)
+{
+	struct __thermal_zone *data = tz->devdata;
+	long dev_trend;
+	int r;
+
+	if (!data->get_trend)
+		return -EINVAL;
+
+	r = data->get_trend(data->sensor_data, &dev_trend);
+	if (r)
+		return r;
+
+	/* TODO: These intervals might have some thresholds, but in core code */
+	if (dev_trend > 0)
+		*trend = THERMAL_TREND_RAISING;
+	else if (dev_trend < 0)
+		*trend = THERMAL_TREND_DROPPING;
+	else
+		*trend = THERMAL_TREND_STABLE;
+
+	return 0;
+}
+
+static int of_thermal_bind(struct thermal_zone_device *thermal,
+			   struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to bind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_bind_cooling_device(thermal,
+						tbp->trip_id, cdev,
+						tbp->min,
+						tbp->max);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_unbind(struct thermal_zone_device *thermal,
+			     struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to unbind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_unbind_cooling_device(thermal,
+						tbp->trip_id, cdev);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_get_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode *mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	*mode = data->mode;
+
+	return 0;
+}
+
+static int of_thermal_set_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	mutex_lock(&tz->lock);
+
+	if (mode == THERMAL_DEVICE_ENABLED)
+		tz->polling_delay = data->polling_delay;
+	else
+		tz->polling_delay = 0;
+
+	mutex_unlock(&tz->lock);
+
+	data->mode = mode;
+	thermal_zone_device_update(tz);
+
+	return 0;
+}
+
+static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
+				    enum thermal_trip_type *type)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*type = data->trips[trip].type;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*temp = data->trips[trip].temperature;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal fw should take care of data->mask & (1 << trip) */
+	data->trips[trip].temperature = temp;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long *hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*hyst = data->trips[trip].hysteresis;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal fw should take care of data->mask & (1 << trip) */
+	data->trips[trip].hysteresis = hyst;
+
+	return 0;
+}
+
+static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+	int i;
+
+	for (i = 0; i < data->ntrips; i++)
+		if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
+			*temp = data->trips[i].temperature;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+
+static struct thermal_zone_device_ops of_thermal_ops = {
+	.get_mode = of_thermal_get_mode,
+	.set_mode = of_thermal_set_mode,
+
+	.get_trip_type = of_thermal_get_trip_type,
+	.get_trip_temp = of_thermal_get_trip_temp,
+	.set_trip_temp = of_thermal_set_trip_temp,
+	.get_trip_hyst = of_thermal_get_trip_hyst,
+	.set_trip_hyst = of_thermal_set_trip_hyst,
+	.get_crit_temp = of_thermal_get_crit_temp,
+
+	.bind = of_thermal_bind,
+	.unbind = of_thermal_unbind,
+};
+
+/***   sensor API   ***/
+
+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 *))
+{
+	struct thermal_zone_device *tzd;
+	struct __thermal_zone *tz;
+
+	tzd = thermal_zone_get_zone_by_name(zone->name);
+	if (IS_ERR(tzd))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	tz = tzd->devdata;
+
+	mutex_lock(&tzd->lock);
+	tz->get_temp = get_temp;
+	tz->get_trend = get_trend;
+	tz->sensor_data = data;
+
+	tzd->ops->get_temp = of_thermal_get_temp;
+	tzd->ops->get_trend = of_thermal_get_trend;
+	mutex_unlock(&tzd->lock);
+
+	return tzd;
+}
+
+/**
+ * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *             than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *        back, when a temperature reading is needed.
+ * @get_temp: a pointer to a function that reads the sensor temperature.
+ * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ *
+ * This function will search the list of thermal zones described in device
+ * tree and look for the zone that refer to the sensor device pointed by
+ * @dev->of_node as temperature providers. For the zone pointing to the
+ * sensor node, the sensor will be added to the DT thermal zone device.
+ *
+ * The thermal zone temperature is provided by the @get_temp function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * The thermal zone temperature trend is provided by the @get_trend function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * TODO:
+ * 01 - This function must enqueue the new sensor instead of using
+ * it as the only source of temperature values.
+ *
+ * 02 - There must be a way to match the sensor with all thermal zones
+ * that refer to it.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+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 *))
+{
+	struct device_node *np, *child, *sensor_np;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np)
+		return ERR_PTR(-ENODEV);
+
+	if (!dev || !dev->of_node)
+		return ERR_PTR(-EINVAL);
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret, id;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "thermal-sensors",
+						 "#thermal-sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			id = 0;
+		else
+			id = sensor_specs.args[0];
+
+		if (sensor_specs.np == sensor_np && id == sensor_id) {
+			of_node_put(np);
+			return thermal_zone_of_add_sensor(child, sensor_np,
+							  data,
+							  get_temp,
+							  get_trend);
+		}
+	}
+	of_node_put(np);
+
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
+
+/**
+ * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
+ *
+ * This function removes the sensor callbacks and private data from the
+ * thermal zone device registered with thermal_zone_of_sensor_register()
+ * API. It will also silent the zone by remove the .get_temp() and .get_trend()
+ * thermal zone device callbacks.
+ *
+ * TODO: When the support to several sensors per zone is added, this
+ * function must search the sensor list based on @dev parameter.
+ *
+ */
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tzd)
+{
+	struct __thermal_zone *tz;
+
+	if (!dev || !tzd || !tzd->devdata)
+		return;
+
+	tz = tzd->devdata;
+
+	/* no __thermal_zone, nothing to be done */
+	if (!tz)
+		return;
+
+	mutex_lock(&tzd->lock);
+	tzd->ops->get_temp = NULL;
+	tzd->ops->get_trend = NULL;
+
+	tz->get_temp = NULL;
+	tz->get_trend = NULL;
+	tz->sensor_data = NULL;
+	mutex_unlock(&tzd->lock);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
+
+/***   functions parsing device tree nodes   ***/
+
+/**
+ * thermal_of_populate_bind_params - parse and fill cooling map data
+ * @np: DT node containing a cooling-map node
+ * @__tbp: data structure to be filled with cooling map info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-map type of node represented by
+ * @np parameter and fills the read data into @__tbp data structure.
+ * It needs the already parsed array of trip points of the thermal zone
+ * in consideration.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_bind_params(struct device_node *np,
+					   struct __thermal_bind_params *__tbp,
+					   struct __thermal_trip *trips,
+					   int ntrips)
+{
+	struct of_phandle_args cooling_spec;
+	struct device_node *trip;
+	int ret, i;
+	u32 prop;
+
+	/* Default weight. Usage is optional */
+	__tbp->usage = 0;
+	ret = of_property_read_u32(np, "contribution", &prop);
+	if (ret == 0)
+		__tbp->usage = prop;
+
+	trip = of_parse_phandle(np, "trip", 0);
+	if (!trip) {
+		pr_err("missing trip property\n");
+		return -ENODEV;
+	}
+
+	/* match using device_node */
+	for (i = 0; i < ntrips; i++)
+		if (trip == trips[i].np) {
+			__tbp->trip_id = i;
+			break;
+		}
+
+	if (i == ntrips) {
+		ret = -ENODEV;
+		goto end;
+	}
+
+	ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
+					 0, &cooling_spec);
+	if (ret < 0) {
+		pr_err("missing cooling_device property\n");
+		goto end;
+	}
+	__tbp->cooling_device = cooling_spec.np;
+	if (cooling_spec.args_count >= 2) { /* at least min and max */
+		__tbp->min = cooling_spec.args[0];
+		__tbp->max = cooling_spec.args[1];
+	} else {
+		pr_err("wrong reference to cooling device, missing limits\n");
+	}
+
+end:
+	of_node_put(trip);
+
+	return ret;
+}
+
+/**
+ * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
+ * into the device tree binding of 'trip', property type.
+ */
+static const char * const trip_types[] = {
+	[THERMAL_TRIP_ACTIVE]	= "active",
+	[THERMAL_TRIP_PASSIVE]	= "passive",
+	[THERMAL_TRIP_HOT]	= "hot",
+	[THERMAL_TRIP_CRITICAL]	= "critical",
+};
+
+/**
+ * thermal_of_get_trip_type - Get phy mode for given device_node
+ * @np:	Pointer to the given device_node
+ * @type: Pointer to resulting trip type
+ *
+ * The function gets trip type string from property 'type',
+ * and store its index in trip_types table in @type,
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int thermal_of_get_trip_type(struct device_node *np,
+				    enum thermal_trip_type *type)
+{
+	const char *t;
+	int err, i;
+
+	err = of_property_read_string(np, "type", &t);
+	if (err < 0)
+		return err;
+
+	for (i = 0; i < ARRAY_SIZE(trip_types); i++)
+		if (!strcasecmp(t, trip_types[i])) {
+			*type = i;
+			return 0;
+		}
+
+	return -ENODEV;
+}
+
+/**
+ * thermal_of_populate_trip - parse and fill one trip point data
+ * @np: DT node containing a trip point node
+ * @trip: trip point data structure to be filled up
+ *
+ * This function parses a trip point type of node represented by
+ * @np parameter and fills the read data into @trip data structure.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_trip(struct device_node *np,
+				    struct __thermal_trip *trip)
+{
+	int prop;
+	int ret;
+
+	ret = of_property_read_u32(np, "temperature", &prop);
+	if (ret < 0) {
+		pr_err("missing temperature property\n");
+		return ret;
+	}
+	trip->temperature = prop;
+
+	ret = of_property_read_u32(np, "hysteresis", &prop);
+	if (ret < 0) {
+		pr_err("missing hysteresis property\n");
+		return ret;
+	}
+	trip->hysteresis = prop;
+
+	ret = thermal_of_get_trip_type(np, &trip->type);
+	if (ret < 0) {
+		pr_err("wrong trip type property\n");
+		return ret;
+	}
+
+	/* Required for cooling map matching */
+	trip->np = np;
+
+	return 0;
+}
+
+/**
+ * thermal_of_build_thermal_zone - parse and fill one thermal zone data
+ * @np: DT node containing a thermal zone node
+ *
+ * This function parses a thermal zone type of node represented by
+ * @np parameter and fills the read data into a __thermal_zone data structure
+ * and return this pointer.
+ *
+ * TODO: Missing properties to parse: thermal-sensor-names and coefficients
+ *
+ * Return: On success returns a valid struct __thermal_zone,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+static struct __thermal_zone *
+thermal_of_build_thermal_zone(struct device_node *np)
+{
+	struct device_node *child = NULL, *gchild;
+	struct __thermal_zone *tz;
+	int ret, i;
+	u32 prop;
+
+	if (!np) {
+		pr_err("no thermal zone np\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
+	if (!tz)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "polling-delay-passive", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay-passive property\n");
+		goto free_tz;
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay property\n");
+		goto free_tz;
+	}
+	tz->polling_delay = prop;
+
+	/* trips */
+	child = of_get_child_by_name(np, "trips");
+
+	/* No trips provided */
+	if (!child)
+		goto finish;
+
+	tz->ntrips = of_get_child_count(child);
+	if (tz->ntrips == 0) /* must have at least one child */
+		goto finish;
+
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips) {
+		ret = -ENOMEM;
+		goto free_tz;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild) {
+		ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
+		if (ret)
+			goto free_trips;
+	}
+
+	of_node_put(child);
+
+	/* cooling-maps */
+	child = of_get_child_by_name(np, "cooling-maps");
+
+	/* cooling-maps not provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	if (tz->num_tbps == 0)
+		goto finish;
+
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps) {
+		ret = -ENOMEM;
+		goto free_trips;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						      tz->trips, tz->ntrips);
+		if (ret)
+			goto free_tbps;
+
+finish:
+	of_node_put(child);
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+
+free_tbps:
+	kfree(tz->tbps);
+free_trips:
+	kfree(tz->trips);
+free_tz:
+	kfree(tz);
+	of_node_put(child);
+
+	return ERR_PTR(ret);
+}
+
+static inline void of_thermal_free_zone(struct __thermal_zone *tz)
+{
+	kfree(tz->tbps);
+	kfree(tz->trips);
+	kfree(tz);
+}
+
+/**
+ * of_parse_thermal_zones - parse device tree thermal data
+ *
+ * Initialization function that can be called by machine initialization
+ * code to parse thermal data and populate the thermal framework
+ * with hardware thermal zones info. This function only parses thermal zones.
+ * Cooling devices and sensor devices nodes are supposed to be parsed
+ * by their respective drivers.
+ *
+ * Return: 0 on success, proper error code otherwise
+ *
+ */
+int __init of_parse_thermal_zones(void)
+{
+	struct device_node *np, *child;
+	struct __thermal_zone *tz;
+	struct thermal_zone_device_ops *ops;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_debug("unable to find thermal zones\n");
+		return 0; /* Run successfully on systems without thermal DT */
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+		struct thermal_zone_params *tzp;
+
+		tz = thermal_of_build_thermal_zone(child);
+		if (IS_ERR(tz)) {
+			pr_err("failed to build thermal zone %s: %ld\n",
+			       child->name,
+			       PTR_ERR(tz));
+			continue;
+		}
+
+		ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			goto exit_free;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp) {
+			kfree(ops);
+			goto exit_free;
+		}
+
+		/* No hwmon because there might be hwmon drivers registering */
+		tzp->no_hwmon = true;
+
+		zone = thermal_zone_device_register(child->name, tz->ntrips,
+						    0, tz,
+						    ops, tzp,
+						    tz->passive_delay,
+						    tz->polling_delay);
+		if (IS_ERR(zone)) {
+			pr_err("Failed to build %s zone %ld\n", child->name,
+			       PTR_ERR(zone));
+			kfree(tzp);
+			kfree(ops);
+			of_thermal_free_zone(tz);
+			/* attempting to build remaining zones still */
+		}
+	}
+
+	return 0;
+
+exit_free:
+	of_thermal_free_zone(tz);
+
+	/* no memory available, so free what we have built */
+	of_thermal_destroy_zones();
+
+	return -ENOMEM;
+}
+
+/**
+ * of_thermal_destroy_zones - remove all zones parsed and allocated resources
+ *
+ * Finds all zones parsed and added to the thermal framework and remove them
+ * from the system, together with their resources.
+ *
+ */
+void __exit of_thermal_destroy_zones(void)
+{
+	struct device_node *np, *child;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_err("unable to find thermal zones\n");
+		return;
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+
+		zone = thermal_zone_get_zone_by_name(child->name);
+		if (IS_ERR(zone))
+			continue;
+
+		thermal_zone_device_unregister(zone);
+		kfree(zone->tzp);
+		kfree(zone->ops);
+		of_thermal_free_zone(zone->devdata);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index f7a9f4f..fec3351 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
  */
 struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	int trips, int mask, void *devdata,
-	const struct thermal_zone_device_ops *ops,
+	struct thermal_zone_device_ops *ops,
 	const struct thermal_zone_params *tzp,
 	int passive_delay, int polling_delay)
 {
@@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
 	if (result)
 		goto unregister_class;
 
+	result = of_parse_thermal_zones();
+	if (result)
+		goto exit_netlink;
+
 	return 0;
 
+exit_netlink:
+	genetlink_exit();
 unregister_governors:
 	thermal_unregister_governors();
 unregister_class:
@@ -1768,6 +1774,7 @@ error:
 
 static void __exit thermal_exit(void)
 {
+	of_thermal_destroy_zones();
 	genetlink_exit();
 	class_unregister(&thermal_class);
 	thermal_unregister_governors();
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 7cf2f66..3db339f 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
 static inline void thermal_gov_user_space_unregister(void) {}
 #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
 
+/* device tree support */
+#ifdef CONFIG_THERMAL_OF
+int of_parse_thermal_zones(void);
+void of_thermal_destroy_zones(void);
+#else
+static inline int of_parse_thermal_zones(void) { return 0; }
+static inline void of_thermal_destroy_zones(void) { }
+#endif
+
 #endif /* __THERMAL_CORE_H__ */
diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
new file mode 100644
index 0000000..59c4581
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal.h
@@ -0,0 +1,27 @@
+/*
+ * This header provides constants for most thermal bindings.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *	Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
+#define _DT_BINDINGS_THERMAL_THERMAL_H
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE		"active"
+#define THERMAL_TRIP_PASSIVE		"passive"
+#define THERMAL_TRIP_HOT		"hot"
+#define THERMAL_TRIP_CRITICAL		"critical"
+
+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT		(-1UL)
+
+#endif
+
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b268d3c..b780c5b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -143,6 +143,7 @@ struct thermal_cooling_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
 	struct device device;
+	struct device_node *np;
 	void *devdata;
 	const struct thermal_cooling_device_ops *ops;
 	bool updated; /* true if the cooling device does not need update */
@@ -172,7 +173,7 @@ struct thermal_zone_device {
 	int emul_temperature;
 	int passive;
 	unsigned int forced_passive;
-	const struct thermal_zone_device_ops *ops;
+	struct thermal_zone_device_ops *ops;
 	const struct thermal_zone_params *tzp;
 	struct thermal_governor *governor;
 	struct list_head thermal_instances;
@@ -242,8 +243,31 @@ struct thermal_genl_event {
 };
 
 /* Function declarations */
+#ifdef CONFIG_THERMAL_OF
+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 *));
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz);
+#else
+static inline 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 *))
+{
+	return NULL;
+}
+
+static inline
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz)
+{
+}
+
+#endif
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
-		void *, const struct thermal_zone_device_ops *,
+		void *, struct thermal_zone_device_ops *,
 		const struct thermal_zone_params *, int, int);
 void thermal_zone_device_unregister(struct thermal_zone_device *);
 
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv7 03/18] thermal: introduce device tree parser
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---

Hello folks,

For those interested on this work, here is a short changelog from v6:
- Reviewed binding documentation and added type and size on all properties
- Described 'thermal-zones' node in binding documentation
- Using now cooling state terminology instead of cooling level
- Renamed milliCelsius to millicelsius
- Renamed cooling-attachments to 'cooling-maps'
- Renamed sensor to thermal sensor
- Renamed #sensor-cells to #thermal-sensor-cells
- #thermal-sensor-cells now is allowed to be 0
- Renamed 'sensors' property to 'thermal-sensors'
- Changed trip type property to be now string and documented possible values
- Described better the cooling properties
- Now parses 'contribution' instead of 'usage'
- Renamed cdev to cooling device
- Renamed 'passive-delay' property to 'polling-delay-passive'
- Fixed a couple of error messages to match the property name
- Fixed a binding issue while using cpufreq as module
- Reworked thermal_of_build_thermal_zone function so that it frees
requested memory if something goes wrong and checks for sub-nodes
with zero children.

---
 .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |   9 +-
 drivers/thermal/thermal_core.h                     |   9 +
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/thermal.h                            |  28 +-
 8 files changed, 1466 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..3dbc017
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,537 @@
+* Thermal Framework Device Tree descriptor
+
+Generic binding to provide a way of defining hardware thermal
+structure using device tree. A thermal structure includes thermal
+zones and their components, such as trip points, polling intervals,
+sensors and cooling devices binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling maps: used to describe links between trip points and
+cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+Note: This binding is a working in progress.
+
+* Thermal sensor devices
+
+Thermal sensor devices are nodes providing temperature sensing capabilities on
+thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
+nodes providing temperature data to thermal zones. Thermal sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #thermal-sensor-cells: Used to provide sensor device specific information
+  Type: unsigned	 while referring to it. Typically 0, on thermal sensor
+  Size: one cell	 nodes with only one sensor, and at least 1 on nodes
+			 with several internal sensors, in order
+			 to identify uniquely the sensor instances within
+			 the IC. See thermal zone binding for more details
+			 on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. A typical passive cooling is a CPU that has dynamic voltage and
+frequency scaling, and uses lower frequencies as cooling states.
+Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the state of cooling in which the device is.
+
+Required property:
+- cooling-min-state:	An integer indicating the smallest
+  Type: unsigned	cooling state accepted. Typically 0.
+  Size: one cell
+
+- cooling-max-state:	An integer indicating the largest
+  Type: unsigned	cooling state accepted.
+  Size: one cell
+
+- #cooling-cells:	Used to provide cooling device specific information
+  Type: unsigned	while referring to it. Must be at least 2, in order
+  Size: one cell      	to specify minimum and maximum cooling state used
+			in the reference. The first cell is the minimum
+			cooling state requested and the second cell is
+			the maximum cooling state requested in the reference.
+			See Cooling device maps section below for more details
+			on how consumers refer to cooling devices.
+
+* Trip points
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+Required properties:
+- temperature:		An integer indicating the trip temperature level,
+  Type: signed		in millicelsius.
+  Size: one cell
+
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+  Type: unsigned	relative value, in millicelsius.
+  Size: one cell
+
+- type:			a string containing the trip type. Supported values are:
+	"active":	A trip point to enable active cooling
+	"passive":	A trip point to enable passive cooling
+	"hot":		A trip point to notify emergency
+	"critical":	Hardware not reliable.
+  Type: string
+
+There are also string constants defined at
+include/dt-bindings/thermal/thermal.h.
+
+* Cooling device maps
+
+The cooling device maps node is a node to describe how cooling devices
+get assigned to trip points of the zone. The cooling devices are expected
+to be loaded in the target system.
+
+Required properties:
+- cooling-device:	A phandle of a cooling device with its specifier,
+  Type: phandle		referring to which cooling device is used in this
+			binding. The required specifiers are: the minimum
+			cooling state and the maximum cooling level used
+			in this map.
+- trip:			A phandle of a trip point node within the same thermal
+  Type: phandle		zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+  Type: unsigned	referred cooling device at the referred trip point.
+  Size: one cell      	The contribution is a ratio of the sum
+			of all cooling contributions within a thermal zone.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit specifier means:
+(i)   - minimum state allowed for minimum cooling level used in the reference.
+(ii)  - maximum state allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zone nodes
+
+The thermal zone node is the node containing all the required info
+for describing a thermal zone, including its cooling device bindings. The
+thermal zone node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone cooling maps.
+
+Required properties:
+- polling-delay-passive:	The maximum number of milliseconds to wait
+  Type: unsigned		between polls when performing passive cooling.
+  Size: one cell
+
+- polling-delay:	The maximum number of milliseconds to wait between polls
+  Type: unsigned	when checking this thermal zone.
+  Size: one cell
+
+- thermal-sensors:		A list of sensor phandles and sensor specifier
+  Type: list of phandles	used while monitoring the thermal zone.
+
+- trips:		A sub-node which is a container of only trip point nodes
+  Type: sub-node	required to describe the thermal zone.
+
+- cooling-maps:		A sub-node which is a container of only cooling device
+  Type: sub-node	map nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- thermal-sensors-names:	List of thermal sensor name strings sorted
+  Type: list of strings		in the same order as the thermal-sensors
+				property.
+
+- coefficients:		An array of integers (one signed cell) containing
+  Type: array		coefficients to compose a linear relation between
+  Elem size: one cell	the sensors described in the thermal-sensors property.
+  Elem type: signed	Coefficients defaults to 1, in case this property
+			is not specified. A simple linear polynomial is used:
+			Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
+
+			The coefficients are ordered and they match with sensors
+			by means of sensor ID. Additional coefficients are
+			interpreted as constant offsets.
+
+Note: The delay properties are bound to the maximum dT/dt (temperature
+derivative over time) in two situations for a thermal zone:
+(i)  - when active cooling is activated (polling-delay-passive); and
+(ii) - when the zone just needs to be monitored (polling-delay).
+The maximum dT/dt is highly bound to hardware power consumption and dissipation
+capability.
+The delays are chosen to account for said max dT/dt, such that a device
+does not cross several trip boundaries unexpectedly between polls. Choosing
+the right polling delays shall avoid having the device in temperature ranges
+that may damage the silicon structures and reduce silicon lifetime.
+
+* The thermal-zones node
+
+The "thermal-zones" node is a container for all thermal zone nodes. It shall
+contain only sub-nodes describing thermal zones as in the section
+"Thermal zone nodes".
+
+* Examples
+
+Below are several examples on how to use thermal data descriptors
+using device tree bindings:
+
+(a) - CPU thermal zone
+
+The CPU thermal zone example below describes how to setup one thermal zone
+using one single sensor as temperature source and many cooling devices and
+power dissipation control sources.
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpus {
+	cpu0: cpu@0 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <0>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0>;
+
+        trips {
+                cpu-alert0: cpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_ACTIVE;
+                };
+                cpu-alert1: cpu-alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu-crit: cpu-crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		map1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		map2 {
+			trip = <&cpu-alert1>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+		};
+	};
+};
+
+In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
+the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
+via I2C bus 1, at adress 0x48, which has ten different cooling states.
+It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
+cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
+at 90C, as an example of active cooling. The same cooling device is used at
+'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
+using all its cooling states at trip point 'cpu-alert1',
+which is a trip point at 100C.
+
+(b) - IC with several internal sensors
+
+The example below describes how to deploy several thermal zones based off a
+single sensor IC, assuming it has several internal sensors. This is a common
+case on SoC designs with several internal IPs that may need different thermal
+requirements, and thus may have their own sensor to monitor or detect internal
+hotspots in their silicon.
+
+#include <dt-bindings/thermal/thermal.h>
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        thermal-sensors = <&bandgap0     0>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                cpu-alert: cpu-alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu-crit: cpu-crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	polling-delay-passive = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0     1>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                gpu-alert: gpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                gpu-crit: gpu-crit {
+                        temperature = <105000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	polling-delay-passive = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        thermal-sensors = <&bandgap0     2>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                dsp-alert: gpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                dsp-crit: gpu-crit {
+                        temperature = <135000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+In the example above there is one bandgap IC which has the capability to
+monitor three sensors. The hardware has been designed so that sensors are
+placed on different places in the DIE to monitor different temperature
+hotspots: one for CPU thermal zone, one for GPU thermal zone and the
+other to monitor a DSP thermal zone.
+
+Thus, there is a need to assign each sensor provided by the bandgap IC
+to different thermal zones. This is achieved by means of using the
+#thermal-sensor-cells property and using the first specifier as sensor ID.
+In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,
+bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
+is used to monitor DSP thermal zone. Each zone may be uncorrelated,
+having its own dT/dt requirements, trips and cooling maps.
+
+
+(c) - Several sensors within one single thermal zone
+
+The example below illustrates how to use more than one sensor within
+one thermal zone.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	adc: sensor@0x49 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <0>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0>,
+			  <&adc>;
+	thermal-sensors-names = "cpu", "pcb north";
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-maps {
+		...
+	};
+};
+
+In some cases, there is a need to use more than one sensor to extrapolate
+a thermal hotspot in the silicon. The above example illustrate this situation.
+For instance, it may be the case that a sensor external to CPU IP may be place
+close to CPU hotspot and together with internal CPU sensor, it is used
+to determine the hotspot. The hyppotetical extrapolation rule would be:
+		hotspot = 100 * bandgap - 120 * adc + 484
+
+The same idea can be used to add fixed offset:
+	polling-delay-passive = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+		hotspot = 1 * adc + 6000
+
+In the above equation, the hotspot is always 6C higher than what is read
+from the sensor ADC. The binding would be then:
+			/* sensor       ID */
+        thermal-sensors =  <&adc	0>;
+
+		/* hotspot = 1 * adc + 6000 */
+	coefficients = 		<1	6000>;
+
+(d) - Board thermal
+
+The board thermal example below illustrates how to setup one thermal zone
+with many sensors and many cooling devices.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	adc-dummy: sensor@0x50 {
+		...
+		#thermal-sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	polling-delay-passive = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-maps {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	polling-delay-passive = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&adc-dummy     0>,
+			  <&adc-dummy     1>,
+			  <&adc-dymmy     2>;
+	thermal-sensors-names = "pcb top edge", "lcd", "back cover";
+			/*
+			 * An array of coefficients describing the sensor
+			 * linear relation. E.g.:
+			 * z = c1*x1 + c2*x2 + c3*x3
+			 */
+	coefficients =		<1200	-345	890>;
+
+	trips {
+		/* Trips are based on resulting linear equation */
+		cpu-trip: cpu-trip {
+			temperature = <60000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		};
+		gpu-trip: gpu-trip {
+			temperature = <55000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		}
+		lcd-trip: lcp-trip {
+			temperature = <53000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		};
+		crit-trip: crit-trip {
+			temperature = <68000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		map1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		map2 {
+			trip = <&lcd-trip>;
+			cooling-device = <&lcd0 5 10>;
+			contribution = <15>;
+		};
+	};
+};
+
+The above example is a mix of previous examples, a sensor IP with several internal
+sensors used to monitor different zones, one of them is composed by several sensors and
+with different cooling devices.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dbfc390..dd81eb8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,6 +29,19 @@ config THERMAL_HWMON
 	  Say 'Y' here if you want all thermal sensors to
 	  have hwmon sysfs interface too.
 
+config THERMAL_OF
+	bool
+	prompt "APIs to parse thermal data out of device tree"
+	depends on OF
+	default y
+	help
+	  This options provides helpers to add the support to
+	  read and parse thermal data definitions out of the
+	  device tree blob.
+
+	  Say 'Y' here if you need to build thermal infrastructure
+	  based on device tree.
+
 choice
 	prompt "Default Thermal governor"
 	default THERMAL_DEFAULT_GOV_STEP_WISE
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 584b363..4b03956 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,6 +7,7 @@ thermal_sys-y			+= thermal_core.o
 
 # interface to/from other layers providing sensors
 thermal_sys-$(CONFIG_THERMAL_HWMON)		+= thermal_hwmon.o
+thermal_sys-$(CONFIG_THERMAL_OF)		+= of-thermal.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)	+= fair_share.o
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
new file mode 100644
index 0000000..0464eaf
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,845 @@
+/*
+ *  of-thermal.c - Generic Thermal Management device tree support.
+ *
+ *  Copyright (C) 2013 Texas Instruments
+ *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ *
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/thermal.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/string.h>
+
+#include "thermal_core.h"
+
+/***   Private data structures to represent thermal device tree data ***/
+
+/**
+ * struct __thermal_trip - representation of a point in temperature domain
+ * @np: pointer to struct device_node that this trip point was created from
+ * @temperature: temperature value in miliCelsius
+ * @hysteresis: relative hysteresis in miliCelsius
+ * @type: trip point type
+ */
+
+struct __thermal_trip {
+	struct device_node *np;
+	unsigned long int temperature;
+	unsigned long int hysteresis;
+	enum thermal_trip_type type;
+};
+
+/**
+ * struct __thermal_bind_param - a match between trip and cooling device
+ * @cooling_device: a pointer to identify the referred cooling device
+ * @trip_id: the trip point index
+ * @usage: the percentage (from 0 to 100) of cooling contribution
+ * @min: minimum cooling state used at this trip point
+ * @max: maximum cooling state used at this trip point
+ */
+
+struct __thermal_bind_params {
+	struct device_node *cooling_device;
+	unsigned int trip_id;
+	unsigned int usage;
+	unsigned long min;
+	unsigned long max;
+};
+
+/**
+ * struct __thermal_zone - internal representation of a thermal zone
+ * @mode: current thermal zone device mode (enabled/disabled)
+ * @passive_delay: polling interval while passive cooling is activated
+ * @polling_delay: zone polling interval
+ * @ntrips: number of trip points
+ * @trips: an array of trip points (0..ntrips - 1)
+ * @num_tbps: number of thermal bind params
+ * @tbps: an array of thermal bind params (0..num_tbps - 1)
+ * @sensor_data: sensor private data used while reading temperature and trend
+ * @get_temp: sensor callback to read temperature
+ * @get_trend: sensor callback to read temperature trend
+ */
+
+struct __thermal_zone {
+	enum thermal_device_mode mode;
+	int passive_delay;
+	int polling_delay;
+
+	/* trip data */
+	int ntrips;
+	struct __thermal_trip *trips;
+
+	/* cooling binding data */
+	int num_tbps;
+	struct __thermal_bind_params *tbps;
+
+	/* sensor interface */
+	void *sensor_data;
+	int (*get_temp)(void *, long *);
+	int (*get_trend)(void *, long *);
+};
+
+/***   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;
+
+	if (!data->get_temp)
+		return -EINVAL;
+
+	return data->get_temp(data->sensor_data, temp);
+}
+
+static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
+				enum thermal_trend *trend)
+{
+	struct __thermal_zone *data = tz->devdata;
+	long dev_trend;
+	int r;
+
+	if (!data->get_trend)
+		return -EINVAL;
+
+	r = data->get_trend(data->sensor_data, &dev_trend);
+	if (r)
+		return r;
+
+	/* TODO: These intervals might have some thresholds, but in core code */
+	if (dev_trend > 0)
+		*trend = THERMAL_TREND_RAISING;
+	else if (dev_trend < 0)
+		*trend = THERMAL_TREND_DROPPING;
+	else
+		*trend = THERMAL_TREND_STABLE;
+
+	return 0;
+}
+
+static int of_thermal_bind(struct thermal_zone_device *thermal,
+			   struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to bind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_bind_cooling_device(thermal,
+						tbp->trip_id, cdev,
+						tbp->min,
+						tbp->max);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_unbind(struct thermal_zone_device *thermal,
+			     struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to unbind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_unbind_cooling_device(thermal,
+						tbp->trip_id, cdev);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_get_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode *mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	*mode = data->mode;
+
+	return 0;
+}
+
+static int of_thermal_set_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	mutex_lock(&tz->lock);
+
+	if (mode == THERMAL_DEVICE_ENABLED)
+		tz->polling_delay = data->polling_delay;
+	else
+		tz->polling_delay = 0;
+
+	mutex_unlock(&tz->lock);
+
+	data->mode = mode;
+	thermal_zone_device_update(tz);
+
+	return 0;
+}
+
+static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
+				    enum thermal_trip_type *type)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*type = data->trips[trip].type;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*temp = data->trips[trip].temperature;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal fw should take care of data->mask & (1 << trip) */
+	data->trips[trip].temperature = temp;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long *hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*hyst = data->trips[trip].hysteresis;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal fw should take care of data->mask & (1 << trip) */
+	data->trips[trip].hysteresis = hyst;
+
+	return 0;
+}
+
+static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+	int i;
+
+	for (i = 0; i < data->ntrips; i++)
+		if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
+			*temp = data->trips[i].temperature;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+
+static struct thermal_zone_device_ops of_thermal_ops = {
+	.get_mode = of_thermal_get_mode,
+	.set_mode = of_thermal_set_mode,
+
+	.get_trip_type = of_thermal_get_trip_type,
+	.get_trip_temp = of_thermal_get_trip_temp,
+	.set_trip_temp = of_thermal_set_trip_temp,
+	.get_trip_hyst = of_thermal_get_trip_hyst,
+	.set_trip_hyst = of_thermal_set_trip_hyst,
+	.get_crit_temp = of_thermal_get_crit_temp,
+
+	.bind = of_thermal_bind,
+	.unbind = of_thermal_unbind,
+};
+
+/***   sensor API   ***/
+
+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 *))
+{
+	struct thermal_zone_device *tzd;
+	struct __thermal_zone *tz;
+
+	tzd = thermal_zone_get_zone_by_name(zone->name);
+	if (IS_ERR(tzd))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	tz = tzd->devdata;
+
+	mutex_lock(&tzd->lock);
+	tz->get_temp = get_temp;
+	tz->get_trend = get_trend;
+	tz->sensor_data = data;
+
+	tzd->ops->get_temp = of_thermal_get_temp;
+	tzd->ops->get_trend = of_thermal_get_trend;
+	mutex_unlock(&tzd->lock);
+
+	return tzd;
+}
+
+/**
+ * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *             than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *        back, when a temperature reading is needed.
+ * @get_temp: a pointer to a function that reads the sensor temperature.
+ * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ *
+ * This function will search the list of thermal zones described in device
+ * tree and look for the zone that refer to the sensor device pointed by
+ * @dev->of_node as temperature providers. For the zone pointing to the
+ * sensor node, the sensor will be added to the DT thermal zone device.
+ *
+ * The thermal zone temperature is provided by the @get_temp function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * The thermal zone temperature trend is provided by the @get_trend function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * TODO:
+ * 01 - This function must enqueue the new sensor instead of using
+ * it as the only source of temperature values.
+ *
+ * 02 - There must be a way to match the sensor with all thermal zones
+ * that refer to it.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+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 *))
+{
+	struct device_node *np, *child, *sensor_np;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np)
+		return ERR_PTR(-ENODEV);
+
+	if (!dev || !dev->of_node)
+		return ERR_PTR(-EINVAL);
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret, id;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "thermal-sensors",
+						 "#thermal-sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			id = 0;
+		else
+			id = sensor_specs.args[0];
+
+		if (sensor_specs.np == sensor_np && id == sensor_id) {
+			of_node_put(np);
+			return thermal_zone_of_add_sensor(child, sensor_np,
+							  data,
+							  get_temp,
+							  get_trend);
+		}
+	}
+	of_node_put(np);
+
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
+
+/**
+ * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
+ *
+ * This function removes the sensor callbacks and private data from the
+ * thermal zone device registered with thermal_zone_of_sensor_register()
+ * API. It will also silent the zone by remove the .get_temp() and .get_trend()
+ * thermal zone device callbacks.
+ *
+ * TODO: When the support to several sensors per zone is added, this
+ * function must search the sensor list based on @dev parameter.
+ *
+ */
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tzd)
+{
+	struct __thermal_zone *tz;
+
+	if (!dev || !tzd || !tzd->devdata)
+		return;
+
+	tz = tzd->devdata;
+
+	/* no __thermal_zone, nothing to be done */
+	if (!tz)
+		return;
+
+	mutex_lock(&tzd->lock);
+	tzd->ops->get_temp = NULL;
+	tzd->ops->get_trend = NULL;
+
+	tz->get_temp = NULL;
+	tz->get_trend = NULL;
+	tz->sensor_data = NULL;
+	mutex_unlock(&tzd->lock);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
+
+/***   functions parsing device tree nodes   ***/
+
+/**
+ * thermal_of_populate_bind_params - parse and fill cooling map data
+ * @np: DT node containing a cooling-map node
+ * @__tbp: data structure to be filled with cooling map info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-map type of node represented by
+ * @np parameter and fills the read data into @__tbp data structure.
+ * It needs the already parsed array of trip points of the thermal zone
+ * in consideration.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_bind_params(struct device_node *np,
+					   struct __thermal_bind_params *__tbp,
+					   struct __thermal_trip *trips,
+					   int ntrips)
+{
+	struct of_phandle_args cooling_spec;
+	struct device_node *trip;
+	int ret, i;
+	u32 prop;
+
+	/* Default weight. Usage is optional */
+	__tbp->usage = 0;
+	ret = of_property_read_u32(np, "contribution", &prop);
+	if (ret == 0)
+		__tbp->usage = prop;
+
+	trip = of_parse_phandle(np, "trip", 0);
+	if (!trip) {
+		pr_err("missing trip property\n");
+		return -ENODEV;
+	}
+
+	/* match using device_node */
+	for (i = 0; i < ntrips; i++)
+		if (trip == trips[i].np) {
+			__tbp->trip_id = i;
+			break;
+		}
+
+	if (i == ntrips) {
+		ret = -ENODEV;
+		goto end;
+	}
+
+	ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
+					 0, &cooling_spec);
+	if (ret < 0) {
+		pr_err("missing cooling_device property\n");
+		goto end;
+	}
+	__tbp->cooling_device = cooling_spec.np;
+	if (cooling_spec.args_count >= 2) { /* at least min and max */
+		__tbp->min = cooling_spec.args[0];
+		__tbp->max = cooling_spec.args[1];
+	} else {
+		pr_err("wrong reference to cooling device, missing limits\n");
+	}
+
+end:
+	of_node_put(trip);
+
+	return ret;
+}
+
+/**
+ * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
+ * into the device tree binding of 'trip', property type.
+ */
+static const char * const trip_types[] = {
+	[THERMAL_TRIP_ACTIVE]	= "active",
+	[THERMAL_TRIP_PASSIVE]	= "passive",
+	[THERMAL_TRIP_HOT]	= "hot",
+	[THERMAL_TRIP_CRITICAL]	= "critical",
+};
+
+/**
+ * thermal_of_get_trip_type - Get phy mode for given device_node
+ * @np:	Pointer to the given device_node
+ * @type: Pointer to resulting trip type
+ *
+ * The function gets trip type string from property 'type',
+ * and store its index in trip_types table in @type,
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int thermal_of_get_trip_type(struct device_node *np,
+				    enum thermal_trip_type *type)
+{
+	const char *t;
+	int err, i;
+
+	err = of_property_read_string(np, "type", &t);
+	if (err < 0)
+		return err;
+
+	for (i = 0; i < ARRAY_SIZE(trip_types); i++)
+		if (!strcasecmp(t, trip_types[i])) {
+			*type = i;
+			return 0;
+		}
+
+	return -ENODEV;
+}
+
+/**
+ * thermal_of_populate_trip - parse and fill one trip point data
+ * @np: DT node containing a trip point node
+ * @trip: trip point data structure to be filled up
+ *
+ * This function parses a trip point type of node represented by
+ * @np parameter and fills the read data into @trip data structure.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_trip(struct device_node *np,
+				    struct __thermal_trip *trip)
+{
+	int prop;
+	int ret;
+
+	ret = of_property_read_u32(np, "temperature", &prop);
+	if (ret < 0) {
+		pr_err("missing temperature property\n");
+		return ret;
+	}
+	trip->temperature = prop;
+
+	ret = of_property_read_u32(np, "hysteresis", &prop);
+	if (ret < 0) {
+		pr_err("missing hysteresis property\n");
+		return ret;
+	}
+	trip->hysteresis = prop;
+
+	ret = thermal_of_get_trip_type(np, &trip->type);
+	if (ret < 0) {
+		pr_err("wrong trip type property\n");
+		return ret;
+	}
+
+	/* Required for cooling map matching */
+	trip->np = np;
+
+	return 0;
+}
+
+/**
+ * thermal_of_build_thermal_zone - parse and fill one thermal zone data
+ * @np: DT node containing a thermal zone node
+ *
+ * This function parses a thermal zone type of node represented by
+ * @np parameter and fills the read data into a __thermal_zone data structure
+ * and return this pointer.
+ *
+ * TODO: Missing properties to parse: thermal-sensor-names and coefficients
+ *
+ * Return: On success returns a valid struct __thermal_zone,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+static struct __thermal_zone *
+thermal_of_build_thermal_zone(struct device_node *np)
+{
+	struct device_node *child = NULL, *gchild;
+	struct __thermal_zone *tz;
+	int ret, i;
+	u32 prop;
+
+	if (!np) {
+		pr_err("no thermal zone np\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
+	if (!tz)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "polling-delay-passive", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay-passive property\n");
+		goto free_tz;
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay property\n");
+		goto free_tz;
+	}
+	tz->polling_delay = prop;
+
+	/* trips */
+	child = of_get_child_by_name(np, "trips");
+
+	/* No trips provided */
+	if (!child)
+		goto finish;
+
+	tz->ntrips = of_get_child_count(child);
+	if (tz->ntrips == 0) /* must have at least one child */
+		goto finish;
+
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips) {
+		ret = -ENOMEM;
+		goto free_tz;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild) {
+		ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
+		if (ret)
+			goto free_trips;
+	}
+
+	of_node_put(child);
+
+	/* cooling-maps */
+	child = of_get_child_by_name(np, "cooling-maps");
+
+	/* cooling-maps not provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	if (tz->num_tbps == 0)
+		goto finish;
+
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps) {
+		ret = -ENOMEM;
+		goto free_trips;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						      tz->trips, tz->ntrips);
+		if (ret)
+			goto free_tbps;
+
+finish:
+	of_node_put(child);
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+
+free_tbps:
+	kfree(tz->tbps);
+free_trips:
+	kfree(tz->trips);
+free_tz:
+	kfree(tz);
+	of_node_put(child);
+
+	return ERR_PTR(ret);
+}
+
+static inline void of_thermal_free_zone(struct __thermal_zone *tz)
+{
+	kfree(tz->tbps);
+	kfree(tz->trips);
+	kfree(tz);
+}
+
+/**
+ * of_parse_thermal_zones - parse device tree thermal data
+ *
+ * Initialization function that can be called by machine initialization
+ * code to parse thermal data and populate the thermal framework
+ * with hardware thermal zones info. This function only parses thermal zones.
+ * Cooling devices and sensor devices nodes are supposed to be parsed
+ * by their respective drivers.
+ *
+ * Return: 0 on success, proper error code otherwise
+ *
+ */
+int __init of_parse_thermal_zones(void)
+{
+	struct device_node *np, *child;
+	struct __thermal_zone *tz;
+	struct thermal_zone_device_ops *ops;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_debug("unable to find thermal zones\n");
+		return 0; /* Run successfully on systems without thermal DT */
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+		struct thermal_zone_params *tzp;
+
+		tz = thermal_of_build_thermal_zone(child);
+		if (IS_ERR(tz)) {
+			pr_err("failed to build thermal zone %s: %ld\n",
+			       child->name,
+			       PTR_ERR(tz));
+			continue;
+		}
+
+		ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			goto exit_free;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp) {
+			kfree(ops);
+			goto exit_free;
+		}
+
+		/* No hwmon because there might be hwmon drivers registering */
+		tzp->no_hwmon = true;
+
+		zone = thermal_zone_device_register(child->name, tz->ntrips,
+						    0, tz,
+						    ops, tzp,
+						    tz->passive_delay,
+						    tz->polling_delay);
+		if (IS_ERR(zone)) {
+			pr_err("Failed to build %s zone %ld\n", child->name,
+			       PTR_ERR(zone));
+			kfree(tzp);
+			kfree(ops);
+			of_thermal_free_zone(tz);
+			/* attempting to build remaining zones still */
+		}
+	}
+
+	return 0;
+
+exit_free:
+	of_thermal_free_zone(tz);
+
+	/* no memory available, so free what we have built */
+	of_thermal_destroy_zones();
+
+	return -ENOMEM;
+}
+
+/**
+ * of_thermal_destroy_zones - remove all zones parsed and allocated resources
+ *
+ * Finds all zones parsed and added to the thermal framework and remove them
+ * from the system, together with their resources.
+ *
+ */
+void __exit of_thermal_destroy_zones(void)
+{
+	struct device_node *np, *child;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_err("unable to find thermal zones\n");
+		return;
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+
+		zone = thermal_zone_get_zone_by_name(child->name);
+		if (IS_ERR(zone))
+			continue;
+
+		thermal_zone_device_unregister(zone);
+		kfree(zone->tzp);
+		kfree(zone->ops);
+		of_thermal_free_zone(zone->devdata);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index f7a9f4f..fec3351 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
  */
 struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	int trips, int mask, void *devdata,
-	const struct thermal_zone_device_ops *ops,
+	struct thermal_zone_device_ops *ops,
 	const struct thermal_zone_params *tzp,
 	int passive_delay, int polling_delay)
 {
@@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
 	if (result)
 		goto unregister_class;
 
+	result = of_parse_thermal_zones();
+	if (result)
+		goto exit_netlink;
+
 	return 0;
 
+exit_netlink:
+	genetlink_exit();
 unregister_governors:
 	thermal_unregister_governors();
 unregister_class:
@@ -1768,6 +1774,7 @@ error:
 
 static void __exit thermal_exit(void)
 {
+	of_thermal_destroy_zones();
 	genetlink_exit();
 	class_unregister(&thermal_class);
 	thermal_unregister_governors();
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 7cf2f66..3db339f 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
 static inline void thermal_gov_user_space_unregister(void) {}
 #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
 
+/* device tree support */
+#ifdef CONFIG_THERMAL_OF
+int of_parse_thermal_zones(void);
+void of_thermal_destroy_zones(void);
+#else
+static inline int of_parse_thermal_zones(void) { return 0; }
+static inline void of_thermal_destroy_zones(void) { }
+#endif
+
 #endif /* __THERMAL_CORE_H__ */
diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
new file mode 100644
index 0000000..59c4581
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal.h
@@ -0,0 +1,27 @@
+/*
+ * This header provides constants for most thermal bindings.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *	Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
+#define _DT_BINDINGS_THERMAL_THERMAL_H
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE		"active"
+#define THERMAL_TRIP_PASSIVE		"passive"
+#define THERMAL_TRIP_HOT		"hot"
+#define THERMAL_TRIP_CRITICAL		"critical"
+
+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT		(-1UL)
+
+#endif
+
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b268d3c..b780c5b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -143,6 +143,7 @@ struct thermal_cooling_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
 	struct device device;
+	struct device_node *np;
 	void *devdata;
 	const struct thermal_cooling_device_ops *ops;
 	bool updated; /* true if the cooling device does not need update */
@@ -172,7 +173,7 @@ struct thermal_zone_device {
 	int emul_temperature;
 	int passive;
 	unsigned int forced_passive;
-	const struct thermal_zone_device_ops *ops;
+	struct thermal_zone_device_ops *ops;
 	const struct thermal_zone_params *tzp;
 	struct thermal_governor *governor;
 	struct list_head thermal_instances;
@@ -242,8 +243,31 @@ struct thermal_genl_event {
 };
 
 /* Function declarations */
+#ifdef CONFIG_THERMAL_OF
+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 *));
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz);
+#else
+static inline 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 *))
+{
+	return NULL;
+}
+
+static inline
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz)
+{
+}
+
+#endif
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
-		void *, const struct thermal_zone_device_ops *,
+		void *, struct thermal_zone_device_ops *,
 		const struct thermal_zone_params *, int, int);
 void thermal_zone_device_unregister(struct thermal_zone_device *);
 
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv7 03/18] thermal: introduce device tree parser
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---

Hello folks,

For those interested on this work, here is a short changelog from v6:
- Reviewed binding documentation and added type and size on all properties
- Described 'thermal-zones' node in binding documentation
- Using now cooling state terminology instead of cooling level
- Renamed milliCelsius to millicelsius
- Renamed cooling-attachments to 'cooling-maps'
- Renamed sensor to thermal sensor
- Renamed #sensor-cells to #thermal-sensor-cells
- #thermal-sensor-cells now is allowed to be 0
- Renamed 'sensors' property to 'thermal-sensors'
- Changed trip type property to be now string and documented possible values
- Described better the cooling properties
- Now parses 'contribution' instead of 'usage'
- Renamed cdev to cooling device
- Renamed 'passive-delay' property to 'polling-delay-passive'
- Fixed a couple of error messages to match the property name
- Fixed a binding issue while using cpufreq as module
- Reworked thermal_of_build_thermal_zone function so that it frees
requested memory if something goes wrong and checks for sub-nodes
with zero children.

---
 .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |   9 +-
 drivers/thermal/thermal_core.h                     |   9 +
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/thermal.h                            |  28 +-
 8 files changed, 1466 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..3dbc017
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,537 @@
+* Thermal Framework Device Tree descriptor
+
+Generic binding to provide a way of defining hardware thermal
+structure using device tree. A thermal structure includes thermal
+zones and their components, such as trip points, polling intervals,
+sensors and cooling devices binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling maps: used to describe links between trip points and
+cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+Note: This binding is a working in progress.
+
+* Thermal sensor devices
+
+Thermal sensor devices are nodes providing temperature sensing capabilities on
+thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
+nodes providing temperature data to thermal zones. Thermal sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #thermal-sensor-cells: Used to provide sensor device specific information
+  Type: unsigned	 while referring to it. Typically 0, on thermal sensor
+  Size: one cell	 nodes with only one sensor, and at least 1 on nodes
+			 with several internal sensors, in order
+			 to identify uniquely the sensor instances within
+			 the IC. See thermal zone binding for more details
+			 on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. A typical passive cooling is a CPU that has dynamic voltage and
+frequency scaling, and uses lower frequencies as cooling states.
+Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the state of cooling in which the device is.
+
+Required property:
+- cooling-min-state:	An integer indicating the smallest
+  Type: unsigned	cooling state accepted. Typically 0.
+  Size: one cell
+
+- cooling-max-state:	An integer indicating the largest
+  Type: unsigned	cooling state accepted.
+  Size: one cell
+
+- #cooling-cells:	Used to provide cooling device specific information
+  Type: unsigned	while referring to it. Must be at least 2, in order
+  Size: one cell      	to specify minimum and maximum cooling state used
+			in the reference. The first cell is the minimum
+			cooling state requested and the second cell is
+			the maximum cooling state requested in the reference.
+			See Cooling device maps section below for more details
+			on how consumers refer to cooling devices.
+
+* Trip points
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+Required properties:
+- temperature:		An integer indicating the trip temperature level,
+  Type: signed		in millicelsius.
+  Size: one cell
+
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+  Type: unsigned	relative value, in millicelsius.
+  Size: one cell
+
+- type:			a string containing the trip type. Supported values are:
+	"active":	A trip point to enable active cooling
+	"passive":	A trip point to enable passive cooling
+	"hot":		A trip point to notify emergency
+	"critical":	Hardware not reliable.
+  Type: string
+
+There are also string constants defined at
+include/dt-bindings/thermal/thermal.h.
+
+* Cooling device maps
+
+The cooling device maps node is a node to describe how cooling devices
+get assigned to trip points of the zone. The cooling devices are expected
+to be loaded in the target system.
+
+Required properties:
+- cooling-device:	A phandle of a cooling device with its specifier,
+  Type: phandle		referring to which cooling device is used in this
+			binding. The required specifiers are: the minimum
+			cooling state and the maximum cooling level used
+			in this map.
+- trip:			A phandle of a trip point node within the same thermal
+  Type: phandle		zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+  Type: unsigned	referred cooling device at the referred trip point.
+  Size: one cell      	The contribution is a ratio of the sum
+			of all cooling contributions within a thermal zone.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit specifier means:
+(i)   - minimum state allowed for minimum cooling level used in the reference.
+(ii)  - maximum state allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zone nodes
+
+The thermal zone node is the node containing all the required info
+for describing a thermal zone, including its cooling device bindings. The
+thermal zone node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone cooling maps.
+
+Required properties:
+- polling-delay-passive:	The maximum number of milliseconds to wait
+  Type: unsigned		between polls when performing passive cooling.
+  Size: one cell
+
+- polling-delay:	The maximum number of milliseconds to wait between polls
+  Type: unsigned	when checking this thermal zone.
+  Size: one cell
+
+- thermal-sensors:		A list of sensor phandles and sensor specifier
+  Type: list of phandles	used while monitoring the thermal zone.
+
+- trips:		A sub-node which is a container of only trip point nodes
+  Type: sub-node	required to describe the thermal zone.
+
+- cooling-maps:		A sub-node which is a container of only cooling device
+  Type: sub-node	map nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- thermal-sensors-names:	List of thermal sensor name strings sorted
+  Type: list of strings		in the same order as the thermal-sensors
+				property.
+
+- coefficients:		An array of integers (one signed cell) containing
+  Type: array		coefficients to compose a linear relation between
+  Elem size: one cell	the sensors described in the thermal-sensors property.
+  Elem type: signed	Coefficients defaults to 1, in case this property
+			is not specified. A simple linear polynomial is used:
+			Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
+
+			The coefficients are ordered and they match with sensors
+			by means of sensor ID. Additional coefficients are
+			interpreted as constant offsets.
+
+Note: The delay properties are bound to the maximum dT/dt (temperature
+derivative over time) in two situations for a thermal zone:
+(i)  - when active cooling is activated (polling-delay-passive); and
+(ii) - when the zone just needs to be monitored (polling-delay).
+The maximum dT/dt is highly bound to hardware power consumption and dissipation
+capability.
+The delays are chosen to account for said max dT/dt, such that a device
+does not cross several trip boundaries unexpectedly between polls. Choosing
+the right polling delays shall avoid having the device in temperature ranges
+that may damage the silicon structures and reduce silicon lifetime.
+
+* The thermal-zones node
+
+The "thermal-zones" node is a container for all thermal zone nodes. It shall
+contain only sub-nodes describing thermal zones as in the section
+"Thermal zone nodes".
+
+* Examples
+
+Below are several examples on how to use thermal data descriptors
+using device tree bindings:
+
+(a) - CPU thermal zone
+
+The CPU thermal zone example below describes how to setup one thermal zone
+using one single sensor as temperature source and many cooling devices and
+power dissipation control sources.
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpus {
+	cpu0: cpu@0 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <0>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0>;
+
+        trips {
+                cpu-alert0: cpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_ACTIVE;
+                };
+                cpu-alert1: cpu-alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu-crit: cpu-crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		map1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		map2 {
+			trip = <&cpu-alert1>;
+			cooling-device +				<&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+		};
+	};
+};
+
+In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
+the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
+via I2C bus 1, at adress 0x48, which has ten different cooling states.
+It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
+cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
+at 90C, as an example of active cooling. The same cooling device is used at
+'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
+using all its cooling states at trip point 'cpu-alert1',
+which is a trip point at 100C.
+
+(b) - IC with several internal sensors
+
+The example below describes how to deploy several thermal zones based off a
+single sensor IC, assuming it has several internal sensors. This is a common
+case on SoC designs with several internal IPs that may need different thermal
+requirements, and thus may have their own sensor to monitor or detect internal
+hotspots in their silicon.
+
+#include <dt-bindings/thermal/thermal.h>
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        thermal-sensors = <&bandgap0     0>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                cpu-alert: cpu-alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu-crit: cpu-crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	polling-delay-passive = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0     1>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                gpu-alert: gpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                gpu-crit: gpu-crit {
+                        temperature = <105000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	polling-delay-passive = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        thermal-sensors = <&bandgap0     2>;
+
+        trips {
+		/* each zone within the SoC may have its own trips */
+                dsp-alert: gpu-alert {
+                        temperature = <90000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                dsp-crit: gpu-crit {
+                        temperature = <135000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+In the example above there is one bandgap IC which has the capability to
+monitor three sensors. The hardware has been designed so that sensors are
+placed on different places in the DIE to monitor different temperature
+hotspots: one for CPU thermal zone, one for GPU thermal zone and the
+other to monitor a DSP thermal zone.
+
+Thus, there is a need to assign each sensor provided by the bandgap IC
+to different thermal zones. This is achieved by means of using the
+#thermal-sensor-cells property and using the first specifier as sensor ID.
+In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,
+bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
+is used to monitor DSP thermal zone. Each zone may be uncorrelated,
+having its own dT/dt requirements, trips and cooling maps.
+
+
+(c) - Several sensors within one single thermal zone
+
+The example below illustrates how to use more than one sensor within
+one thermal zone.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	adc: sensor@0x49 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#thermal-sensor-cells = <0>;
+};
+
+cpu-thermal: cpu-thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap0>,
+			  <&adc>;
+	thermal-sensors-names = "cpu", "pcb north";
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-maps {
+		...
+	};
+};
+
+In some cases, there is a need to use more than one sensor to extrapolate
+a thermal hotspot in the silicon. The above example illustrate this situation.
+For instance, it may be the case that a sensor external to CPU IP may be place
+close to CPU hotspot and together with internal CPU sensor, it is used
+to determine the hotspot. The hyppotetical extrapolation rule would be:
+		hotspot = 100 * bandgap - 120 * adc + 484
+
+The same idea can be used to add fixed offset:
+	polling-delay-passive = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+		hotspot = 1 * adc + 6000
+
+In the above equation, the hotspot is always 6C higher than what is read
+from the sensor ADC. The binding would be then:
+			/* sensor       ID */
+        thermal-sensors =  <&adc	0>;
+
+		/* hotspot = 1 * adc + 6000 */
+	coefficients = 		<1	6000>;
+
+(d) - Board thermal
+
+The board thermal example below illustrates how to setup one thermal zone
+with many sensors and many cooling devices.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	adc-dummy: sensor@0x50 {
+		...
+		#thermal-sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	polling-delay-passive = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-maps {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	polling-delay-passive = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&adc-dummy     0>,
+			  <&adc-dummy     1>,
+			  <&adc-dymmy     2>;
+	thermal-sensors-names = "pcb top edge", "lcd", "back cover";
+			/*
+			 * An array of coefficients describing the sensor
+			 * linear relation. E.g.:
+			 * z = c1*x1 + c2*x2 + c3*x3
+			 */
+	coefficients =		<1200	-345	890>;
+
+	trips {
+		/* Trips are based on resulting linear equation */
+		cpu-trip: cpu-trip {
+			temperature = <60000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		};
+		gpu-trip: gpu-trip {
+			temperature = <55000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		}
+		lcd-trip: lcp-trip {
+			temperature = <53000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_PASSIVE;
+		};
+		crit-trip: crit-trip {
+			temperature = <68000>; /* millicelsius */
+			hysteresis = <2000>; /* millicelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		map1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		map2 {
+			trip = <&lcd-trip>;
+			cooling-device = <&lcd0 5 10>;
+			contribution = <15>;
+		};
+	};
+};
+
+The above example is a mix of previous examples, a sensor IP with several internal
+sensors used to monitor different zones, one of them is composed by several sensors and
+with different cooling devices.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dbfc390..dd81eb8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,6 +29,19 @@ config THERMAL_HWMON
 	  Say 'Y' here if you want all thermal sensors to
 	  have hwmon sysfs interface too.
 
+config THERMAL_OF
+	bool
+	prompt "APIs to parse thermal data out of device tree"
+	depends on OF
+	default y
+	help
+	  This options provides helpers to add the support to
+	  read and parse thermal data definitions out of the
+	  device tree blob.
+
+	  Say 'Y' here if you need to build thermal infrastructure
+	  based on device tree.
+
 choice
 	prompt "Default Thermal governor"
 	default THERMAL_DEFAULT_GOV_STEP_WISE
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 584b363..4b03956 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,6 +7,7 @@ thermal_sys-y			+= thermal_core.o
 
 # interface to/from other layers providing sensors
 thermal_sys-$(CONFIG_THERMAL_HWMON)		+= thermal_hwmon.o
+thermal_sys-$(CONFIG_THERMAL_OF)		+= of-thermal.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)	+= fair_share.o
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
new file mode 100644
index 0000000..0464eaf
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,845 @@
+/*
+ *  of-thermal.c - Generic Thermal Management device tree support.
+ *
+ *  Copyright (C) 2013 Texas Instruments
+ *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ *
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/thermal.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/string.h>
+
+#include "thermal_core.h"
+
+/***   Private data structures to represent thermal device tree data ***/
+
+/**
+ * struct __thermal_trip - representation of a point in temperature domain
+ * @np: pointer to struct device_node that this trip point was created from
+ * @temperature: temperature value in miliCelsius
+ * @hysteresis: relative hysteresis in miliCelsius
+ * @type: trip point type
+ */
+
+struct __thermal_trip {
+	struct device_node *np;
+	unsigned long int temperature;
+	unsigned long int hysteresis;
+	enum thermal_trip_type type;
+};
+
+/**
+ * struct __thermal_bind_param - a match between trip and cooling device
+ * @cooling_device: a pointer to identify the referred cooling device
+ * @trip_id: the trip point index
+ * @usage: the percentage (from 0 to 100) of cooling contribution
+ * @min: minimum cooling state used at this trip point
+ * @max: maximum cooling state used at this trip point
+ */
+
+struct __thermal_bind_params {
+	struct device_node *cooling_device;
+	unsigned int trip_id;
+	unsigned int usage;
+	unsigned long min;
+	unsigned long max;
+};
+
+/**
+ * struct __thermal_zone - internal representation of a thermal zone
+ * @mode: current thermal zone device mode (enabled/disabled)
+ * @passive_delay: polling interval while passive cooling is activated
+ * @polling_delay: zone polling interval
+ * @ntrips: number of trip points
+ * @trips: an array of trip points (0..ntrips - 1)
+ * @num_tbps: number of thermal bind params
+ * @tbps: an array of thermal bind params (0..num_tbps - 1)
+ * @sensor_data: sensor private data used while reading temperature and trend
+ * @get_temp: sensor callback to read temperature
+ * @get_trend: sensor callback to read temperature trend
+ */
+
+struct __thermal_zone {
+	enum thermal_device_mode mode;
+	int passive_delay;
+	int polling_delay;
+
+	/* trip data */
+	int ntrips;
+	struct __thermal_trip *trips;
+
+	/* cooling binding data */
+	int num_tbps;
+	struct __thermal_bind_params *tbps;
+
+	/* sensor interface */
+	void *sensor_data;
+	int (*get_temp)(void *, long *);
+	int (*get_trend)(void *, long *);
+};
+
+/***   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;
+
+	if (!data->get_temp)
+		return -EINVAL;
+
+	return data->get_temp(data->sensor_data, temp);
+}
+
+static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
+				enum thermal_trend *trend)
+{
+	struct __thermal_zone *data = tz->devdata;
+	long dev_trend;
+	int r;
+
+	if (!data->get_trend)
+		return -EINVAL;
+
+	r = data->get_trend(data->sensor_data, &dev_trend);
+	if (r)
+		return r;
+
+	/* TODO: These intervals might have some thresholds, but in core code */
+	if (dev_trend > 0)
+		*trend = THERMAL_TREND_RAISING;
+	else if (dev_trend < 0)
+		*trend = THERMAL_TREND_DROPPING;
+	else
+		*trend = THERMAL_TREND_STABLE;
+
+	return 0;
+}
+
+static int of_thermal_bind(struct thermal_zone_device *thermal,
+			   struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to bind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device = cdev->np) {
+			int ret;
+
+			ret = thermal_zone_bind_cooling_device(thermal,
+						tbp->trip_id, cdev,
+						tbp->min,
+						tbp->max);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_unbind(struct thermal_zone_device *thermal,
+			     struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to unbind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device = cdev->np) {
+			int ret;
+
+			ret = thermal_zone_unbind_cooling_device(thermal,
+						tbp->trip_id, cdev);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_get_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode *mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	*mode = data->mode;
+
+	return 0;
+}
+
+static int of_thermal_set_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	mutex_lock(&tz->lock);
+
+	if (mode = THERMAL_DEVICE_ENABLED)
+		tz->polling_delay = data->polling_delay;
+	else
+		tz->polling_delay = 0;
+
+	mutex_unlock(&tz->lock);
+
+	data->mode = mode;
+	thermal_zone_device_update(tz);
+
+	return 0;
+}
+
+static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
+				    enum thermal_trip_type *type)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*type = data->trips[trip].type;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*temp = data->trips[trip].temperature;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal fw should take care of data->mask & (1 << trip) */
+	data->trips[trip].temperature = temp;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long *hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*hyst = data->trips[trip].hysteresis;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal fw should take care of data->mask & (1 << trip) */
+	data->trips[trip].hysteresis = hyst;
+
+	return 0;
+}
+
+static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+	int i;
+
+	for (i = 0; i < data->ntrips; i++)
+		if (data->trips[i].type = THERMAL_TRIP_CRITICAL) {
+			*temp = data->trips[i].temperature;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+
+static struct thermal_zone_device_ops of_thermal_ops = {
+	.get_mode = of_thermal_get_mode,
+	.set_mode = of_thermal_set_mode,
+
+	.get_trip_type = of_thermal_get_trip_type,
+	.get_trip_temp = of_thermal_get_trip_temp,
+	.set_trip_temp = of_thermal_set_trip_temp,
+	.get_trip_hyst = of_thermal_get_trip_hyst,
+	.set_trip_hyst = of_thermal_set_trip_hyst,
+	.get_crit_temp = of_thermal_get_crit_temp,
+
+	.bind = of_thermal_bind,
+	.unbind = of_thermal_unbind,
+};
+
+/***   sensor API   ***/
+
+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 *))
+{
+	struct thermal_zone_device *tzd;
+	struct __thermal_zone *tz;
+
+	tzd = thermal_zone_get_zone_by_name(zone->name);
+	if (IS_ERR(tzd))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	tz = tzd->devdata;
+
+	mutex_lock(&tzd->lock);
+	tz->get_temp = get_temp;
+	tz->get_trend = get_trend;
+	tz->sensor_data = data;
+
+	tzd->ops->get_temp = of_thermal_get_temp;
+	tzd->ops->get_trend = of_thermal_get_trend;
+	mutex_unlock(&tzd->lock);
+
+	return tzd;
+}
+
+/**
+ * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *             than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *        back, when a temperature reading is needed.
+ * @get_temp: a pointer to a function that reads the sensor temperature.
+ * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ *
+ * This function will search the list of thermal zones described in device
+ * tree and look for the zone that refer to the sensor device pointed by
+ * @dev->of_node as temperature providers. For the zone pointing to the
+ * sensor node, the sensor will be added to the DT thermal zone device.
+ *
+ * The thermal zone temperature is provided by the @get_temp function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * The thermal zone temperature trend is provided by the @get_trend function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * TODO:
+ * 01 - This function must enqueue the new sensor instead of using
+ * it as the only source of temperature values.
+ *
+ * 02 - There must be a way to match the sensor with all thermal zones
+ * that refer to it.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+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 *))
+{
+	struct device_node *np, *child, *sensor_np;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np)
+		return ERR_PTR(-ENODEV);
+
+	if (!dev || !dev->of_node)
+		return ERR_PTR(-EINVAL);
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret, id;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "thermal-sensors",
+						 "#thermal-sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			id = 0;
+		else
+			id = sensor_specs.args[0];
+
+		if (sensor_specs.np = sensor_np && id = sensor_id) {
+			of_node_put(np);
+			return thermal_zone_of_add_sensor(child, sensor_np,
+							  data,
+							  get_temp,
+							  get_trend);
+		}
+	}
+	of_node_put(np);
+
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
+
+/**
+ * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
+ *
+ * This function removes the sensor callbacks and private data from the
+ * thermal zone device registered with thermal_zone_of_sensor_register()
+ * API. It will also silent the zone by remove the .get_temp() and .get_trend()
+ * thermal zone device callbacks.
+ *
+ * TODO: When the support to several sensors per zone is added, this
+ * function must search the sensor list based on @dev parameter.
+ *
+ */
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tzd)
+{
+	struct __thermal_zone *tz;
+
+	if (!dev || !tzd || !tzd->devdata)
+		return;
+
+	tz = tzd->devdata;
+
+	/* no __thermal_zone, nothing to be done */
+	if (!tz)
+		return;
+
+	mutex_lock(&tzd->lock);
+	tzd->ops->get_temp = NULL;
+	tzd->ops->get_trend = NULL;
+
+	tz->get_temp = NULL;
+	tz->get_trend = NULL;
+	tz->sensor_data = NULL;
+	mutex_unlock(&tzd->lock);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
+
+/***   functions parsing device tree nodes   ***/
+
+/**
+ * thermal_of_populate_bind_params - parse and fill cooling map data
+ * @np: DT node containing a cooling-map node
+ * @__tbp: data structure to be filled with cooling map info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-map type of node represented by
+ * @np parameter and fills the read data into @__tbp data structure.
+ * It needs the already parsed array of trip points of the thermal zone
+ * in consideration.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_bind_params(struct device_node *np,
+					   struct __thermal_bind_params *__tbp,
+					   struct __thermal_trip *trips,
+					   int ntrips)
+{
+	struct of_phandle_args cooling_spec;
+	struct device_node *trip;
+	int ret, i;
+	u32 prop;
+
+	/* Default weight. Usage is optional */
+	__tbp->usage = 0;
+	ret = of_property_read_u32(np, "contribution", &prop);
+	if (ret = 0)
+		__tbp->usage = prop;
+
+	trip = of_parse_phandle(np, "trip", 0);
+	if (!trip) {
+		pr_err("missing trip property\n");
+		return -ENODEV;
+	}
+
+	/* match using device_node */
+	for (i = 0; i < ntrips; i++)
+		if (trip = trips[i].np) {
+			__tbp->trip_id = i;
+			break;
+		}
+
+	if (i = ntrips) {
+		ret = -ENODEV;
+		goto end;
+	}
+
+	ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
+					 0, &cooling_spec);
+	if (ret < 0) {
+		pr_err("missing cooling_device property\n");
+		goto end;
+	}
+	__tbp->cooling_device = cooling_spec.np;
+	if (cooling_spec.args_count >= 2) { /* at least min and max */
+		__tbp->min = cooling_spec.args[0];
+		__tbp->max = cooling_spec.args[1];
+	} else {
+		pr_err("wrong reference to cooling device, missing limits\n");
+	}
+
+end:
+	of_node_put(trip);
+
+	return ret;
+}
+
+/**
+ * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
+ * into the device tree binding of 'trip', property type.
+ */
+static const char * const trip_types[] = {
+	[THERMAL_TRIP_ACTIVE]	= "active",
+	[THERMAL_TRIP_PASSIVE]	= "passive",
+	[THERMAL_TRIP_HOT]	= "hot",
+	[THERMAL_TRIP_CRITICAL]	= "critical",
+};
+
+/**
+ * thermal_of_get_trip_type - Get phy mode for given device_node
+ * @np:	Pointer to the given device_node
+ * @type: Pointer to resulting trip type
+ *
+ * The function gets trip type string from property 'type',
+ * and store its index in trip_types table in @type,
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int thermal_of_get_trip_type(struct device_node *np,
+				    enum thermal_trip_type *type)
+{
+	const char *t;
+	int err, i;
+
+	err = of_property_read_string(np, "type", &t);
+	if (err < 0)
+		return err;
+
+	for (i = 0; i < ARRAY_SIZE(trip_types); i++)
+		if (!strcasecmp(t, trip_types[i])) {
+			*type = i;
+			return 0;
+		}
+
+	return -ENODEV;
+}
+
+/**
+ * thermal_of_populate_trip - parse and fill one trip point data
+ * @np: DT node containing a trip point node
+ * @trip: trip point data structure to be filled up
+ *
+ * This function parses a trip point type of node represented by
+ * @np parameter and fills the read data into @trip data structure.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_trip(struct device_node *np,
+				    struct __thermal_trip *trip)
+{
+	int prop;
+	int ret;
+
+	ret = of_property_read_u32(np, "temperature", &prop);
+	if (ret < 0) {
+		pr_err("missing temperature property\n");
+		return ret;
+	}
+	trip->temperature = prop;
+
+	ret = of_property_read_u32(np, "hysteresis", &prop);
+	if (ret < 0) {
+		pr_err("missing hysteresis property\n");
+		return ret;
+	}
+	trip->hysteresis = prop;
+
+	ret = thermal_of_get_trip_type(np, &trip->type);
+	if (ret < 0) {
+		pr_err("wrong trip type property\n");
+		return ret;
+	}
+
+	/* Required for cooling map matching */
+	trip->np = np;
+
+	return 0;
+}
+
+/**
+ * thermal_of_build_thermal_zone - parse and fill one thermal zone data
+ * @np: DT node containing a thermal zone node
+ *
+ * This function parses a thermal zone type of node represented by
+ * @np parameter and fills the read data into a __thermal_zone data structure
+ * and return this pointer.
+ *
+ * TODO: Missing properties to parse: thermal-sensor-names and coefficients
+ *
+ * Return: On success returns a valid struct __thermal_zone,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+static struct __thermal_zone *
+thermal_of_build_thermal_zone(struct device_node *np)
+{
+	struct device_node *child = NULL, *gchild;
+	struct __thermal_zone *tz;
+	int ret, i;
+	u32 prop;
+
+	if (!np) {
+		pr_err("no thermal zone np\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
+	if (!tz)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "polling-delay-passive", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay-passive property\n");
+		goto free_tz;
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay property\n");
+		goto free_tz;
+	}
+	tz->polling_delay = prop;
+
+	/* trips */
+	child = of_get_child_by_name(np, "trips");
+
+	/* No trips provided */
+	if (!child)
+		goto finish;
+
+	tz->ntrips = of_get_child_count(child);
+	if (tz->ntrips = 0) /* must have at least one child */
+		goto finish;
+
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips) {
+		ret = -ENOMEM;
+		goto free_tz;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild) {
+		ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
+		if (ret)
+			goto free_trips;
+	}
+
+	of_node_put(child);
+
+	/* cooling-maps */
+	child = of_get_child_by_name(np, "cooling-maps");
+
+	/* cooling-maps not provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	if (tz->num_tbps = 0)
+		goto finish;
+
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps) {
+		ret = -ENOMEM;
+		goto free_trips;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						      tz->trips, tz->ntrips);
+		if (ret)
+			goto free_tbps;
+
+finish:
+	of_node_put(child);
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+
+free_tbps:
+	kfree(tz->tbps);
+free_trips:
+	kfree(tz->trips);
+free_tz:
+	kfree(tz);
+	of_node_put(child);
+
+	return ERR_PTR(ret);
+}
+
+static inline void of_thermal_free_zone(struct __thermal_zone *tz)
+{
+	kfree(tz->tbps);
+	kfree(tz->trips);
+	kfree(tz);
+}
+
+/**
+ * of_parse_thermal_zones - parse device tree thermal data
+ *
+ * Initialization function that can be called by machine initialization
+ * code to parse thermal data and populate the thermal framework
+ * with hardware thermal zones info. This function only parses thermal zones.
+ * Cooling devices and sensor devices nodes are supposed to be parsed
+ * by their respective drivers.
+ *
+ * Return: 0 on success, proper error code otherwise
+ *
+ */
+int __init of_parse_thermal_zones(void)
+{
+	struct device_node *np, *child;
+	struct __thermal_zone *tz;
+	struct thermal_zone_device_ops *ops;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_debug("unable to find thermal zones\n");
+		return 0; /* Run successfully on systems without thermal DT */
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+		struct thermal_zone_params *tzp;
+
+		tz = thermal_of_build_thermal_zone(child);
+		if (IS_ERR(tz)) {
+			pr_err("failed to build thermal zone %s: %ld\n",
+			       child->name,
+			       PTR_ERR(tz));
+			continue;
+		}
+
+		ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			goto exit_free;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp) {
+			kfree(ops);
+			goto exit_free;
+		}
+
+		/* No hwmon because there might be hwmon drivers registering */
+		tzp->no_hwmon = true;
+
+		zone = thermal_zone_device_register(child->name, tz->ntrips,
+						    0, tz,
+						    ops, tzp,
+						    tz->passive_delay,
+						    tz->polling_delay);
+		if (IS_ERR(zone)) {
+			pr_err("Failed to build %s zone %ld\n", child->name,
+			       PTR_ERR(zone));
+			kfree(tzp);
+			kfree(ops);
+			of_thermal_free_zone(tz);
+			/* attempting to build remaining zones still */
+		}
+	}
+
+	return 0;
+
+exit_free:
+	of_thermal_free_zone(tz);
+
+	/* no memory available, so free what we have built */
+	of_thermal_destroy_zones();
+
+	return -ENOMEM;
+}
+
+/**
+ * of_thermal_destroy_zones - remove all zones parsed and allocated resources
+ *
+ * Finds all zones parsed and added to the thermal framework and remove them
+ * from the system, together with their resources.
+ *
+ */
+void __exit of_thermal_destroy_zones(void)
+{
+	struct device_node *np, *child;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_err("unable to find thermal zones\n");
+		return;
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+
+		zone = thermal_zone_get_zone_by_name(child->name);
+		if (IS_ERR(zone))
+			continue;
+
+		thermal_zone_device_unregister(zone);
+		kfree(zone->tzp);
+		kfree(zone->ops);
+		of_thermal_free_zone(zone->devdata);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index f7a9f4f..fec3351 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
  */
 struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	int trips, int mask, void *devdata,
-	const struct thermal_zone_device_ops *ops,
+	struct thermal_zone_device_ops *ops,
 	const struct thermal_zone_params *tzp,
 	int passive_delay, int polling_delay)
 {
@@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
 	if (result)
 		goto unregister_class;
 
+	result = of_parse_thermal_zones();
+	if (result)
+		goto exit_netlink;
+
 	return 0;
 
+exit_netlink:
+	genetlink_exit();
 unregister_governors:
 	thermal_unregister_governors();
 unregister_class:
@@ -1768,6 +1774,7 @@ error:
 
 static void __exit thermal_exit(void)
 {
+	of_thermal_destroy_zones();
 	genetlink_exit();
 	class_unregister(&thermal_class);
 	thermal_unregister_governors();
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 7cf2f66..3db339f 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
 static inline void thermal_gov_user_space_unregister(void) {}
 #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
 
+/* device tree support */
+#ifdef CONFIG_THERMAL_OF
+int of_parse_thermal_zones(void);
+void of_thermal_destroy_zones(void);
+#else
+static inline int of_parse_thermal_zones(void) { return 0; }
+static inline void of_thermal_destroy_zones(void) { }
+#endif
+
 #endif /* __THERMAL_CORE_H__ */
diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
new file mode 100644
index 0000000..59c4581
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal.h
@@ -0,0 +1,27 @@
+/*
+ * This header provides constants for most thermal bindings.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *	Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
+#define _DT_BINDINGS_THERMAL_THERMAL_H
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE		"active"
+#define THERMAL_TRIP_PASSIVE		"passive"
+#define THERMAL_TRIP_HOT		"hot"
+#define THERMAL_TRIP_CRITICAL		"critical"
+
+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT		(-1UL)
+
+#endif
+
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b268d3c..b780c5b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -143,6 +143,7 @@ struct thermal_cooling_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
 	struct device device;
+	struct device_node *np;
 	void *devdata;
 	const struct thermal_cooling_device_ops *ops;
 	bool updated; /* true if the cooling device does not need update */
@@ -172,7 +173,7 @@ struct thermal_zone_device {
 	int emul_temperature;
 	int passive;
 	unsigned int forced_passive;
-	const struct thermal_zone_device_ops *ops;
+	struct thermal_zone_device_ops *ops;
 	const struct thermal_zone_params *tzp;
 	struct thermal_governor *governor;
 	struct list_head thermal_instances;
@@ -242,8 +243,31 @@ struct thermal_genl_event {
 };
 
 /* Function declarations */
+#ifdef CONFIG_THERMAL_OF
+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 *));
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz);
+#else
+static inline 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 *))
+{
+	return NULL;
+}
+
+static inline
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz)
+{
+}
+
+#endif
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
-		void *, const struct thermal_zone_device_ops *,
+		void *, struct thermal_zone_device_ops *,
 		const struct thermal_zone_params *, int, int);
 void thermal_zone_device_unregister(struct thermal_zone_device *);
 
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 04/18] thermal: core: introduce thermal_of_cooling_device_register
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch adds a new API to allow registering cooling devices
in the thermal framework derived from device tree nodes.

This API links the cooling device with the device tree node
so that binding with thermal zones is possible, given
that thermal zones are pointing to cooling device
device tree nodes.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 58 +++++++++++++++++++++++++++++++++++++++---
 include/linux/thermal.h        |  4 +++
 2 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index fec3351..5325fee 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -34,6 +34,7 @@
 #include <linux/thermal.h>
 #include <linux/reboot.h>
 #include <linux/string.h>
+#include <linux/of.h>
 #include <net/netlink.h>
 #include <net/genetlink.h>
 
@@ -1053,7 +1054,8 @@ static struct class thermal_class = {
 };
 
 /**
- * thermal_cooling_device_register() - register a new thermal cooling device
+ * __thermal_cooling_device_register() - register a new thermal cooling device
+ * @np:		a pointer to a device tree node.
  * @type:	the thermal cooling device type.
  * @devdata:	device private data.
  * @ops:		standard thermal cooling devices callbacks.
@@ -1061,13 +1063,16 @@ static struct class thermal_class = {
  * This interface function adds a new thermal cooling device (fan/processor/...)
  * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
  * to all the thermal zone devices registered at the same time.
+ * It also gives the opportunity to link the cooling device to a device tree
+ * node, so that it can be bound to a thermal zone created out of device tree.
  *
  * Return: a pointer to the created struct thermal_cooling_device or an
  * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
  */
-struct thermal_cooling_device *
-thermal_cooling_device_register(char *type, void *devdata,
-				const struct thermal_cooling_device_ops *ops)
+static struct thermal_cooling_device *
+__thermal_cooling_device_register(struct device_node *np,
+				  char *type, void *devdata,
+				  const struct thermal_cooling_device_ops *ops)
 {
 	struct thermal_cooling_device *cdev;
 	int result;
@@ -1092,6 +1097,7 @@ thermal_cooling_device_register(char *type, void *devdata,
 	strlcpy(cdev->type, type ? : "", sizeof(cdev->type));
 	mutex_init(&cdev->lock);
 	INIT_LIST_HEAD(&cdev->thermal_instances);
+	cdev->np = np;
 	cdev->ops = ops;
 	cdev->updated = true;
 	cdev->device.class = &thermal_class;
@@ -1134,9 +1140,53 @@ unregister:
 	device_unregister(&cdev->device);
 	return ERR_PTR(result);
 }
+
+/**
+ * thermal_cooling_device_register() - register a new thermal cooling device
+ * @type:	the thermal cooling device type.
+ * @devdata:	device private data.
+ * @ops:		standard thermal cooling devices callbacks.
+ *
+ * This interface function adds a new thermal cooling device (fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_cooling_device_register(char *type, void *devdata,
+				const struct thermal_cooling_device_ops *ops)
+{
+	return __thermal_cooling_device_register(NULL, type, devdata, ops);
+}
 EXPORT_SYMBOL_GPL(thermal_cooling_device_register);
 
 /**
+ * thermal_of_cooling_device_register() - register an OF thermal cooling device
+ * @np:		a pointer to a device tree node.
+ * @type:	the thermal cooling device type.
+ * @devdata:	device private data.
+ * @ops:		standard thermal cooling devices callbacks.
+ *
+ * This function will register a cooling device with device tree node reference.
+ * This interface function adds a new thermal cooling device (fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+				   char *type, void *devdata,
+				   const struct thermal_cooling_device_ops *ops)
+{
+	return __thermal_cooling_device_register(np, type, devdata, ops);
+}
+EXPORT_SYMBOL_GPL(thermal_of_cooling_device_register);
+
+/**
  * thermal_cooling_device_unregister - removes the registered thermal cooling device
  * @cdev:	the thermal cooling device to remove.
  *
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b780c5b..f7e11c7 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -25,6 +25,7 @@
 #ifndef __THERMAL_H__
 #define __THERMAL_H__
 
+#include <linux/of.h>
 #include <linux/idr.h>
 #include <linux/device.h>
 #include <linux/workqueue.h>
@@ -280,6 +281,9 @@ void thermal_zone_device_update(struct thermal_zone_device *);
 
 struct thermal_cooling_device *thermal_cooling_device_register(char *, void *,
 		const struct thermal_cooling_device_ops *);
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np, char *, void *,
+				   const struct thermal_cooling_device_ops *);
 void thermal_cooling_device_unregister(struct thermal_cooling_device *);
 struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
 int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long *temp);
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 04/18] thermal: core: introduce thermal_of_cooling_device_register
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren-3lzwWm7+Weoh9ZMKESR00Q, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eduardo Valentin

This patch adds a new API to allow registering cooling devices
in the thermal framework derived from device tree nodes.

This API links the cooling device with the device tree node
so that binding with thermal zones is possible, given
that thermal zones are pointing to cooling device
device tree nodes.

Cc: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
---
 drivers/thermal/thermal_core.c | 58 +++++++++++++++++++++++++++++++++++++++---
 include/linux/thermal.h        |  4 +++
 2 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index fec3351..5325fee 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -34,6 +34,7 @@
 #include <linux/thermal.h>
 #include <linux/reboot.h>
 #include <linux/string.h>
+#include <linux/of.h>
 #include <net/netlink.h>
 #include <net/genetlink.h>
 
@@ -1053,7 +1054,8 @@ static struct class thermal_class = {
 };
 
 /**
- * thermal_cooling_device_register() - register a new thermal cooling device
+ * __thermal_cooling_device_register() - register a new thermal cooling device
+ * @np:		a pointer to a device tree node.
  * @type:	the thermal cooling device type.
  * @devdata:	device private data.
  * @ops:		standard thermal cooling devices callbacks.
@@ -1061,13 +1063,16 @@ static struct class thermal_class = {
  * This interface function adds a new thermal cooling device (fan/processor/...)
  * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
  * to all the thermal zone devices registered at the same time.
+ * It also gives the opportunity to link the cooling device to a device tree
+ * node, so that it can be bound to a thermal zone created out of device tree.
  *
  * Return: a pointer to the created struct thermal_cooling_device or an
  * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
  */
-struct thermal_cooling_device *
-thermal_cooling_device_register(char *type, void *devdata,
-				const struct thermal_cooling_device_ops *ops)
+static struct thermal_cooling_device *
+__thermal_cooling_device_register(struct device_node *np,
+				  char *type, void *devdata,
+				  const struct thermal_cooling_device_ops *ops)
 {
 	struct thermal_cooling_device *cdev;
 	int result;
@@ -1092,6 +1097,7 @@ thermal_cooling_device_register(char *type, void *devdata,
 	strlcpy(cdev->type, type ? : "", sizeof(cdev->type));
 	mutex_init(&cdev->lock);
 	INIT_LIST_HEAD(&cdev->thermal_instances);
+	cdev->np = np;
 	cdev->ops = ops;
 	cdev->updated = true;
 	cdev->device.class = &thermal_class;
@@ -1134,9 +1140,53 @@ unregister:
 	device_unregister(&cdev->device);
 	return ERR_PTR(result);
 }
+
+/**
+ * thermal_cooling_device_register() - register a new thermal cooling device
+ * @type:	the thermal cooling device type.
+ * @devdata:	device private data.
+ * @ops:		standard thermal cooling devices callbacks.
+ *
+ * This interface function adds a new thermal cooling device (fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_cooling_device_register(char *type, void *devdata,
+				const struct thermal_cooling_device_ops *ops)
+{
+	return __thermal_cooling_device_register(NULL, type, devdata, ops);
+}
 EXPORT_SYMBOL_GPL(thermal_cooling_device_register);
 
 /**
+ * thermal_of_cooling_device_register() - register an OF thermal cooling device
+ * @np:		a pointer to a device tree node.
+ * @type:	the thermal cooling device type.
+ * @devdata:	device private data.
+ * @ops:		standard thermal cooling devices callbacks.
+ *
+ * This function will register a cooling device with device tree node reference.
+ * This interface function adds a new thermal cooling device (fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+				   char *type, void *devdata,
+				   const struct thermal_cooling_device_ops *ops)
+{
+	return __thermal_cooling_device_register(np, type, devdata, ops);
+}
+EXPORT_SYMBOL_GPL(thermal_of_cooling_device_register);
+
+/**
  * thermal_cooling_device_unregister - removes the registered thermal cooling device
  * @cdev:	the thermal cooling device to remove.
  *
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b780c5b..f7e11c7 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -25,6 +25,7 @@
 #ifndef __THERMAL_H__
 #define __THERMAL_H__
 
+#include <linux/of.h>
 #include <linux/idr.h>
 #include <linux/device.h>
 #include <linux/workqueue.h>
@@ -280,6 +281,9 @@ void thermal_zone_device_update(struct thermal_zone_device *);
 
 struct thermal_cooling_device *thermal_cooling_device_register(char *, void *,
 		const struct thermal_cooling_device_ops *);
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np, char *, void *,
+				   const struct thermal_cooling_device_ops *);
 void thermal_cooling_device_unregister(struct thermal_cooling_device *);
 struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
 int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long *temp);
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 04/18] thermal: core: introduce thermal_of_cooling_device_register
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch adds a new API to allow registering cooling devices
in the thermal framework derived from device tree nodes.

This API links the cooling device with the device tree node
so that binding with thermal zones is possible, given
that thermal zones are pointing to cooling device
device tree nodes.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/thermal_core.c | 58 +++++++++++++++++++++++++++++++++++++++---
 include/linux/thermal.h        |  4 +++
 2 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index fec3351..5325fee 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -34,6 +34,7 @@
 #include <linux/thermal.h>
 #include <linux/reboot.h>
 #include <linux/string.h>
+#include <linux/of.h>
 #include <net/netlink.h>
 #include <net/genetlink.h>
 
@@ -1053,7 +1054,8 @@ static struct class thermal_class = {
 };
 
 /**
- * thermal_cooling_device_register() - register a new thermal cooling device
+ * __thermal_cooling_device_register() - register a new thermal cooling device
+ * @np:		a pointer to a device tree node.
  * @type:	the thermal cooling device type.
  * @devdata:	device private data.
  * @ops:		standard thermal cooling devices callbacks.
@@ -1061,13 +1063,16 @@ static struct class thermal_class = {
  * This interface function adds a new thermal cooling device (fan/processor/...)
  * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
  * to all the thermal zone devices registered at the same time.
+ * It also gives the opportunity to link the cooling device to a device tree
+ * node, so that it can be bound to a thermal zone created out of device tree.
  *
  * Return: a pointer to the created struct thermal_cooling_device or an
  * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
  */
-struct thermal_cooling_device *
-thermal_cooling_device_register(char *type, void *devdata,
-				const struct thermal_cooling_device_ops *ops)
+static struct thermal_cooling_device *
+__thermal_cooling_device_register(struct device_node *np,
+				  char *type, void *devdata,
+				  const struct thermal_cooling_device_ops *ops)
 {
 	struct thermal_cooling_device *cdev;
 	int result;
@@ -1092,6 +1097,7 @@ thermal_cooling_device_register(char *type, void *devdata,
 	strlcpy(cdev->type, type ? : "", sizeof(cdev->type));
 	mutex_init(&cdev->lock);
 	INIT_LIST_HEAD(&cdev->thermal_instances);
+	cdev->np = np;
 	cdev->ops = ops;
 	cdev->updated = true;
 	cdev->device.class = &thermal_class;
@@ -1134,9 +1140,53 @@ unregister:
 	device_unregister(&cdev->device);
 	return ERR_PTR(result);
 }
+
+/**
+ * thermal_cooling_device_register() - register a new thermal cooling device
+ * @type:	the thermal cooling device type.
+ * @devdata:	device private data.
+ * @ops:		standard thermal cooling devices callbacks.
+ *
+ * This interface function adds a new thermal cooling device (fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_cooling_device_register(char *type, void *devdata,
+				const struct thermal_cooling_device_ops *ops)
+{
+	return __thermal_cooling_device_register(NULL, type, devdata, ops);
+}
 EXPORT_SYMBOL_GPL(thermal_cooling_device_register);
 
 /**
+ * thermal_of_cooling_device_register() - register an OF thermal cooling device
+ * @np:		a pointer to a device tree node.
+ * @type:	the thermal cooling device type.
+ * @devdata:	device private data.
+ * @ops:		standard thermal cooling devices callbacks.
+ *
+ * This function will register a cooling device with device tree node reference.
+ * This interface function adds a new thermal cooling device (fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+				   char *type, void *devdata,
+				   const struct thermal_cooling_device_ops *ops)
+{
+	return __thermal_cooling_device_register(np, type, devdata, ops);
+}
+EXPORT_SYMBOL_GPL(thermal_of_cooling_device_register);
+
+/**
  * thermal_cooling_device_unregister - removes the registered thermal cooling device
  * @cdev:	the thermal cooling device to remove.
  *
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b780c5b..f7e11c7 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -25,6 +25,7 @@
 #ifndef __THERMAL_H__
 #define __THERMAL_H__
 
+#include <linux/of.h>
 #include <linux/idr.h>
 #include <linux/device.h>
 #include <linux/workqueue.h>
@@ -280,6 +281,9 @@ void thermal_zone_device_update(struct thermal_zone_device *);
 
 struct thermal_cooling_device *thermal_cooling_device_register(char *, void *,
 		const struct thermal_cooling_device_ops *);
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np, char *, void *,
+				   const struct thermal_cooling_device_ops *);
 void thermal_cooling_device_unregister(struct thermal_cooling_device *);
 struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
 int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long *temp);
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 05/18] thermal: cpu_cooling: introduce of_cpufreq_cooling_register
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces an API to register cpufreq cooling device
based on device tree node.

The registration via device tree node differs from normal
registration due to the fact that it is needed to fill
the device_node structure in order to be able to match
the cooling devices with trip points.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/Kconfig       |  1 +
 drivers/thermal/cpu_cooling.c | 56 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/cpu_cooling.h   | 25 +++++++++++++++++++
 3 files changed, 76 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dd81eb8..9e7cc3f 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -91,6 +91,7 @@ config THERMAL_GOV_USER_SPACE
 config CPU_THERMAL
 	bool "generic cpu cooling support"
 	depends on CPU_FREQ
+	depends on THERMAL_OF
 	select CPU_FREQ_TABLE
 	help
 	  This implements the generic cpu cooling mechanism through frequency
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index d179028..b7db93a 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -417,18 +417,21 @@ static struct notifier_block thermal_cpufreq_notifier_block = {
 };
 
 /**
- * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * __cpufreq_cooling_register - helper function to create cpufreq cooling device
+ * @np: a valid struct device_node to the cooling device device tree node
  * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
  *
  * This interface function registers the cpufreq cooling device with the name
  * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
- * cooling devices.
+ * cooling devices. It also gives the opportunity to link the cooling device
+ * with a device tree node, in order to bind it via the thermal DT code.
  *
  * Return: a valid struct thermal_cooling_device pointer on success,
  * on failure, it returns a corresponding ERR_PTR().
  */
-struct thermal_cooling_device *
-cpufreq_cooling_register(const struct cpumask *clip_cpus)
+static struct thermal_cooling_device *
+__cpufreq_cooling_register(struct device_node *np,
+			   const struct cpumask *clip_cpus)
 {
 	struct thermal_cooling_device *cool_dev;
 	struct cpufreq_cooling_device *cpufreq_dev = NULL;
@@ -467,8 +470,8 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 	snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
 		 cpufreq_dev->id);
 
-	cool_dev = thermal_cooling_device_register(dev_name, cpufreq_dev,
-						   &cpufreq_cooling_ops);
+	cool_dev = thermal_of_cooling_device_register(np, dev_name, cpufreq_dev,
+						      &cpufreq_cooling_ops);
 	if (!cool_dev) {
 		release_idr(&cpufreq_idr, cpufreq_dev->id);
 		kfree(cpufreq_dev);
@@ -488,9 +491,50 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 
 	return cool_dev;
 }
+
+/**
+ * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+cpufreq_cooling_register(const struct cpumask *clip_cpus)
+{
+	return __cpufreq_cooling_register(NULL, clip_cpus);
+}
 EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
 
 /**
+ * of_cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @np: a valid struct device_node to the cooling device device tree node
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices. Using this API, the cpufreq cooling device will be
+ * linked to the device tree node provided.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	if (!np)
+		return ERR_PTR(-EINVAL);
+
+	return __cpufreq_cooling_register(np, clip_cpus);
+}
+EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  *
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index a5d52ee..c303d38 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -24,6 +24,7 @@
 #ifndef __CPU_COOLING_H__
 #define __CPU_COOLING_H__
 
+#include <linux/of.h>
 #include <linux/thermal.h>
 #include <linux/cpumask.h>
 
@@ -36,6 +37,24 @@ struct thermal_cooling_device *
 cpufreq_cooling_register(const struct cpumask *clip_cpus);
 
 /**
+ * of_cpufreq_cooling_register - create cpufreq cooling device based on DT.
+ * @np: a valid struct device_node to the cooling device device tree node.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen
+ */
+#ifdef CONFIG_THERMAL_OF
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus);
+#else
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	return NULL;
+}
+#endif
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  */
@@ -48,6 +67,12 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 {
 	return NULL;
 }
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	return NULL;
+}
 static inline
 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 {
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 05/18] thermal: cpu_cooling: introduce of_cpufreq_cooling_register
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces an API to register cpufreq cooling device
based on device tree node.

The registration via device tree node differs from normal
registration due to the fact that it is needed to fill
the device_node structure in order to be able to match
the cooling devices with trip points.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/Kconfig       |  1 +
 drivers/thermal/cpu_cooling.c | 56 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/cpu_cooling.h   | 25 +++++++++++++++++++
 3 files changed, 76 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dd81eb8..9e7cc3f 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -91,6 +91,7 @@ config THERMAL_GOV_USER_SPACE
 config CPU_THERMAL
 	bool "generic cpu cooling support"
 	depends on CPU_FREQ
+	depends on THERMAL_OF
 	select CPU_FREQ_TABLE
 	help
 	  This implements the generic cpu cooling mechanism through frequency
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index d179028..b7db93a 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -417,18 +417,21 @@ static struct notifier_block thermal_cpufreq_notifier_block = {
 };
 
 /**
- * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * __cpufreq_cooling_register - helper function to create cpufreq cooling device
+ * @np: a valid struct device_node to the cooling device device tree node
  * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
  *
  * This interface function registers the cpufreq cooling device with the name
  * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
- * cooling devices.
+ * cooling devices. It also gives the opportunity to link the cooling device
+ * with a device tree node, in order to bind it via the thermal DT code.
  *
  * Return: a valid struct thermal_cooling_device pointer on success,
  * on failure, it returns a corresponding ERR_PTR().
  */
-struct thermal_cooling_device *
-cpufreq_cooling_register(const struct cpumask *clip_cpus)
+static struct thermal_cooling_device *
+__cpufreq_cooling_register(struct device_node *np,
+			   const struct cpumask *clip_cpus)
 {
 	struct thermal_cooling_device *cool_dev;
 	struct cpufreq_cooling_device *cpufreq_dev = NULL;
@@ -467,8 +470,8 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 	snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
 		 cpufreq_dev->id);
 
-	cool_dev = thermal_cooling_device_register(dev_name, cpufreq_dev,
-						   &cpufreq_cooling_ops);
+	cool_dev = thermal_of_cooling_device_register(np, dev_name, cpufreq_dev,
+						      &cpufreq_cooling_ops);
 	if (!cool_dev) {
 		release_idr(&cpufreq_idr, cpufreq_dev->id);
 		kfree(cpufreq_dev);
@@ -488,9 +491,50 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 
 	return cool_dev;
 }
+
+/**
+ * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+cpufreq_cooling_register(const struct cpumask *clip_cpus)
+{
+	return __cpufreq_cooling_register(NULL, clip_cpus);
+}
 EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
 
 /**
+ * of_cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @np: a valid struct device_node to the cooling device device tree node
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices. Using this API, the cpufreq cooling device will be
+ * linked to the device tree node provided.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	if (!np)
+		return ERR_PTR(-EINVAL);
+
+	return __cpufreq_cooling_register(np, clip_cpus);
+}
+EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  *
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index a5d52ee..c303d38 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -24,6 +24,7 @@
 #ifndef __CPU_COOLING_H__
 #define __CPU_COOLING_H__
 
+#include <linux/of.h>
 #include <linux/thermal.h>
 #include <linux/cpumask.h>
 
@@ -36,6 +37,24 @@ struct thermal_cooling_device *
 cpufreq_cooling_register(const struct cpumask *clip_cpus);
 
 /**
+ * of_cpufreq_cooling_register - create cpufreq cooling device based on DT.
+ * @np: a valid struct device_node to the cooling device device tree node.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen
+ */
+#ifdef CONFIG_THERMAL_OF
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus);
+#else
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	return NULL;
+}
+#endif
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  */
@@ -48,6 +67,12 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 {
 	return NULL;
 }
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	return NULL;
+}
 static inline
 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 {
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 05/18] thermal: cpu_cooling: introduce of_cpufreq_cooling_register
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces an API to register cpufreq cooling device
based on device tree node.

The registration via device tree node differs from normal
registration due to the fact that it is needed to fill
the device_node structure in order to be able to match
the cooling devices with trip points.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/Kconfig       |  1 +
 drivers/thermal/cpu_cooling.c | 56 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/cpu_cooling.h   | 25 +++++++++++++++++++
 3 files changed, 76 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dd81eb8..9e7cc3f 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -91,6 +91,7 @@ config THERMAL_GOV_USER_SPACE
 config CPU_THERMAL
 	bool "generic cpu cooling support"
 	depends on CPU_FREQ
+	depends on THERMAL_OF
 	select CPU_FREQ_TABLE
 	help
 	  This implements the generic cpu cooling mechanism through frequency
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index d179028..b7db93a 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -417,18 +417,21 @@ static struct notifier_block thermal_cpufreq_notifier_block = {
 };
 
 /**
- * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * __cpufreq_cooling_register - helper function to create cpufreq cooling device
+ * @np: a valid struct device_node to the cooling device device tree node
  * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
  *
  * This interface function registers the cpufreq cooling device with the name
  * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
- * cooling devices.
+ * cooling devices. It also gives the opportunity to link the cooling device
+ * with a device tree node, in order to bind it via the thermal DT code.
  *
  * Return: a valid struct thermal_cooling_device pointer on success,
  * on failure, it returns a corresponding ERR_PTR().
  */
-struct thermal_cooling_device *
-cpufreq_cooling_register(const struct cpumask *clip_cpus)
+static struct thermal_cooling_device *
+__cpufreq_cooling_register(struct device_node *np,
+			   const struct cpumask *clip_cpus)
 {
 	struct thermal_cooling_device *cool_dev;
 	struct cpufreq_cooling_device *cpufreq_dev = NULL;
@@ -467,8 +470,8 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 	snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
 		 cpufreq_dev->id);
 
-	cool_dev = thermal_cooling_device_register(dev_name, cpufreq_dev,
-						   &cpufreq_cooling_ops);
+	cool_dev = thermal_of_cooling_device_register(np, dev_name, cpufreq_dev,
+						      &cpufreq_cooling_ops);
 	if (!cool_dev) {
 		release_idr(&cpufreq_idr, cpufreq_dev->id);
 		kfree(cpufreq_dev);
@@ -488,9 +491,50 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 
 	return cool_dev;
 }
+
+/**
+ * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+cpufreq_cooling_register(const struct cpumask *clip_cpus)
+{
+	return __cpufreq_cooling_register(NULL, clip_cpus);
+}
 EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
 
 /**
+ * of_cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @np: a valid struct device_node to the cooling device device tree node
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices. Using this API, the cpufreq cooling device will be
+ * linked to the device tree node provided.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	if (!np)
+		return ERR_PTR(-EINVAL);
+
+	return __cpufreq_cooling_register(np, clip_cpus);
+}
+EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  *
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index a5d52ee..c303d38 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -24,6 +24,7 @@
 #ifndef __CPU_COOLING_H__
 #define __CPU_COOLING_H__
 
+#include <linux/of.h>
 #include <linux/thermal.h>
 #include <linux/cpumask.h>
 
@@ -36,6 +37,24 @@ struct thermal_cooling_device *
 cpufreq_cooling_register(const struct cpumask *clip_cpus);
 
 /**
+ * of_cpufreq_cooling_register - create cpufreq cooling device based on DT.
+ * @np: a valid struct device_node to the cooling device device tree node.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen
+ */
+#ifdef CONFIG_THERMAL_OF
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus);
+#else
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	return NULL;
+}
+#endif
+
+/**
  * cpufreq_cooling_unregister - function to remove cpufreq cooling device.
  * @cdev: thermal cooling device pointer.
  */
@@ -48,6 +67,12 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
 {
 	return NULL;
 }
+static inline struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+			    const struct cpumask *clip_cpus)
+{
+	return NULL;
+}
 static inline
 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 {
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 06/18] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Rafael J. Wysocki, Viresh Kumar,
	cpufreq, devicetree-discuss

This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
the cpu0 device tree node needs to be properly configured
with cooling device properties.

In case these properties are present,, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.

Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt         |  7 +++++++
 drivers/cpufreq/Kconfig                                  |  2 +-
 drivers/cpufreq/cpufreq-cpu0.c                           | 16 ++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..f055515 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,10 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
   in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- #cooling-cells:
+- cooling-min-level:
+- cooling-max-level:
+     Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
 
 Examples:
 
@@ -33,6 +37,9 @@ cpus {
 			198000  850000
 		>;
 		clock-latency = <61036>; /* two CLK32 periods */
+		#cooling-cells = <2>;
+		cooling-min-level = <0>;
+		cooling-max-level = <2>;
 	};
 
 	cpu@1 {
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 534fcb8..fc1e9a5 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -186,7 +186,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
-	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
+	depends on HAVE_CLK && REGULATOR && PM_OPP && OF && THERMAL && CPU_THERMAL
 	select CPU_FREQ_TABLE
 	help
 	  This adds a generic cpufreq driver for CPU0 frequency management.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 78c49d8..fd707b8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -13,7 +13,9 @@
 
 #include <linux/clk.h>
 #include <linux/cpu.h>
+#include <linux/cpu_cooling.h>
 #include <linux/cpufreq.h>
+#include <linux/cpumask.h>
 #include <linux/err.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -21,6 +23,7 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
+#include <linux/thermal.h>
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
@@ -29,6 +32,7 @@ static struct device *cpu_dev;
 static struct clk *cpu_clk;
 static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -260,6 +264,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 		goto out_free_table;
 	}
 
+	/*
+	 * For now, just loading the cooling device;
+	 * thermal DT code takes care of matching them.
+	 */
+	if (of_find_property(np, "#cooling-cells", NULL)) {
+		cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
+		if (IS_ERR(cdev))
+			pr_err("running cpufreq without cooling device: %ld\n",
+			       PTR_ERR(cdev));
+	}
+
 	of_node_put(np);
 	return 0;
 
@@ -272,6 +287,7 @@ out_put_node:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+	cpufreq_cooling_unregister(cdev);
 	cpufreq_unregister_driver(&cpu0_cpufreq_driver);
 	opp_free_cpufreq_table(cpu_dev, &freq_table);
 
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 06/18] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Rafael J. Wysocki, Viresh Kumar,
	cpufreq, devicetree-discuss

This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
the cpu0 device tree node needs to be properly configured
with cooling device properties.

In case these properties are present,, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.

Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt         |  7 +++++++
 drivers/cpufreq/Kconfig                                  |  2 +-
 drivers/cpufreq/cpufreq-cpu0.c                           | 16 ++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..f055515 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,10 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
   in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- #cooling-cells:
+- cooling-min-level:
+- cooling-max-level:
+     Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
 
 Examples:
 
@@ -33,6 +37,9 @@ cpus {
 			198000  850000
 		>;
 		clock-latency = <61036>; /* two CLK32 periods */
+		#cooling-cells = <2>;
+		cooling-min-level = <0>;
+		cooling-max-level = <2>;
 	};
 
 	cpu@1 {
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 534fcb8..fc1e9a5 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -186,7 +186,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
-	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
+	depends on HAVE_CLK && REGULATOR && PM_OPP && OF && THERMAL && CPU_THERMAL
 	select CPU_FREQ_TABLE
 	help
 	  This adds a generic cpufreq driver for CPU0 frequency management.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 78c49d8..fd707b8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -13,7 +13,9 @@
 
 #include <linux/clk.h>
 #include <linux/cpu.h>
+#include <linux/cpu_cooling.h>
 #include <linux/cpufreq.h>
+#include <linux/cpumask.h>
 #include <linux/err.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -21,6 +23,7 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
+#include <linux/thermal.h>
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
@@ -29,6 +32,7 @@ static struct device *cpu_dev;
 static struct clk *cpu_clk;
 static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -260,6 +264,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 		goto out_free_table;
 	}
 
+	/*
+	 * For now, just loading the cooling device;
+	 * thermal DT code takes care of matching them.
+	 */
+	if (of_find_property(np, "#cooling-cells", NULL)) {
+		cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
+		if (IS_ERR(cdev))
+			pr_err("running cpufreq without cooling device: %ld\n",
+			       PTR_ERR(cdev));
+	}
+
 	of_node_put(np);
 	return 0;
 
@@ -272,6 +287,7 @@ out_put_node:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+	cpufreq_cooling_unregister(cdev);
 	cpufreq_unregister_driver(&cpu0_cpufreq_driver);
 	opp_free_cpufreq_table(cpu_dev, &freq_table);
 
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 06/18] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device propertie
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Rafael J. Wysocki, Viresh Kumar,
	cpufreq, devicetree-discuss

This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
the cpu0 device tree node needs to be properly configured
with cooling device properties.

In case these properties are present,, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.

Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt         |  7 +++++++
 drivers/cpufreq/Kconfig                                  |  2 +-
 drivers/cpufreq/cpufreq-cpu0.c                           | 16 ++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..f055515 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,10 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
   in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- #cooling-cells:
+- cooling-min-level:
+- cooling-max-level:
+     Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
 
 Examples:
 
@@ -33,6 +37,9 @@ cpus {
 			198000  850000
 		>;
 		clock-latency = <61036>; /* two CLK32 periods */
+		#cooling-cells = <2>;
+		cooling-min-level = <0>;
+		cooling-max-level = <2>;
 	};
 
 	cpu@1 {
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 534fcb8..fc1e9a5 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -186,7 +186,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
-	depends on HAVE_CLK && REGULATOR && PM_OPP && OF
+	depends on HAVE_CLK && REGULATOR && PM_OPP && OF && THERMAL && CPU_THERMAL
 	select CPU_FREQ_TABLE
 	help
 	  This adds a generic cpufreq driver for CPU0 frequency management.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 78c49d8..fd707b8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -13,7 +13,9 @@
 
 #include <linux/clk.h>
 #include <linux/cpu.h>
+#include <linux/cpu_cooling.h>
 #include <linux/cpufreq.h>
+#include <linux/cpumask.h>
 #include <linux/err.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -21,6 +23,7 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
+#include <linux/thermal.h>
 
 static unsigned int transition_latency;
 static unsigned int voltage_tolerance; /* in percentage */
@@ -29,6 +32,7 @@ static struct device *cpu_dev;
 static struct clk *cpu_clk;
 static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -260,6 +264,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 		goto out_free_table;
 	}
 
+	/*
+	 * For now, just loading the cooling device;
+	 * thermal DT code takes care of matching them.
+	 */
+	if (of_find_property(np, "#cooling-cells", NULL)) {
+		cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
+		if (IS_ERR(cdev))
+			pr_err("running cpufreq without cooling device: %ld\n",
+			       PTR_ERR(cdev));
+	}
+
 	of_node_put(np);
 	return 0;
 
@@ -272,6 +287,7 @@ out_put_node:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+	cpufreq_cooling_unregister(cdev);
 	cpufreq_unregister_driver(&cpu0_cpufreq_driver);
 	opp_free_cpufreq_table(cpu_dev, &freq_table);
 
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 07/18] hwmon: lm75: expose to thermal fw via DT nodes
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Jean Delvare

This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare <khali@linux-fr.org>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 35 ++++++++++++++++++++++++++++++-----
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..1d3600a 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
 #include <linux/hwmon-sysfs.h>
 #include <linux/err.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/thermal.h>
 #include "lm75.h"
 
 
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
 /* Each client has this additional data */
 struct lm75_data {
 	struct device		*hwmon_dev;
+	struct thermal_zone_device	*tz;
 	struct mutex		update_lock;
 	u8			orig_conf;
 	u8			resolution;	/* In bits, between 9 and 12 */
@@ -90,22 +93,36 @@ static struct lm75_data *lm75_update_device(struct device *dev);
 
 /*-----------------------------------------------------------------------*/
 
+static inline long lm75_reg_to_mc(s16 temp, u8 resolution)
+{
+	return ((temp >> (16 - resolution)) * 1000) >> (resolution - 8);
+}
+
 /* sysfs attributes for hwmon */
 
+static int lm75_read_temp(void *dev, long *temp)
+{
+	struct lm75_data *data = lm75_update_device(dev);
+
+	if (IS_ERR(data))
+		return PTR_ERR(data);
+
+	*temp = lm75_reg_to_mc(data->temp[0], data->resolution);
+
+	return 0;
+}
+
 static ssize_t show_temp(struct device *dev, struct device_attribute *da,
 			 char *buf)
 {
 	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
 	struct lm75_data *data = lm75_update_device(dev);
-	long temp;
 
 	if (IS_ERR(data))
 		return PTR_ERR(data);
 
-	temp = ((data->temp[attr->index] >> (16 - data->resolution)) * 1000)
-	       >> (data->resolution - 8);
-
-	return sprintf(buf, "%ld\n", temp);
+	return sprintf(buf, "%ld\n", lm75_reg_to_mc(data->temp[attr->index],
+						    data->resolution));
 }
 
 static ssize_t set_temp(struct device *dev, struct device_attribute *da,
@@ -271,6 +288,13 @@ lm75_probe(struct i2c_client *client, const struct i2c_device_id *id)
 		goto exit_remove;
 	}
 
+	data->tz = thermal_zone_of_sensor_register(&client->dev,
+						   0,
+						   &client->dev,
+						   lm75_read_temp, NULL);
+	if (IS_ERR(data->tz))
+		data->tz = NULL;
+
 	dev_info(&client->dev, "%s: sensor '%s'\n",
 		 dev_name(data->hwmon_dev), client->name);
 
@@ -285,6 +309,7 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	thermal_zone_of_sensor_unregister(&client->dev, data->tz);
 	hwmon_device_unregister(data->hwmon_dev);
 	sysfs_remove_group(&client->dev.kobj, &lm75_group);
 	lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 07/18] hwmon: lm75: expose to thermal fw via DT nodes
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Jean Delvare

This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare <khali@linux-fr.org>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 35 ++++++++++++++++++++++++++++++-----
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..1d3600a 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
 #include <linux/hwmon-sysfs.h>
 #include <linux/err.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/thermal.h>
 #include "lm75.h"
 
 
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
 /* Each client has this additional data */
 struct lm75_data {
 	struct device		*hwmon_dev;
+	struct thermal_zone_device	*tz;
 	struct mutex		update_lock;
 	u8			orig_conf;
 	u8			resolution;	/* In bits, between 9 and 12 */
@@ -90,22 +93,36 @@ static struct lm75_data *lm75_update_device(struct device *dev);
 
 /*-----------------------------------------------------------------------*/
 
+static inline long lm75_reg_to_mc(s16 temp, u8 resolution)
+{
+	return ((temp >> (16 - resolution)) * 1000) >> (resolution - 8);
+}
+
 /* sysfs attributes for hwmon */
 
+static int lm75_read_temp(void *dev, long *temp)
+{
+	struct lm75_data *data = lm75_update_device(dev);
+
+	if (IS_ERR(data))
+		return PTR_ERR(data);
+
+	*temp = lm75_reg_to_mc(data->temp[0], data->resolution);
+
+	return 0;
+}
+
 static ssize_t show_temp(struct device *dev, struct device_attribute *da,
 			 char *buf)
 {
 	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
 	struct lm75_data *data = lm75_update_device(dev);
-	long temp;
 
 	if (IS_ERR(data))
 		return PTR_ERR(data);
 
-	temp = ((data->temp[attr->index] >> (16 - data->resolution)) * 1000)
-	       >> (data->resolution - 8);
-
-	return sprintf(buf, "%ld\n", temp);
+	return sprintf(buf, "%ld\n", lm75_reg_to_mc(data->temp[attr->index],
+						    data->resolution));
 }
 
 static ssize_t set_temp(struct device *dev, struct device_attribute *da,
@@ -271,6 +288,13 @@ lm75_probe(struct i2c_client *client, const struct i2c_device_id *id)
 		goto exit_remove;
 	}
 
+	data->tz = thermal_zone_of_sensor_register(&client->dev,
+						   0,
+						   &client->dev,
+						   lm75_read_temp, NULL);
+	if (IS_ERR(data->tz))
+		data->tz = NULL;
+
 	dev_info(&client->dev, "%s: sensor '%s'\n",
 		 dev_name(data->hwmon_dev), client->name);
 
@@ -285,6 +309,7 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	thermal_zone_of_sensor_unregister(&client->dev, data->tz);
 	hwmon_device_unregister(data->hwmon_dev);
 	sysfs_remove_group(&client->dev.kobj, &lm75_group);
 	lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 07/18] hwmon: lm75: expose to thermal fw via DT nodes
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Jean Delvare

This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare <khali@linux-fr.org>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 35 ++++++++++++++++++++++++++++++-----
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..1d3600a 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
 #include <linux/hwmon-sysfs.h>
 #include <linux/err.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/thermal.h>
 #include "lm75.h"
 
 
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
 /* Each client has this additional data */
 struct lm75_data {
 	struct device		*hwmon_dev;
+	struct thermal_zone_device	*tz;
 	struct mutex		update_lock;
 	u8			orig_conf;
 	u8			resolution;	/* In bits, between 9 and 12 */
@@ -90,22 +93,36 @@ static struct lm75_data *lm75_update_device(struct device *dev);
 
 /*-----------------------------------------------------------------------*/
 
+static inline long lm75_reg_to_mc(s16 temp, u8 resolution)
+{
+	return ((temp >> (16 - resolution)) * 1000) >> (resolution - 8);
+}
+
 /* sysfs attributes for hwmon */
 
+static int lm75_read_temp(void *dev, long *temp)
+{
+	struct lm75_data *data = lm75_update_device(dev);
+
+	if (IS_ERR(data))
+		return PTR_ERR(data);
+
+	*temp = lm75_reg_to_mc(data->temp[0], data->resolution);
+
+	return 0;
+}
+
 static ssize_t show_temp(struct device *dev, struct device_attribute *da,
 			 char *buf)
 {
 	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
 	struct lm75_data *data = lm75_update_device(dev);
-	long temp;
 
 	if (IS_ERR(data))
 		return PTR_ERR(data);
 
-	temp = ((data->temp[attr->index] >> (16 - data->resolution)) * 1000)
-	       >> (data->resolution - 8);
-
-	return sprintf(buf, "%ld\n", temp);
+	return sprintf(buf, "%ld\n", lm75_reg_to_mc(data->temp[attr->index],
+						    data->resolution));
 }
 
 static ssize_t set_temp(struct device *dev, struct device_attribute *da,
@@ -271,6 +288,13 @@ lm75_probe(struct i2c_client *client, const struct i2c_device_id *id)
 		goto exit_remove;
 	}
 
+	data->tz = thermal_zone_of_sensor_register(&client->dev,
+						   0,
+						   &client->dev,
+						   lm75_read_temp, NULL);
+	if (IS_ERR(data->tz))
+		data->tz = NULL;
+
 	dev_info(&client->dev, "%s: sensor '%s'\n",
 		 dev_name(data->hwmon_dev), client->name);
 
@@ -285,6 +309,7 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	thermal_zone_of_sensor_unregister(&client->dev, data->tz);
 	hwmon_device_unregister(data->hwmon_dev);
 	sysfs_remove_group(&client->dev.kobj, &lm75_group);
 	lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 08/18] hwmon: tmp102: expose to thermal fw via DT nodes
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Jean Delvare

This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare <khali@linux-fr.org>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/tmp102.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..6748b45 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
 #include <linux/mutex.h>
 #include <linux/device.h>
 #include <linux/jiffies.h>
+#include <linux/thermal.h>
+#include <linux/of.h>
 
 #define	DRIVER_NAME "tmp102"
 
@@ -50,6 +52,7 @@
 
 struct tmp102 {
 	struct device *hwmon_dev;
+	struct thermal_zone_device *tz;
 	struct mutex lock;
 	u16 config_orig;
 	unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client *client)
 	return tmp102;
 }
 
+static int tmp102_read_temp(void *dev, long *temp)
+{
+	struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+	*temp = tmp102->temp[0];
+
+	return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
@@ -204,6 +216,12 @@ static int tmp102_probe(struct i2c_client *client,
 		goto fail_remove_sysfs;
 	}
 
+	tmp102->tz = thermal_zone_of_sensor_register(&client->dev, 0,
+						     &client->dev,
+						     tmp102_read_temp, NULL);
+	if (IS_ERR(tmp102->tz))
+		tmp102->tz = NULL;
+
 	dev_info(&client->dev, "initialized\n");
 
 	return 0;
@@ -220,6 +238,7 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
 	hwmon_device_unregister(tmp102->hwmon_dev);
 	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
 
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 08/18] hwmon: tmp102: expose to thermal fw via DT nodes
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren-3lzwWm7+Weoh9ZMKESR00Q, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eduardo Valentin,
	Jean Delvare

This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Acked-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
---
 drivers/hwmon/tmp102.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..6748b45 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
 #include <linux/mutex.h>
 #include <linux/device.h>
 #include <linux/jiffies.h>
+#include <linux/thermal.h>
+#include <linux/of.h>
 
 #define	DRIVER_NAME "tmp102"
 
@@ -50,6 +52,7 @@
 
 struct tmp102 {
 	struct device *hwmon_dev;
+	struct thermal_zone_device *tz;
 	struct mutex lock;
 	u16 config_orig;
 	unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client *client)
 	return tmp102;
 }
 
+static int tmp102_read_temp(void *dev, long *temp)
+{
+	struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+	*temp = tmp102->temp[0];
+
+	return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
@@ -204,6 +216,12 @@ static int tmp102_probe(struct i2c_client *client,
 		goto fail_remove_sysfs;
 	}
 
+	tmp102->tz = thermal_zone_of_sensor_register(&client->dev, 0,
+						     &client->dev,
+						     tmp102_read_temp, NULL);
+	if (IS_ERR(tmp102->tz))
+		tmp102->tz = NULL;
+
 	dev_info(&client->dev, "initialized\n");
 
 	return 0;
@@ -220,6 +238,7 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
 	hwmon_device_unregister(tmp102->hwmon_dev);
 	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 08/18] hwmon: tmp102: expose to thermal fw via DT nodes
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Jean Delvare

This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.

The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.

Cc: Jean Delvare <khali@linux-fr.org>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/tmp102.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..6748b45 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
 #include <linux/mutex.h>
 #include <linux/device.h>
 #include <linux/jiffies.h>
+#include <linux/thermal.h>
+#include <linux/of.h>
 
 #define	DRIVER_NAME "tmp102"
 
@@ -50,6 +52,7 @@
 
 struct tmp102 {
 	struct device *hwmon_dev;
+	struct thermal_zone_device *tz;
 	struct mutex lock;
 	u16 config_orig;
 	unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client *client)
 	return tmp102;
 }
 
+static int tmp102_read_temp(void *dev, long *temp)
+{
+	struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+	*temp = tmp102->temp[0];
+
+	return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
@@ -204,6 +216,12 @@ static int tmp102_probe(struct i2c_client *client,
 		goto fail_remove_sysfs;
 	}
 
+	tmp102->tz = thermal_zone_of_sensor_register(&client->dev, 0,
+						     &client->dev,
+						     tmp102_read_temp, NULL);
+	if (IS_ERR(tmp102->tz))
+		tmp102->tz = NULL;
+
 	dev_info(&client->dev, "initialized\n");
 
 	return 0;
@@ -220,6 +238,7 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
 	hwmon_device_unregister(tmp102->hwmon_dev);
 	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
 
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 09/18] thermal: ti-soc-thermal: use thermal DT infrastructure
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.

The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.

In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 77 +++++++++++++++++-----
 1 file changed, 62 insertions(+), 15 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 4f8b9af..b80b5b8 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
 #include <linux/cpufreq.h>
 #include <linux/cpumask.h>
 #include <linux/cpu_cooling.h>
+#include <linux/of.h>
 
 #include "ti-thermal.h"
 #include "ti-bandgap.h"
@@ -44,6 +45,7 @@ struct ti_thermal_data {
 	enum thermal_device_mode mode;
 	struct work_struct thermal_wq;
 	int sensor_id;
+	bool our_zone;
 };
 
 static void ti_thermal_work(struct work_struct *work)
@@ -75,11 +77,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int s, int c)
 
 /* thermal zone ops */
 /* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
-				      unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, long *temp)
 {
 	struct thermal_zone_device *pcb_tz = NULL;
-	struct ti_thermal_data *data = thermal->devdata;
+	struct ti_thermal_data *data = devdata;
 	struct ti_bandgap *bgp;
 	const struct ti_temp_sensor *s;
 	int ret, tmp, slope, constant;
@@ -117,6 +118,14 @@ static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
 	return ret;
 }
 
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+				      unsigned long *temp)
+{
+	struct ti_thermal_data *data = thermal->devdata;
+
+	return __ti_thermal_get_temp(data, temp);
+}
+
 /* Bind callback functions for thermal zone */
 static int ti_thermal_bind(struct thermal_zone_device *thermal,
 			   struct thermal_cooling_device *cdev)
@@ -229,11 +238,9 @@ static int ti_thermal_get_trip_temp(struct thermal_zone_device *thermal,
 	return 0;
 }
 
-/* Get the temperature trend callback functions for thermal zone */
-static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
-				int trip, enum thermal_trend *trend)
+static int __ti_thermal_get_trend(void *p, long *trend)
 {
-	struct ti_thermal_data *data = thermal->devdata;
+	struct ti_thermal_data *data = p;
 	struct ti_bandgap *bgp;
 	int id, tr, ret = 0;
 
@@ -244,6 +251,22 @@ static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
 	if (ret)
 		return ret;
 
+	*trend = tr;
+
+	return 0;
+}
+
+/* Get the temperature trend callback functions for thermal zone */
+static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
+				int trip, enum thermal_trend *trend)
+{
+	int ret;
+	long tr;
+
+	ret = __ti_thermal_get_trend(thermal->devdata, &tr);
+	if (ret)
+		return ret;
+
 	if (tr > 0)
 		*trend = THERMAL_TREND_RAISING;
 	else if (tr < 0)
@@ -307,16 +330,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
 	if (!data)
 		return -EINVAL;
 
-	/* Create thermal zone */
-	data->ti_thermal = thermal_zone_device_register(domain,
+	/* in case this is specified by DT */
+	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
+					data, __ti_thermal_get_temp,
+					__ti_thermal_get_trend);
+	if (IS_ERR(data->ti_thermal)) {
+		/* Create thermal zone */
+		data->ti_thermal = thermal_zone_device_register(domain,
 				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,
 				NULL, FAST_TEMP_MONITORING_RATE,
 				FAST_TEMP_MONITORING_RATE);
-	if (IS_ERR(data->ti_thermal)) {
-		dev_err(bgp->dev, "thermal zone device is NULL\n");
-		return PTR_ERR(data->ti_thermal);
+		if (IS_ERR(data->ti_thermal)) {
+			dev_err(bgp->dev, "thermal zone device is NULL\n");
+			return PTR_ERR(data->ti_thermal);
+		}
+		data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
+		data->our_zone = true;
 	}
-	data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
 	ti_bandgap_set_sensor_data(bgp, id, data);
 	ti_bandgap_write_update_interval(bgp, data->sensor_id,
 					data->ti_thermal->polling_delay);
@@ -330,7 +360,13 @@ int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id)
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
 
-	thermal_zone_device_unregister(data->ti_thermal);
+	if (data && data->ti_thermal) {
+		if (data->our_zone)
+			thermal_zone_device_unregister(data->ti_thermal);
+		else
+			thermal_zone_of_sensor_unregister(bgp->dev,
+							  data->ti_thermal);
+	}
 
 	return 0;
 }
@@ -349,6 +385,15 @@ int ti_thermal_report_sensor_temperature(struct ti_bandgap *bgp, int id)
 int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
 {
 	struct ti_thermal_data *data;
+	struct device_node *np = bgp->dev->of_node;
+
+	/*
+	 * We are assuming here that if one deploys the zone
+	 * using DT, then it must be aware that the cooling device
+	 * loading has to happen via cpufreq driver.
+	 */
+	if (of_find_property(np, "#thermal-sensor-cells", NULL))
+		return 0;
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
 	if (!data || IS_ERR(data))
@@ -379,7 +424,9 @@ int ti_thermal_unregister_cpu_cooling(struct ti_bandgap *bgp, int id)
 	struct ti_thermal_data *data;
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
-	cpufreq_cooling_unregister(data->cool_dev);
+
+	if (data && data->cool_dev)
+		cpufreq_cooling_unregister(data->cool_dev);
 
 	return 0;
 }
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 09/18] thermal: ti-soc-thermal: use thermal DT infrastructure
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.

The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.

In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 77 +++++++++++++++++-----
 1 file changed, 62 insertions(+), 15 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 4f8b9af..b80b5b8 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
 #include <linux/cpufreq.h>
 #include <linux/cpumask.h>
 #include <linux/cpu_cooling.h>
+#include <linux/of.h>
 
 #include "ti-thermal.h"
 #include "ti-bandgap.h"
@@ -44,6 +45,7 @@ struct ti_thermal_data {
 	enum thermal_device_mode mode;
 	struct work_struct thermal_wq;
 	int sensor_id;
+	bool our_zone;
 };
 
 static void ti_thermal_work(struct work_struct *work)
@@ -75,11 +77,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int s, int c)
 
 /* thermal zone ops */
 /* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
-				      unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, long *temp)
 {
 	struct thermal_zone_device *pcb_tz = NULL;
-	struct ti_thermal_data *data = thermal->devdata;
+	struct ti_thermal_data *data = devdata;
 	struct ti_bandgap *bgp;
 	const struct ti_temp_sensor *s;
 	int ret, tmp, slope, constant;
@@ -117,6 +118,14 @@ static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
 	return ret;
 }
 
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+				      unsigned long *temp)
+{
+	struct ti_thermal_data *data = thermal->devdata;
+
+	return __ti_thermal_get_temp(data, temp);
+}
+
 /* Bind callback functions for thermal zone */
 static int ti_thermal_bind(struct thermal_zone_device *thermal,
 			   struct thermal_cooling_device *cdev)
@@ -229,11 +238,9 @@ static int ti_thermal_get_trip_temp(struct thermal_zone_device *thermal,
 	return 0;
 }
 
-/* Get the temperature trend callback functions for thermal zone */
-static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
-				int trip, enum thermal_trend *trend)
+static int __ti_thermal_get_trend(void *p, long *trend)
 {
-	struct ti_thermal_data *data = thermal->devdata;
+	struct ti_thermal_data *data = p;
 	struct ti_bandgap *bgp;
 	int id, tr, ret = 0;
 
@@ -244,6 +251,22 @@ static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
 	if (ret)
 		return ret;
 
+	*trend = tr;
+
+	return 0;
+}
+
+/* Get the temperature trend callback functions for thermal zone */
+static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
+				int trip, enum thermal_trend *trend)
+{
+	int ret;
+	long tr;
+
+	ret = __ti_thermal_get_trend(thermal->devdata, &tr);
+	if (ret)
+		return ret;
+
 	if (tr > 0)
 		*trend = THERMAL_TREND_RAISING;
 	else if (tr < 0)
@@ -307,16 +330,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
 	if (!data)
 		return -EINVAL;
 
-	/* Create thermal zone */
-	data->ti_thermal = thermal_zone_device_register(domain,
+	/* in case this is specified by DT */
+	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
+					data, __ti_thermal_get_temp,
+					__ti_thermal_get_trend);
+	if (IS_ERR(data->ti_thermal)) {
+		/* Create thermal zone */
+		data->ti_thermal = thermal_zone_device_register(domain,
 				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,
 				NULL, FAST_TEMP_MONITORING_RATE,
 				FAST_TEMP_MONITORING_RATE);
-	if (IS_ERR(data->ti_thermal)) {
-		dev_err(bgp->dev, "thermal zone device is NULL\n");
-		return PTR_ERR(data->ti_thermal);
+		if (IS_ERR(data->ti_thermal)) {
+			dev_err(bgp->dev, "thermal zone device is NULL\n");
+			return PTR_ERR(data->ti_thermal);
+		}
+		data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
+		data->our_zone = true;
 	}
-	data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
 	ti_bandgap_set_sensor_data(bgp, id, data);
 	ti_bandgap_write_update_interval(bgp, data->sensor_id,
 					data->ti_thermal->polling_delay);
@@ -330,7 +360,13 @@ int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id)
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
 
-	thermal_zone_device_unregister(data->ti_thermal);
+	if (data && data->ti_thermal) {
+		if (data->our_zone)
+			thermal_zone_device_unregister(data->ti_thermal);
+		else
+			thermal_zone_of_sensor_unregister(bgp->dev,
+							  data->ti_thermal);
+	}
 
 	return 0;
 }
@@ -349,6 +385,15 @@ int ti_thermal_report_sensor_temperature(struct ti_bandgap *bgp, int id)
 int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
 {
 	struct ti_thermal_data *data;
+	struct device_node *np = bgp->dev->of_node;
+
+	/*
+	 * We are assuming here that if one deploys the zone
+	 * using DT, then it must be aware that the cooling device
+	 * loading has to happen via cpufreq driver.
+	 */
+	if (of_find_property(np, "#thermal-sensor-cells", NULL))
+		return 0;
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
 	if (!data || IS_ERR(data))
@@ -379,7 +424,9 @@ int ti_thermal_unregister_cpu_cooling(struct ti_bandgap *bgp, int id)
 	struct ti_thermal_data *data;
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
-	cpufreq_cooling_unregister(data->cool_dev);
+
+	if (data && data->cool_dev)
+		cpufreq_cooling_unregister(data->cool_dev);
 
 	return 0;
 }
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 09/18] thermal: ti-soc-thermal: use thermal DT infrastructure
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.

The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.

In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 77 +++++++++++++++++-----
 1 file changed, 62 insertions(+), 15 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 4f8b9af..b80b5b8 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
 #include <linux/cpufreq.h>
 #include <linux/cpumask.h>
 #include <linux/cpu_cooling.h>
+#include <linux/of.h>
 
 #include "ti-thermal.h"
 #include "ti-bandgap.h"
@@ -44,6 +45,7 @@ struct ti_thermal_data {
 	enum thermal_device_mode mode;
 	struct work_struct thermal_wq;
 	int sensor_id;
+	bool our_zone;
 };
 
 static void ti_thermal_work(struct work_struct *work)
@@ -75,11 +77,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int s, int c)
 
 /* thermal zone ops */
 /* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
-				      unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, long *temp)
 {
 	struct thermal_zone_device *pcb_tz = NULL;
-	struct ti_thermal_data *data = thermal->devdata;
+	struct ti_thermal_data *data = devdata;
 	struct ti_bandgap *bgp;
 	const struct ti_temp_sensor *s;
 	int ret, tmp, slope, constant;
@@ -117,6 +118,14 @@ static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
 	return ret;
 }
 
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+				      unsigned long *temp)
+{
+	struct ti_thermal_data *data = thermal->devdata;
+
+	return __ti_thermal_get_temp(data, temp);
+}
+
 /* Bind callback functions for thermal zone */
 static int ti_thermal_bind(struct thermal_zone_device *thermal,
 			   struct thermal_cooling_device *cdev)
@@ -229,11 +238,9 @@ static int ti_thermal_get_trip_temp(struct thermal_zone_device *thermal,
 	return 0;
 }
 
-/* Get the temperature trend callback functions for thermal zone */
-static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
-				int trip, enum thermal_trend *trend)
+static int __ti_thermal_get_trend(void *p, long *trend)
 {
-	struct ti_thermal_data *data = thermal->devdata;
+	struct ti_thermal_data *data = p;
 	struct ti_bandgap *bgp;
 	int id, tr, ret = 0;
 
@@ -244,6 +251,22 @@ static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
 	if (ret)
 		return ret;
 
+	*trend = tr;
+
+	return 0;
+}
+
+/* Get the temperature trend callback functions for thermal zone */
+static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
+				int trip, enum thermal_trend *trend)
+{
+	int ret;
+	long tr;
+
+	ret = __ti_thermal_get_trend(thermal->devdata, &tr);
+	if (ret)
+		return ret;
+
 	if (tr > 0)
 		*trend = THERMAL_TREND_RAISING;
 	else if (tr < 0)
@@ -307,16 +330,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
 	if (!data)
 		return -EINVAL;
 
-	/* Create thermal zone */
-	data->ti_thermal = thermal_zone_device_register(domain,
+	/* in case this is specified by DT */
+	data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
+					data, __ti_thermal_get_temp,
+					__ti_thermal_get_trend);
+	if (IS_ERR(data->ti_thermal)) {
+		/* Create thermal zone */
+		data->ti_thermal = thermal_zone_device_register(domain,
 				OMAP_TRIP_NUMBER, 0, data, &ti_thermal_ops,
 				NULL, FAST_TEMP_MONITORING_RATE,
 				FAST_TEMP_MONITORING_RATE);
-	if (IS_ERR(data->ti_thermal)) {
-		dev_err(bgp->dev, "thermal zone device is NULL\n");
-		return PTR_ERR(data->ti_thermal);
+		if (IS_ERR(data->ti_thermal)) {
+			dev_err(bgp->dev, "thermal zone device is NULL\n");
+			return PTR_ERR(data->ti_thermal);
+		}
+		data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
+		data->our_zone = true;
 	}
-	data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
 	ti_bandgap_set_sensor_data(bgp, id, data);
 	ti_bandgap_write_update_interval(bgp, data->sensor_id,
 					data->ti_thermal->polling_delay);
@@ -330,7 +360,13 @@ int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id)
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
 
-	thermal_zone_device_unregister(data->ti_thermal);
+	if (data && data->ti_thermal) {
+		if (data->our_zone)
+			thermal_zone_device_unregister(data->ti_thermal);
+		else
+			thermal_zone_of_sensor_unregister(bgp->dev,
+							  data->ti_thermal);
+	}
 
 	return 0;
 }
@@ -349,6 +385,15 @@ int ti_thermal_report_sensor_temperature(struct ti_bandgap *bgp, int id)
 int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
 {
 	struct ti_thermal_data *data;
+	struct device_node *np = bgp->dev->of_node;
+
+	/*
+	 * We are assuming here that if one deploys the zone
+	 * using DT, then it must be aware that the cooling device
+	 * loading has to happen via cpufreq driver.
+	 */
+	if (of_find_property(np, "#thermal-sensor-cells", NULL))
+		return 0;
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
 	if (!data || IS_ERR(data))
@@ -379,7 +424,9 @@ int ti_thermal_unregister_cpu_cooling(struct ti_bandgap *bgp, int id)
 	struct ti_thermal_data *data;
 
 	data = ti_bandgap_get_sensor_data(bgp, id);
-	cpufreq_cooling_unregister(data->cool_dev);
+
+	if (data && data->cool_dev)
+		cpufreq_cooling_unregister(data->cool_dev);
 
 	return 0;
 }
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 10/18] arm: dts: add omap4 CPU thermal data
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41 ++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 0000000..65a6deb
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpu_thermal: cpu_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap     0>;
+
+        trips {
+                cpu_alert0: cpu_alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu_crit: cpu_crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu_alert0>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 10/18] arm: dts: add omap4 CPU thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: devicetree, durgadoss.r, linux-pm, Tony Lindgren, linux-kernel,
	lm-sensors, Eduardo Valentin, Benoît Cousson, grant.likely,
	Russell King, linux-omap, linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41 ++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 0000000..65a6deb
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpu_thermal: cpu_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap     0>;
+
+        trips {
+                cpu_alert0: cpu_alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu_crit: cpu_crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu_alert0>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 10/18] arm: dts: add omap4 CPU thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41 ++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 0000000..65a6deb
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpu_thermal: cpu_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+        thermal-sensors = <&bandgap     0>;
+
+        trips {
+                cpu_alert0: cpu_alert {
+                        temperature = <100000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_PASSIVE;
+                };
+                cpu_crit: cpu_crit {
+                        temperature = <125000>; /* millicelsius */
+                        hysteresis = <2000>; /* millicelsius */
+                        type = THERMAL_TRIP_CRITICAL;
+                };
+        };
+
+	cooling-maps {
+		map0 {
+			trip = <&cpu_alert0>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 10/18] arm: dts: add omap4 CPU thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

VGhpcyBwYXRjaCBjaGFuZ2VzIGEgZHRzaSBmaWxlIHRvIGNvbnRhaW4gdGhlIHRoZXJtYWwgZGF0
YQpmb3IgTVBVIGRvbWFpbiBvbiBPTUFQNCBhbmQgbGF0ZXIgU29Dcy4gVGhpcyBkYXRhIHdpbGwK
ZW5hYmxlIHRoZSBwYXNzaXZlIGNvb2xpbmcgd2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlCmF0
IDEwMEMgYW5kIHRoZSBzeXN0ZW0gd2lsbCBkbyBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4K
ClRoaXMgdGhlcm1hbCBkYXRhIGNhbiBiZSByZXVzZWQgYWNyb3NzIFRJIFNvQyBkZXZpY2VzLgoK
Q2M6ICJCZW5vw650IENvdXNzb24iIDxiY291c3NvbkBiYXlsaWJyZS5jb20+CkNjOiBUb255IExp
bmRncmVuIDx0b255QGF0b21pZGUuY29tPgpDYzogUm9iIEhlcnJpbmcgPHJvYi5oZXJyaW5nQGNh
bHhlZGEuY29tPgpDYzogUGF3ZWwgTW9sbCA8cGF3ZWwubW9sbEBhcm0uY29tPgpDYzogTWFyayBS
dXRsYW5kIDxtYXJrLnJ1dGxhbmRAYXJtLmNvbT4KQ2M6IFN0ZXBoZW4gV2FycmVuIDxzd2FycmVu
QHd3d2RvdG9yZy5vcmc+CkNjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29t
PgpDYzogUnVzc2VsbCBLaW5nIDxsaW51eEBhcm0ubGludXgub3JnLnVrPgpDYzogbGludXgtb21h
cEB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnCkNjOiBsaW51
eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtl
cm5lbC5vcmcKU2lnbmVkLW9mZi1ieTogRWR1YXJkbyBWYWxlbnRpbiA8ZWR1YXJkby52YWxlbnRp
bkB0aS5jb20+Ci0tLQogYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQtY3B1LXRoZXJtYWwuZHRzaSB8
IDQxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgNDEg
aW5zZXJ0aW9ucygrKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGFyY2gvYXJtL2Jvb3QvZHRzL29tYXA0
LWNwdS10aGVybWFsLmR0c2kKCmRpZmYgLS1naXQgYS9hcmNoL2FybS9ib290L2R0cy9vbWFwNC1j
cHUtdGhlcm1hbC5kdHNpIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQtY3B1LXRoZXJtYWwuZHRz
aQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi42NWE2ZGViCi0tLSAvZGV2L251
bGwKKysrIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQtY3B1LXRoZXJtYWwuZHRzaQpAQCAtMCww
ICsxLDQxIEBACisvKgorICogRGV2aWNlIFRyZWUgU291cmNlIGZvciBPTUFQNC81IFNvQyBDUFUg
dGhlcm1hbAorICoKKyAqIENvcHlyaWdodCAoQykgMjAxMyBUZXhhcyBJbnN0cnVtZW50cyBJbmNv
cnBvcmF0ZWQgLSBodHRwOi8vd3d3LnRpLmNvbS8KKyAqIENvbnRhY3Q6IEVkdWFyZG8gVmFsZW50
aW4gPGVkdWFyZG8udmFsZW50aW5AdGkuY29tPgorICoKKyAqIFRoaXMgZmlsZSBpcyBsaWNlbnNl
ZCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiB2
ZXJzaW9uIDIuICBUaGlzIHByb2dyYW0gaXMgbGljZW5zZWQgImFzIGlzIiB3aXRob3V0IGFueSB3
YXJyYW50eSBvZiBhbnkKKyAqIGtpbmQsIHdoZXRoZXIgZXhwcmVzcyBvciBpbXBsaWVkLgorICov
CisKKyNpbmNsdWRlIDxkdC1iaW5kaW5ncy90aGVybWFsL3RoZXJtYWwuaD4KKworY3B1X3RoZXJt
YWw6IGNwdV90aGVybWFsIHsKKwlwb2xsaW5nLWRlbGF5LXBhc3NpdmUgPSA8MjUwPjsgLyogbWls
bGlzZWNvbmRzICovCisJcG9sbGluZy1kZWxheSA9IDwxMDAwPjsgLyogbWlsbGlzZWNvbmRzICov
CisKKwkJCS8qIHNlbnNvciAgICAgICBJRCAqLworICAgICAgICB0aGVybWFsLXNlbnNvcnMgPSA8
JmJhbmRnYXAgICAgIDA+OworCisgICAgICAgIHRyaXBzIHsKKyAgICAgICAgICAgICAgICBjcHVf
YWxlcnQwOiBjcHVfYWxlcnQgeworICAgICAgICAgICAgICAgICAgICAgICAgdGVtcGVyYXR1cmUg
PSA8MTAwMDAwPjsgLyogbWlsbGljZWxzaXVzICovCisgICAgICAgICAgICAgICAgICAgICAgICBo
eXN0ZXJlc2lzID0gPDIwMDA+OyAvKiBtaWxsaWNlbHNpdXMgKi8KKyAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBUSEVSTUFMX1RSSVBfUEFTU0lWRTsKKyAgICAgICAgICAgICAgICB9Owor
ICAgICAgICAgICAgICAgIGNwdV9jcml0OiBjcHVfY3JpdCB7CisgICAgICAgICAgICAgICAgICAg
ICAgICB0ZW1wZXJhdHVyZSA9IDwxMjUwMDA+OyAvKiBtaWxsaWNlbHNpdXMgKi8KKyAgICAgICAg
ICAgICAgICAgICAgICAgIGh5c3RlcmVzaXMgPSA8MjAwMD47IC8qIG1pbGxpY2Vsc2l1cyAqLwor
ICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSA9IFRIRVJNQUxfVFJJUF9DUklUSUNBTDsKKyAg
ICAgICAgICAgICAgICB9OworICAgICAgICB9OworCisJY29vbGluZy1tYXBzIHsKKwkJbWFwMCB7
CisJCQl0cmlwID0gPCZjcHVfYWxlcnQwPjsKKwkJCWNvb2xpbmctZGV2aWNlID0KKwkJCQk8JmNw
dTAgVEhFUk1BTF9OT19MSU1JVCBUSEVSTUFMX05PX0xJTUlUPjsKKwkJfTsKKwl9OworfTsKLS0g
CjEuOC4yLjEuMzQyLmdmYTcyODVkCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5z
b3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1z
ZW5zb3Jz

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 11/18] arm: dts: add omap4430 thermal data
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, devicetree-discuss,
	linux-arm-kernel

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
 
 / {
 	cpus {
-		cpu@0 {
+		cpu0: cpu@0 {
 			/* OMAP443x variants OPP50-OPPNT */
 			operating-points = <
 				/* kHz    uV */
@@ -25,9 +25,15 @@
 		};
 	};
 
-	bandgap {
+	thermal-zones{
+		#include "omap4-cpu-thermal.dtsi"
+	};
+
+	bandgap: bandgap {
 		reg = <0x4a002260 0x4
 		       0x4a00232C 0x4>;
 		compatible = "ti,omap4430-bandgap";
+
+		#thermal-sensor-cells = <0>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: devicetree, durgadoss.r, linux-pm, Tony Lindgren,
	devicetree-discuss, linux-kernel, lm-sensors, Eduardo Valentin,
	Benoît Cousson, grant.likely, Russell King, linux-omap,
	linux-arm-kernel

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
 
 / {
 	cpus {
-		cpu@0 {
+		cpu0: cpu@0 {
 			/* OMAP443x variants OPP50-OPPNT */
 			operating-points = <
 				/* kHz    uV */
@@ -25,9 +25,15 @@
 		};
 	};
 
-	bandgap {
+	thermal-zones{
+		#include "omap4-cpu-thermal.dtsi"
+	};
+
+	bandgap: bandgap {
 		reg = <0x4a002260 0x4
 		       0x4a00232C 0x4>;
 		compatible = "ti,omap4430-bandgap";
+
+		#thermal-sensor-cells = <0>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
 
 / {
 	cpus {
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			/* OMAP443x variants OPP50-OPPNT */
 			operating-points = <
 				/* kHz    uV */
@@ -25,9 +25,15 @@
 		};
 	};
 
-	bandgap {
+	thermal-zones{
+		#include "omap4-cpu-thermal.dtsi"
+	};
+
+	bandgap: bandgap {
 		reg = <0x4a002260 0x4
 		       0x4a00232C 0x4>;
 		compatible = "ti,omap4430-bandgap";
+
+		#thermal-sensor-cells = <0>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, devicetree-discuss,
	linux-arm-kernel

VGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBkdHNpIGVudHJ5IG9uIG9tYXA0NDMwIHRvIGNvbnRhaW4K
dGhlIHRoZXJtYWwgZGF0YS4gVGhpcyBkYXRhIHdpbGwgZW5hYmxlIHRoZSBwYXNzaXZlCmNvb2xp
bmcgd2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlIGF0IDEwMEMgYW5kIHRoZQpzeXN0ZW0gd2ls
bCBkbyBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4KCkNjOiAiQmVub8OudCBDb3Vzc29uIiA8
YmNvdXNzb25AYmF5bGlicmUuY29tPgpDYzogVG9ueSBMaW5kZ3JlbiA8dG9ueUBhdG9taWRlLmNv
bT4KQ2M6IFJ1c3NlbGwgS2luZyA8bGludXhAYXJtLmxpbnV4Lm9yZy51az4KQ2M6IGxpbnV4LW9t
YXBAdmdlci5rZXJuZWwub3JnCkNjOiBkZXZpY2V0cmVlLWRpc2N1c3NAbGlzdHMub3psYWJzLm9y
ZwpDYzogbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCkNjOiBsaW51eC1rZXJu
ZWxAdmdlci5rZXJuZWwub3JnClNpZ25lZC1vZmYtYnk6IEVkdWFyZG8gVmFsZW50aW4gPGVkdWFy
ZG8udmFsZW50aW5AdGkuY29tPgotLS0KIGFyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kg
fCAxMCArKysrKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspLCAyIGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kgYi9h
cmNoL2FybS9ib290L2R0cy9vbWFwNDQzeC5kdHNpCmluZGV4IGJjZjQ1NWUuLmU5Yzk3ZDYgMTAw
NjQ0Ci0tLSBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kKKysrIGIvYXJjaC9hcm0v
Ym9vdC9kdHMvb21hcDQ0M3guZHRzaQpAQCAtMTIsNyArMTIsNyBAQAogCiAvIHsKIAljcHVzIHsK
LQkJY3B1QDAgeworCQljcHUwOiBjcHVAMCB7CiAJCQkvKiBPTUFQNDQzeCB2YXJpYW50cyBPUFA1
MC1PUFBOVCAqLwogCQkJb3BlcmF0aW5nLXBvaW50cyA9IDwKIAkJCQkvKiBrSHogICAgdVYgKi8K
QEAgLTI1LDkgKzI1LDE1IEBACiAJCX07CiAJfTsKIAotCWJhbmRnYXAgeworCXRoZXJtYWwtem9u
ZXN7CisJCSNpbmNsdWRlICJvbWFwNC1jcHUtdGhlcm1hbC5kdHNpIgorCX07CisKKwliYW5kZ2Fw
OiBiYW5kZ2FwIHsKIAkJcmVnID0gPDB4NGEwMDIyNjAgMHg0CiAJCSAgICAgICAweDRhMDAyMzJD
IDB4ND47CiAJCWNvbXBhdGlibGUgPSAidGksb21hcDQ0MzAtYmFuZGdhcCI7CisKKwkJI3RoZXJt
YWwtc2Vuc29yLWNlbGxzID0gPDA+OwogCX07CiB9OwotLSAKMS44LjIuMS4zNDIuZ2ZhNzI4NWQK
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5z
b3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5s
bS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 12/18] arm: dts: add omap4460 thermal data
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..4d93aba 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -12,7 +12,7 @@
 / {
 	cpus {
 		/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
-		cpu@0 {
+		cpu0: cpu@0 {
 			operating-points = <
 				/* kHz    uV */
 				350000  1025000
@@ -30,12 +30,18 @@
 		ti,hwmods = "debugss";
 	};
 
-	bandgap {
+	thermal-zones{
+		#include "omap4-cpu-thermal.dtsi"
+	};
+
+	bandgap: bandgap {
 		reg = <0x4a002260 0x4
 		       0x4a00232C 0x4
 		       0x4a002378 0x18>;
 		compatible = "ti,omap4460-bandgap";
 		interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>; /* talert */
 		gpios = <&gpio3 22 0>; /* tshut */
+
+		#thermal-sensor-cells = <0>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 12/18] arm: dts: add omap4460 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..4d93aba 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -12,7 +12,7 @@
 / {
 	cpus {
 		/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
-		cpu@0 {
+		cpu0: cpu@0 {
 			operating-points = <
 				/* kHz    uV */
 				350000  1025000
@@ -30,12 +30,18 @@
 		ti,hwmods = "debugss";
 	};
 
-	bandgap {
+	thermal-zones{
+		#include "omap4-cpu-thermal.dtsi"
+	};
+
+	bandgap: bandgap {
 		reg = <0x4a002260 0x4
 		       0x4a00232C 0x4
 		       0x4a002378 0x18>;
 		compatible = "ti,omap4460-bandgap";
 		interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>; /* talert */
 		gpios = <&gpio3 22 0>; /* tshut */
+
+		#thermal-sensor-cells = <0>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 12/18] arm: dts: add omap4460 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..4d93aba 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -12,7 +12,7 @@
 / {
 	cpus {
 		/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			operating-points = <
 				/* kHz    uV */
 				350000  1025000
@@ -30,12 +30,18 @@
 		ti,hwmods = "debugss";
 	};
 
-	bandgap {
+	thermal-zones{
+		#include "omap4-cpu-thermal.dtsi"
+	};
+
+	bandgap: bandgap {
 		reg = <0x4a002260 0x4
 		       0x4a00232C 0x4
 		       0x4a002378 0x18>;
 		compatible = "ti,omap4460-bandgap";
 		interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>; /* talert */
 		gpios = <&gpio3 22 0>; /* tshut */
+
+		#thermal-sensor-cells = <0>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 12/18] arm: dts: add omap4460 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

VGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBkdHNpIGVudHJ5IG9uIG9tYXA0NDYwIHRvIGNvbnRhaW4K
dGhlIHRoZXJtYWwgZGF0YS4gVGhpcyBkYXRhIHdpbGwgZW5hYmxlIHRoZSBwYXNzaXZlCmNvb2xp
bmcgd2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlIGF0IDEwMEMgYW5kIHRoZQpzeXN0ZW0gd2ls
bCBkbyBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4KCkNjOiAiQmVub8OudCBDb3Vzc29uIiA8
YmNvdXNzb25AYmF5bGlicmUuY29tPgpDYzogVG9ueSBMaW5kZ3JlbiA8dG9ueUBhdG9taWRlLmNv
bT4KQ2M6IFJvYiBIZXJyaW5nIDxyb2IuaGVycmluZ0BjYWx4ZWRhLmNvbT4KQ2M6IFBhd2VsIE1v
bGwgPHBhd2VsLm1vbGxAYXJtLmNvbT4KQ2M6IE1hcmsgUnV0bGFuZCA8bWFyay5ydXRsYW5kQGFy
bS5jb20+CkNjOiBTdGVwaGVuIFdhcnJlbiA8c3dhcnJlbkB3d3dkb3Rvcmcub3JnPgpDYzogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6IFJ1c3NlbGwgS2luZyA8bGlu
dXhAYXJtLmxpbnV4Lm9yZy51az4KQ2M6IGxpbnV4LW9tYXBAdmdlci5rZXJuZWwub3JnCkNjOiBk
ZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZwpDYzogbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZy
YWRlYWQub3JnCkNjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnClNpZ25lZC1vZmYtYnk6
IEVkdWFyZG8gVmFsZW50aW4gPGVkdWFyZG8udmFsZW50aW5AdGkuY29tPgotLS0KIGFyY2gvYXJt
L2Jvb3QvZHRzL29tYXA0NDYwLmR0c2kgfCAxMCArKysrKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwg
OCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2Jv
b3QvZHRzL29tYXA0NDYwLmR0c2kgYi9hcmNoL2FybS9ib290L2R0cy9vbWFwNDQ2MC5kdHNpCmlu
ZGV4IGMyZjBmMzkuLjRkOTNhYmEgMTAwNjQ0Ci0tLSBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0
NDYwLmR0c2kKKysrIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQ0NjAuZHRzaQpAQCAtMTIsNyAr
MTIsNyBAQAogLyB7CiAJY3B1cyB7CiAJCS8qIE9NQVA0NDZ4ICdzdGFuZGFyZCBkZXZpY2UnIHZh
cmlhbnRzIE9QUDUwIHRvIE9QUFR1cmJvICovCi0JCWNwdUAwIHsKKwkJY3B1MDogY3B1QDAgewog
CQkJb3BlcmF0aW5nLXBvaW50cyA9IDwKIAkJCQkvKiBrSHogICAgdVYgKi8KIAkJCQkzNTAwMDAg
IDEwMjUwMDAKQEAgLTMwLDEyICszMCwxOCBAQAogCQl0aSxod21vZHMgPSAiZGVidWdzcyI7CiAJ
fTsKIAotCWJhbmRnYXAgeworCXRoZXJtYWwtem9uZXN7CisJCSNpbmNsdWRlICJvbWFwNC1jcHUt
dGhlcm1hbC5kdHNpIgorCX07CisKKwliYW5kZ2FwOiBiYW5kZ2FwIHsKIAkJcmVnID0gPDB4NGEw
MDIyNjAgMHg0CiAJCSAgICAgICAweDRhMDAyMzJDIDB4NAogCQkgICAgICAgMHg0YTAwMjM3OCAw
eDE4PjsKIAkJY29tcGF0aWJsZSA9ICJ0aSxvbWFwNDQ2MC1iYW5kZ2FwIjsKIAkJaW50ZXJydXB0
cyA9IDwwIDEyNiBJUlFfVFlQRV9MRVZFTF9ISUdIPjsgLyogdGFsZXJ0ICovCiAJCWdwaW9zID0g
PCZncGlvMyAyMiAwPjsgLyogdHNodXQgKi8KKworCQkjdGhlcm1hbC1zZW5zb3ItY2VsbHMgPSA8
MD47CiAJfTsKIH07Ci0tIAoxLjguMi4xLjM0Mi5nZmE3Mjg1ZAoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0Cmxt
LXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxt
YW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 13/18] arm: dts: add cooling properties on omap4430 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, devicetree-discuss,
	linux-arm-kernel

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index e9c97d6..930ab47 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,11 @@
 				1008000 1375000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+
+			/* cooling options */
+			cooling-min-level = <0>;
+			cooling-max-level = <3>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 13/18] arm: dts: add cooling properties on omap4430 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren-3lzwWm7+Weoh9ZMKESR00Q, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eduardo Valentin,
	Benoît Cousson, Tony Lindgren, Russell King,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Benoît Cousson" <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap443x.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index e9c97d6..930ab47 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,11 @@
 				1008000 1375000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+
+			/* cooling options */
+			cooling-min-level = <0>;
+			cooling-max-level = <3>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 13/18] arm: dts: add cooling properties on omap4430 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index e9c97d6..930ab47 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,11 @@
 				1008000 1375000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+
+			/* cooling options */
+			cooling-min-level = <0>;
+			cooling-max-level = <3>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 13/18] arm: dts: add cooling properties on omap4430 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, devicetree-discuss,
	linux-arm-kernel

T01BUDQ0MzAgZGV2aWNlcyBjYW4gcmVhY2ggaGlnaCB0ZW1wZXJhdHVyZXMgYW5kIHRodXMKbmVl
ZHMgdG8gaGF2ZSBjcHVmcmVxLWNvb2xpbmcgb24gc3lzdGVtcyBydW5uaW5nIG9uIGl0LgoKVGhp
cyBwYXRjaCBhZGRzIHRoZSByZXF1aXJlZCBjb29saW5nIGRldmljZSBwcm9wZXJ0aWVzCnNvIHRo
YXQgY3B1ZnJlcS1jcHUwIGRyaXZlciBsb2FkcyB0aGUgY29vbGluZyBkZXZpY2UuCgpDYzogIkJl
bm/DrnQgQ291c3NvbiIgPGJjb3Vzc29uQGJheWxpYnJlLmNvbT4KQ2M6IFRvbnkgTGluZGdyZW4g
PHRvbnlAYXRvbWlkZS5jb20+CkNjOiBSdXNzZWxsIEtpbmcgPGxpbnV4QGFybS5saW51eC5vcmcu
dWs+CkNjOiBsaW51eC1vbWFwQHZnZXIua2VybmVsLm9yZwpDYzogZGV2aWNldHJlZS1kaXNjdXNz
QGxpc3RzLm96bGFicy5vcmcKQ2M6IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9y
ZwpDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZwpTaWduZWQtb2ZmLWJ5OiBFZHVhcmRv
IFZhbGVudGluIDxlZHVhcmRvLnZhbGVudGluQHRpLmNvbT4KLS0tCiBhcmNoL2FybS9ib290L2R0
cy9vbWFwNDQzeC5kdHNpIHwgNSArKysrKwogMSBmaWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygr
KQoKZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kgYi9hcmNoL2Fy
bS9ib290L2R0cy9vbWFwNDQzeC5kdHNpCmluZGV4IGU5Yzk3ZDYuLjkzMGFiNDcgMTAwNjQ0Ci0t
LSBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kKKysrIGIvYXJjaC9hcm0vYm9vdC9k
dHMvb21hcDQ0M3guZHRzaQpAQCAtMjIsNiArMjIsMTEgQEAKIAkJCQkxMDA4MDAwIDEzNzUwMDAK
IAkJCT47CiAJCQljbG9jay1sYXRlbmN5ID0gPDMwMDAwMD47IC8qIEZyb20gbGVnYWN5IGRyaXZl
ciAqLworCisJCQkvKiBjb29saW5nIG9wdGlvbnMgKi8KKwkJCWNvb2xpbmctbWluLWxldmVsID0g
PDA+OworCQkJY29vbGluZy1tYXgtbGV2ZWwgPSA8Mz47CisJCQkjY29vbGluZy1jZWxscyA9IDwy
PjsgLyogbWluIGZvbGxvd2VkIGJ5IG1heCAqLwogCQl9OwogCX07CiAKLS0gCjEuOC4yLjEuMzQy
LmdmYTcyODVkCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRw
Oi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 14/18] arm: dts: add cooling properties on omap4460 cpu node
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

OMAP4460 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 4d93aba..dc22719 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -20,6 +20,11 @@
 				920000  1313000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+
+			/* cooling options */
+			cooling-min-level = <0>;
+			cooling-max-level = <2>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 14/18] arm: dts: add cooling properties on omap4460 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

OMAP4460 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 4d93aba..dc22719 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -20,6 +20,11 @@
 				920000  1313000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+
+			/* cooling options */
+			cooling-min-level = <0>;
+			cooling-max-level = <2>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 14/18] arm: dts: add cooling properties on omap4460 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

OMAP4460 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap4460.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 4d93aba..dc22719 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -20,6 +20,11 @@
 				920000  1313000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+
+			/* cooling options */
+			cooling-min-level = <0>;
+			cooling-max-level = <2>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 14/18] arm: dts: add cooling properties on omap4460 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

T01BUDQ0NjAgZGV2aWNlcyBjYW4gcmVhY2ggaGlnaCB0ZW1wZXJhdHVyZXMgYW5kIHRodXMKbmVl
ZHMgdG8gaGF2ZSBjcHVmcmVxLWNvb2xpbmcgb24gc3lzdGVtcyBydW5uaW5nIG9uIGl0LgoKVGhp
cyBwYXRjaCBhZGRzIHRoZSByZXF1aXJlZCBjb29saW5nIGRldmljZSBwcm9wZXJ0aWVzCnNvIHRo
YXQgY3B1ZnJlcS1jcHUwIGRyaXZlciBsb2FkcyB0aGUgY29vbGluZyBkZXZpY2UuCgpDYzogIkJl
bm/DrnQgQ291c3NvbiIgPGJjb3Vzc29uQGJheWxpYnJlLmNvbT4KQ2M6IFRvbnkgTGluZGdyZW4g
PHRvbnlAYXRvbWlkZS5jb20+CkNjOiBSb2IgSGVycmluZyA8cm9iLmhlcnJpbmdAY2FseGVkYS5j
b20+CkNjOiBQYXdlbCBNb2xsIDxwYXdlbC5tb2xsQGFybS5jb20+CkNjOiBNYXJrIFJ1dGxhbmQg
PG1hcmsucnV0bGFuZEBhcm0uY29tPgpDYzogU3RlcGhlbiBXYXJyZW4gPHN3YXJyZW5Ad3d3ZG90
b3JnLm9yZz4KQ2M6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkNjOiBS
dXNzZWxsIEtpbmcgPGxpbnV4QGFybS5saW51eC5vcmcudWs+CkNjOiBsaW51eC1vbWFwQHZnZXIu
a2VybmVsLm9yZwpDYzogZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGxpbnV4LWFybS1r
ZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9y
ZwpTaWduZWQtb2ZmLWJ5OiBFZHVhcmRvIFZhbGVudGluIDxlZHVhcmRvLnZhbGVudGluQHRpLmNv
bT4KLS0tCiBhcmNoL2FybS9ib290L2R0cy9vbWFwNDQ2MC5kdHNpIHwgNSArKysrKwogMSBmaWxl
IGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2Jvb3QvZHRz
L29tYXA0NDYwLmR0c2kgYi9hcmNoL2FybS9ib290L2R0cy9vbWFwNDQ2MC5kdHNpCmluZGV4IDRk
OTNhYmEuLmRjMjI3MTkgMTAwNjQ0Ci0tLSBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDYwLmR0
c2kKKysrIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQ0NjAuZHRzaQpAQCAtMjAsNiArMjAsMTEg
QEAKIAkJCQk5MjAwMDAgIDEzMTMwMDAKIAkJCT47CiAJCQljbG9jay1sYXRlbmN5ID0gPDMwMDAw
MD47IC8qIEZyb20gbGVnYWN5IGRyaXZlciAqLworCisJCQkvKiBjb29saW5nIG9wdGlvbnMgKi8K
KwkJCWNvb2xpbmctbWluLWxldmVsID0gPDA+OworCQkJY29vbGluZy1tYXgtbGV2ZWwgPSA8Mj47
CisJCQkjY29vbGluZy1jZWxscyA9IDwyPjsgLyogbWluIGZvbGxvd2VkIGJ5IG1heCAqLwogCQl9
OwogCX07CiAKLS0gCjEuOC4yLjEuMzQyLmdmYTcyODVkCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vu
c29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9s
aXN0aW5mby9sbS1zZW5zb3Jz

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 15/18] arm: dts: add omap5 GPU thermal data
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 0000000..8941c8e
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+gpu_thermal: gpu_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     1>;
+
+	trips {
+		gpu_crit: gpu_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 15/18] arm: dts: add omap5 GPU thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 0000000..8941c8e
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+gpu_thermal: gpu_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     1>;
+
+	trips {
+		gpu_crit: gpu_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 15/18] arm: dts: add omap5 GPU thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 0000000..8941c8e
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+gpu_thermal: gpu_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     1>;
+
+	trips {
+		gpu_crit: gpu_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 15/18] arm: dts: add omap5 GPU thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

VGhpcyBwYXRjaCBjaGFuZ2VzIGEgZHRzaSBmaWxlIHRvIGNvbnRhaW4gdGhlIHRoZXJtYWwgZGF0
YQpmb3IgR1BVIGRvbWFpbiBvbiBPTUFQNSBhbmQgbGF0ZXIgU29Dcy4gVGhpcyBkYXRhIHdpbGwK
ZW5hYmxlIGEgdGhlcm1hbCBzaHV0ZG93biBhdCAxMjVDLgoKVGhpcyB0aGVybWFsIGRhdGEgY2Fu
IGJlIHJldXNlZCBhY3Jvc3MgVEkgU29DIGRldmljZXMuCgpDYzogIkJlbm/DrnQgQ291c3NvbiIg
PGJjb3Vzc29uQGJheWxpYnJlLmNvbT4KQ2M6IFRvbnkgTGluZGdyZW4gPHRvbnlAYXRvbWlkZS5j
b20+CkNjOiBSb2IgSGVycmluZyA8cm9iLmhlcnJpbmdAY2FseGVkYS5jb20+CkNjOiBQYXdlbCBN
b2xsIDxwYXdlbC5tb2xsQGFybS5jb20+CkNjOiBNYXJrIFJ1dGxhbmQgPG1hcmsucnV0bGFuZEBh
cm0uY29tPgpDYzogU3RlcGhlbiBXYXJyZW4gPHN3YXJyZW5Ad3d3ZG90b3JnLm9yZz4KQ2M6IElh
biBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkNjOiBSdXNzZWxsIEtpbmcgPGxp
bnV4QGFybS5saW51eC5vcmcudWs+CkNjOiBsaW51eC1vbWFwQHZnZXIua2VybmVsLm9yZwpDYzog
ZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5m
cmFkZWFkLm9yZwpDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZwpTaWduZWQtb2ZmLWJ5
OiBFZHVhcmRvIFZhbGVudGluIDxlZHVhcmRvLnZhbGVudGluQHRpLmNvbT4KLS0tCiBhcmNoL2Fy
bS9ib290L2R0cy9vbWFwNS1ncHUtdGhlcm1hbC5kdHNpIHwgMjggKysrKysrKysrKysrKysrKysr
KysrKysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDI4IGluc2VydGlvbnMoKykKIGNyZWF0ZSBtb2Rl
IDEwMDY0NCBhcmNoL2FybS9ib290L2R0cy9vbWFwNS1ncHUtdGhlcm1hbC5kdHNpCgpkaWZmIC0t
Z2l0IGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUtZ3B1LXRoZXJtYWwuZHRzaSBiL2FyY2gvYXJt
L2Jvb3QvZHRzL29tYXA1LWdwdS10aGVybWFsLmR0c2kKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5k
ZXggMDAwMDAwMC4uODk0MWM4ZQotLS0gL2Rldi9udWxsCisrKyBiL2FyY2gvYXJtL2Jvb3QvZHRz
L29tYXA1LWdwdS10aGVybWFsLmR0c2kKQEAgLTAsMCArMSwyOCBAQAorLyoKKyAqIERldmljZSBU
cmVlIFNvdXJjZSBmb3IgT01BUDU0M3ggU29DIEdQVSB0aGVybWFsCisgKgorICogQ29weXJpZ2h0
IChDKSAyMDEzIFRleGFzIEluc3RydW1lbnRzIEluY29ycG9yYXRlZCAtIGh0dHA6Ly93d3cudGku
Y29tLworICogQ29udGFjdDogRWR1YXJkbyBWYWxlbnRpbiA8ZWR1YXJkby52YWxlbnRpbkB0aS5j
b20+CisgKgorICogVGhpcyBmaWxlIGlzIGxpY2Vuc2VkIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUg
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIHZlcnNpb24gMi4gIFRoaXMgcHJvZ3JhbSBp
cyBsaWNlbnNlZCAiYXMgaXMiIHdpdGhvdXQgYW55IHdhcnJhbnR5IG9mIGFueQorICoga2luZCwg
d2hldGhlciBleHByZXNzIG9yIGltcGxpZWQuCisgKi8KKworI2luY2x1ZGUgPGR0LWJpbmRpbmdz
L3RoZXJtYWwvdGhlcm1hbC5oPgorCitncHVfdGhlcm1hbDogZ3B1X3RoZXJtYWwgeworCXBvbGxp
bmctZGVsYXktcGFzc2l2ZSA9IDwyNTA+OyAvKiBtaWxsaXNlY29uZHMgKi8KKwlwb2xsaW5nLWRl
bGF5ID0gPDEwMDA+OyAvKiBtaWxsaXNlY29uZHMgKi8KKworCQkJLyogc2Vuc29yICAgICAgIElE
ICovCisJdGhlcm1hbC1zZW5zb3JzID0gPCZiYW5kZ2FwICAgICAxPjsKKworCXRyaXBzIHsKKwkJ
Z3B1X2NyaXQ6IGdwdV9jcml0IHsKKwkJCXRlbXBlcmF0dXJlID0gPDEyNTAwMD47IC8qIG1pbGxp
Q2Vsc2l1cyAqLworCQkJaHlzdGVyZXNpcyA9IDwyMDAwPjsgLyogbWlsbGlDZWxzaXVzICovCisJ
CQl0eXBlID0gVEhFUk1BTF9UUklQX0NSSVRJQ0FMOworCQl9OworCX07Cit9OwotLSAKMS44LjIu
MS4zNDIuZ2ZhNzI4NWQKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3Jn
Cmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 16/18] arm: dts: add omap5 CORE thermal data
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
  (?)
@ 2013-09-27  3:13   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5-core-thermal.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 0000000..3e9dc00
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+core_thermal: core_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     2>;
+
+	trips {
+		core_crit: core_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 16/18] arm: dts: add omap5 CORE thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5-core-thermal.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 0000000..3e9dc00
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+core_thermal: core_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     2>;
+
+	trips {
+		core_crit: core_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 16/18] arm: dts: add omap5 CORE thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.

This thermal data can be reused across TI SoC devices.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5-core-thermal.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 0000000..3e9dc00
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+core_thermal: core_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     2>;
+
+	trips {
+		core_crit: core_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = THERMAL_TRIP_CRITICAL;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 16/18] arm: dts: add omap5 CORE thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

VGhpcyBwYXRjaCBjaGFuZ2VzIGEgZHRzaSBmaWxlIHRvIGNvbnRhaW4gdGhlIHRoZXJtYWwgZGF0
YQpmb3IgQ09SRSBkb21haW4gb24gT01BUDUgYW5kIGxhdGVyIFNvQ3MuIFRoaXMgZGF0YSB3aWxs
CmVuYWJsZSBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4KClRoaXMgdGhlcm1hbCBkYXRhIGNh
biBiZSByZXVzZWQgYWNyb3NzIFRJIFNvQyBkZXZpY2VzLgoKQ2M6ICJCZW5vw650IENvdXNzb24i
IDxiY291c3NvbkBiYXlsaWJyZS5jb20+CkNjOiBUb255IExpbmRncmVuIDx0b255QGF0b21pZGUu
Y29tPgpDYzogUm9iIEhlcnJpbmcgPHJvYi5oZXJyaW5nQGNhbHhlZGEuY29tPgpDYzogUGF3ZWwg
TW9sbCA8cGF3ZWwubW9sbEBhcm0uY29tPgpDYzogTWFyayBSdXRsYW5kIDxtYXJrLnJ1dGxhbmRA
YXJtLmNvbT4KQ2M6IFN0ZXBoZW4gV2FycmVuIDxzd2FycmVuQHd3d2RvdG9yZy5vcmc+CkNjOiBJ
YW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpDYzogUnVzc2VsbCBLaW5nIDxs
aW51eEBhcm0ubGludXgub3JnLnVrPgpDYzogbGludXgtb21hcEB2Z2VyLmtlcm5lbC5vcmcKQ2M6
IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnCkNjOiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmlu
ZnJhZGVhZC5vcmcKQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcKU2lnbmVkLW9mZi1i
eTogRWR1YXJkbyBWYWxlbnRpbiA8ZWR1YXJkby52YWxlbnRpbkB0aS5jb20+Ci0tLQogYXJjaC9h
cm0vYm9vdC9kdHMvb21hcDUtY29yZS10aGVybWFsLmR0c2kgfCAyOCArKysrKysrKysrKysrKysr
KysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMjggaW5zZXJ0aW9ucygrKQogY3JlYXRlIG1v
ZGUgMTAwNjQ0IGFyY2gvYXJtL2Jvb3QvZHRzL29tYXA1LWNvcmUtdGhlcm1hbC5kdHNpCgpkaWZm
IC0tZ2l0IGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUtY29yZS10aGVybWFsLmR0c2kgYi9hcmNo
L2FybS9ib290L2R0cy9vbWFwNS1jb3JlLXRoZXJtYWwuZHRzaQpuZXcgZmlsZSBtb2RlIDEwMDY0
NAppbmRleCAwMDAwMDAwLi4zZTlkYzAwCi0tLSAvZGV2L251bGwKKysrIGIvYXJjaC9hcm0vYm9v
dC9kdHMvb21hcDUtY29yZS10aGVybWFsLmR0c2kKQEAgLTAsMCArMSwyOCBAQAorLyoKKyAqIERl
dmljZSBUcmVlIFNvdXJjZSBmb3IgT01BUDU0M3ggU29DIENPUkUgdGhlcm1hbAorICoKKyAqIENv
cHlyaWdodCAoQykgMjAxMyBUZXhhcyBJbnN0cnVtZW50cyBJbmNvcnBvcmF0ZWQgLSBodHRwOi8v
d3d3LnRpLmNvbS8KKyAqIENvbnRhY3Q6IEVkdWFyZG8gVmFsZW50aW4gPGVkdWFyZG8udmFsZW50
aW5AdGkuY29tPgorICoKKyAqIFRoaXMgZmlsZSBpcyBsaWNlbnNlZCB1bmRlciB0aGUgdGVybXMg
b2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiB2ZXJzaW9uIDIuICBUaGlzIHBy
b2dyYW0gaXMgbGljZW5zZWQgImFzIGlzIiB3aXRob3V0IGFueSB3YXJyYW50eSBvZiBhbnkKKyAq
IGtpbmQsIHdoZXRoZXIgZXhwcmVzcyBvciBpbXBsaWVkLgorICovCisKKyNpbmNsdWRlIDxkdC1i
aW5kaW5ncy90aGVybWFsL3RoZXJtYWwuaD4KKworY29yZV90aGVybWFsOiBjb3JlX3RoZXJtYWwg
eworCXBvbGxpbmctZGVsYXktcGFzc2l2ZSA9IDwyNTA+OyAvKiBtaWxsaXNlY29uZHMgKi8KKwlw
b2xsaW5nLWRlbGF5ID0gPDEwMDA+OyAvKiBtaWxsaXNlY29uZHMgKi8KKworCQkJLyogc2Vuc29y
ICAgICAgIElEICovCisJdGhlcm1hbC1zZW5zb3JzID0gPCZiYW5kZ2FwICAgICAyPjsKKworCXRy
aXBzIHsKKwkJY29yZV9jcml0OiBjb3JlX2NyaXQgeworCQkJdGVtcGVyYXR1cmUgPSA8MTI1MDAw
PjsgLyogbWlsbGlDZWxzaXVzICovCisJCQloeXN0ZXJlc2lzID0gPDIwMDA+OyAvKiBtaWxsaUNl
bHNpdXMgKi8KKwkJCXR5cGUgPSBUSEVSTUFMX1RSSVBfQ1JJVElDQUw7CisJCX07CisJfTsKK307
Ci0tIAoxLjguMi4xLjM0Mi5nZmE3Mjg1ZAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0t
c2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8v
bG0tc2Vuc29ycw=

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 17/18] arm: dts: add omap5 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..187cb71 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,7 +33,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		cpu@0 {
+		cpu0: cpu@0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
@@ -45,6 +45,12 @@
 		};
 	};
 
+	thermal-zones {
+		#include "omap4-cpu-thermal.dtsi"
+		#include "omap5-gpu-thermal.dtsi"
+		#include "omap5-core-thermal.dtsi"
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		/* PPI secure/nonsecure IRQ */
@@ -705,13 +711,15 @@
 			};
 		};
 
-		bandgap@4a0021e0 {
+		bandgap: bandgap@4a0021e0 {
 			reg = <0x4a0021e0 0xc
 			       0x4a00232c 0xc
 			       0x4a002380 0x2c
 			       0x4a0023C0 0x3c>;
 			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
 			compatible = "ti,omap5430-bandgap";
+
+			#thermal-sensor-cells = <1>;
 		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 17/18] arm: dts: add omap5 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren-3lzwWm7+Weoh9ZMKESR00Q, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eduardo Valentin,
	Benoît Cousson, Tony Lindgren, Russell King,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.

Cc: "Benoît Cousson" <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap5.dtsi | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..187cb71 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,7 +33,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		cpu@0 {
+		cpu0: cpu@0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
@@ -45,6 +45,12 @@
 		};
 	};
 
+	thermal-zones {
+		#include "omap4-cpu-thermal.dtsi"
+		#include "omap5-gpu-thermal.dtsi"
+		#include "omap5-core-thermal.dtsi"
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		/* PPI secure/nonsecure IRQ */
@@ -705,13 +711,15 @@
 			};
 		};
 
-		bandgap@4a0021e0 {
+		bandgap: bandgap@4a0021e0 {
 			reg = <0x4a0021e0 0xc
 			       0x4a00232c 0xc
 			       0x4a002380 0x2c
 			       0x4a0023C0 0x3c>;
 			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
 			compatible = "ti,omap5430-bandgap";
+
+			#thermal-sensor-cells = <1>;
 		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 17/18] arm: dts: add omap5 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..187cb71 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,7 +33,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
@@ -45,6 +45,12 @@
 		};
 	};
 
+	thermal-zones {
+		#include "omap4-cpu-thermal.dtsi"
+		#include "omap5-gpu-thermal.dtsi"
+		#include "omap5-core-thermal.dtsi"
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		/* PPI secure/nonsecure IRQ */
@@ -705,13 +711,15 @@
 			};
 		};
 
-		bandgap at 4a0021e0 {
+		bandgap: bandgap at 4a0021e0 {
 			reg = <0x4a0021e0 0xc
 			       0x4a00232c 0xc
 			       0x4a002380 0x2c
 			       0x4a0023C0 0x3c>;
 			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
 			compatible = "ti,omap5430-bandgap";
+
+			#thermal-sensor-cells = <1>;
 		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 17/18] arm: dts: add omap5 thermal data
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

VGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBkdHNpIGVudHJ5IG9uIG9tYXA1IHRvIGNvbnRhaW4KdGhl
IHRoZXJtYWwgZGF0YS4gVGhpcyBkYXRhIHdpbGwgZW5hYmxlIHRoZSBwYXNzaXZlCmNvb2xpbmcg
d2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlIGF0IDEwMEMuIFRoZQpzeXN0ZW0gd2lsbCBkbyBh
IHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1QyB3aGVuZXZlcgphbnkgb2YgaXRzIHNlbnNvcnMgc2Vl
cyB0aGlzIGxldmVsLgoKQ2M6ICJCZW5vw650IENvdXNzb24iIDxiY291c3NvbkBiYXlsaWJyZS5j
b20+CkNjOiBUb255IExpbmRncmVuIDx0b255QGF0b21pZGUuY29tPgpDYzogUm9iIEhlcnJpbmcg
PHJvYi5oZXJyaW5nQGNhbHhlZGEuY29tPgpDYzogUGF3ZWwgTW9sbCA8cGF3ZWwubW9sbEBhcm0u
Y29tPgpDYzogTWFyayBSdXRsYW5kIDxtYXJrLnJ1dGxhbmRAYXJtLmNvbT4KQ2M6IFN0ZXBoZW4g
V2FycmVuIDxzd2FycmVuQHd3d2RvdG9yZy5vcmc+CkNjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1w
YmVsbEBjaXRyaXguY29tPgpDYzogUnVzc2VsbCBLaW5nIDxsaW51eEBhcm0ubGludXgub3JnLnVr
PgpDYzogbGludXgtb21hcEB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGRldmljZXRyZWVAdmdlci5rZXJu
ZWwub3JnCkNjOiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKQ2M6IGxpbnV4
LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcKU2lnbmVkLW9mZi1ieTogRWR1YXJkbyBWYWxlbnRpbiA8
ZWR1YXJkby52YWxlbnRpbkB0aS5jb20+Ci0tLQogYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUuZHRz
aSB8IDEyICsrKysrKysrKystLQogMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKyksIDIg
ZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUuZHRzaSBi
L2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA1LmR0c2kKaW5kZXggN2NkZWExYi4uMTg3Y2I3MSAxMDA2
NDQKLS0tIGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUuZHRzaQorKysgYi9hcmNoL2FybS9ib290
L2R0cy9vbWFwNS5kdHNpCkBAIC0zMyw3ICszMyw3IEBACiAJCSNhZGRyZXNzLWNlbGxzID0gPDE+
OwogCQkjc2l6ZS1jZWxscyA9IDwwPjsKIAotCQljcHVAMCB7CisJCWNwdTA6IGNwdUAwIHsKIAkJ
CWRldmljZV90eXBlID0gImNwdSI7CiAJCQljb21wYXRpYmxlID0gImFybSxjb3J0ZXgtYTE1IjsK
IAkJCXJlZyA9IDwweDA+OwpAQCAtNDUsNiArNDUsMTIgQEAKIAkJfTsKIAl9OwogCisJdGhlcm1h
bC16b25lcyB7CisJCSNpbmNsdWRlICJvbWFwNC1jcHUtdGhlcm1hbC5kdHNpIgorCQkjaW5jbHVk
ZSAib21hcDUtZ3B1LXRoZXJtYWwuZHRzaSIKKwkJI2luY2x1ZGUgIm9tYXA1LWNvcmUtdGhlcm1h
bC5kdHNpIgorCX07CisKIAl0aW1lciB7CiAJCWNvbXBhdGlibGUgPSAiYXJtLGFybXY3LXRpbWVy
IjsKIAkJLyogUFBJIHNlY3VyZS9ub25zZWN1cmUgSVJRICovCkBAIC03MDUsMTMgKzcxMSwxNSBA
QAogCQkJfTsKIAkJfTsKIAotCQliYW5kZ2FwQDRhMDAyMWUwIHsKKwkJYmFuZGdhcDogYmFuZGdh
cEA0YTAwMjFlMCB7CiAJCQlyZWcgPSA8MHg0YTAwMjFlMCAweGMKIAkJCSAgICAgICAweDRhMDAy
MzJjIDB4YwogCQkJICAgICAgIDB4NGEwMDIzODAgMHgyYwogCQkJICAgICAgIDB4NGEwMDIzQzAg
MHgzYz47CiAJCQlpbnRlcnJ1cHRzID0gPEdJQ19TUEkgMTI2IElSUV9UWVBFX0xFVkVMX0hJR0g+
OwogCQkJY29tcGF0aWJsZSA9ICJ0aSxvbWFwNTQzMC1iYW5kZ2FwIjsKKworCQkJI3RoZXJtYWwt
c2Vuc29yLWNlbGxzID0gPDE+OwogCQl9OwogCX07CiB9OwotLSAKMS44LjIuMS4zNDIuZ2ZhNzI4
NWQKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1z
ZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0
cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 18/18] arm: dts: add cooling properties on omap5 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 187cb71..a35cd61 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -37,6 +37,9 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
+
+			/* cooling options */
+			#cooling-cells = <2>; /* min followed by max */
 		};
 		cpu@1 {
 			device_type = "cpu";
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 18/18] arm: dts: add cooling properties on omap5 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren-3lzwWm7+Weoh9ZMKESR00Q, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eduardo Valentin,
	Benoît Cousson, Tony Lindgren, Russell King,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Benoît Cousson" <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap5.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 187cb71..a35cd61 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -37,6 +37,9 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
+
+			/* cooling options */
+			#cooling-cells = <2>; /* min followed by max */
 		};
 		cpu@1 {
 			device_type = "cpu";
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv4 18/18] arm: dts: add cooling properties on omap5 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: linux-arm-kernel

OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.

Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 187cb71..a35cd61 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -37,6 +37,9 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a15";
 			reg = <0x0>;
+
+			/* cooling options */
+			#cooling-cells = <2>; /* min followed by max */
 		};
 		cpu at 1 {
 			device_type = "cpu";
-- 
1.8.2.1.342.gfa7285d

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv4 18/18] arm: dts: add cooling properties on omap5 cpu node
@ 2013-09-27  3:13   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:13 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin, Benoît Cousson,
	Tony Lindgren, Russell King, linux-omap, linux-arm-kernel

T01BUDUgZGV2aWNlcyBjYW4gcmVhY2ggaGlnaCB0ZW1wZXJhdHVyZXMgYW5kIHRodXMKbmVlZHMg
dG8gaGF2ZSBjcHVmcmVxLWNvb2xpbmcgb24gc3lzdGVtcyBydW5uaW5nIG9uIGl0LgoKVGhpcyBw
YXRjaCBhZGRzIHRoZSByZXF1aXJlZCBjb29saW5nIGRldmljZSBwcm9wZXJ0aWVzCnNvIHRoYXQg
Y3B1ZnJlcS1jcHUwIGRyaXZlciBsb2FkcyB0aGUgY29vbGluZyBkZXZpY2UuCgpDYzogIkJlbm/D
rnQgQ291c3NvbiIgPGJjb3Vzc29uQGJheWxpYnJlLmNvbT4KQ2M6IFRvbnkgTGluZGdyZW4gPHRv
bnlAYXRvbWlkZS5jb20+CkNjOiBSb2IgSGVycmluZyA8cm9iLmhlcnJpbmdAY2FseGVkYS5jb20+
CkNjOiBQYXdlbCBNb2xsIDxwYXdlbC5tb2xsQGFybS5jb20+CkNjOiBNYXJrIFJ1dGxhbmQgPG1h
cmsucnV0bGFuZEBhcm0uY29tPgpDYzogU3RlcGhlbiBXYXJyZW4gPHN3YXJyZW5Ad3d3ZG90b3Jn
Lm9yZz4KQ2M6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkNjOiBSdXNz
ZWxsIEtpbmcgPGxpbnV4QGFybS5saW51eC5vcmcudWs+CkNjOiBsaW51eC1vbWFwQHZnZXIua2Vy
bmVsLm9yZwpDYzogZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGxpbnV4LWFybS1rZXJu
ZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZwpT
aWduZWQtb2ZmLWJ5OiBFZHVhcmRvIFZhbGVudGluIDxlZHVhcmRvLnZhbGVudGluQHRpLmNvbT4K
LS0tCiBhcmNoL2FybS9ib290L2R0cy9vbWFwNS5kdHNpIHwgMyArKysKIDEgZmlsZSBjaGFuZ2Vk
LCAzIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9hcmNoL2FybS9ib290L2R0cy9vbWFwNS5k
dHNpIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUuZHRzaQppbmRleCAxODdjYjcxLi5hMzVjZDYx
IDEwMDY0NAotLS0gYS9hcmNoL2FybS9ib290L2R0cy9vbWFwNS5kdHNpCisrKyBiL2FyY2gvYXJt
L2Jvb3QvZHRzL29tYXA1LmR0c2kKQEAgLTM3LDYgKzM3LDkgQEAKIAkJCWRldmljZV90eXBlID0g
ImNwdSI7CiAJCQljb21wYXRpYmxlID0gImFybSxjb3J0ZXgtYTE1IjsKIAkJCXJlZyA9IDwweDA+
OworCisJCQkvKiBjb29saW5nIG9wdGlvbnMgKi8KKwkJCSNjb29saW5nLWNlbGxzID0gPDI+OyAv
KiBtaW4gZm9sbG93ZWQgYnkgbWF4ICovCiAJCX07CiAJCWNwdUAxIHsKIAkJCWRldmljZV90eXBl
ID0gImNwdSI7Ci0tIAoxLjguMi4xLjM0Mi5nZmE3Mjg1ZAoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNl
bnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4v
bGlzdGluZm8vbG0tc2Vuc29ycw=

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
  2013-09-27  3:13 ` Eduardo Valentin
  (?)
@ 2013-09-27  3:15   ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:15 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni, grant.likely, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 4305 bytes --]

On 26-09-2013 23:13, Eduardo Valentin wrote:
> Hello all,
> 
> Here is the continuation of work of representing hardware thermal properties
> in device tree infrastructure. The present patch series is the fourth version
> of this work. Previous versions were sent as RFCs and can be found here:
> V3: 

Too fast, hit send too early. For those interested, here is the link to V3:
https://lkml.org/lkml/2013/9/15/122

> RFCv2: http://lkml.org/lkml/2013/8/23/594
> RFCv1: http://lkml.org/lkml/2013/7/22/319
> 
> Major difference from V3 is on the parser itself. I have updated the binding
> documentation and improved the code accordingly to previous comments mainly
> from Mark R. and Joe P.
> 
> The changes on hwmon drivers have been accepted by Guenter, and in this
> series I am including his Acked-by, as I didn't change anything on that side.
> 
> I also found a bug while using all involved code built as modules, thus
> I have reworked a bit the cooling device registration part. This is why
> there are two new patches in this series (patches 02 and 04).
> 
> Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7,
> although this series is not including the DRA7 part (I will be sending separately).
> 
> Thanks all who have been contributing reviewing this code.
> 
> All best,
> 
> Eduardo Valentin (18):
>   thermal: allow registering without .get_temp
>   thermal: core: allow binding via .bind when tzp is present
>   thermal: introduce device tree parser
>   thermal: core: introduce thermal_of_cooling_device_register
>   thermal: cpu_cooling: introduce of_cpufreq_cooling_register
>   cpufreq: cpufreq-cpu0: add dt node parsing for cooling device
>     properties
>   hwmon: lm75: expose to thermal fw via DT nodes
>   hwmon: tmp102: expose to thermal fw via DT nodes
>   thermal: ti-soc-thermal: use thermal DT infrastructure
>   arm: dts: add omap4 CPU thermal data
>   arm: dts: add omap4430 thermal data
>   arm: dts: add omap4460 thermal data
>   arm: dts: add cooling properties on omap4430 cpu node
>   arm: dts: add cooling properties on omap4460 cpu node
>   arm: dts: add omap5 GPU thermal data
>   arm: dts: add omap5 CORE thermal data
>   arm: dts: add omap5 thermal data
>   arm: dts: add cooling properties on omap5 cpu node
> 
>  .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   7 +
>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>  arch/arm/boot/dts/omap4-cpu-thermal.dtsi           |  41 +
>  arch/arm/boot/dts/omap443x.dtsi                    |  15 +-
>  arch/arm/boot/dts/omap4460.dtsi                    |  15 +-
>  arch/arm/boot/dts/omap5-core-thermal.dtsi          |  28 +
>  arch/arm/boot/dts/omap5-gpu-thermal.dtsi           |  28 +
>  arch/arm/boot/dts/omap5.dtsi                       |  15 +-
>  drivers/cpufreq/Kconfig                            |   2 +-
>  drivers/cpufreq/cpufreq-cpu0.c                     |  16 +
>  drivers/hwmon/lm75.c                               |  35 +-
>  drivers/hwmon/tmp102.c                             |  19 +
>  drivers/thermal/Kconfig                            |  14 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/cpu_cooling.c                      |  56 +-
>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>  drivers/thermal/thermal_core.c                     |  79 +-
>  drivers/thermal/thermal_core.h                     |   9 +
>  drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  77 +-
>  include/dt-bindings/thermal/thermal.h              |  27 +
>  include/linux/cpu_cooling.h                        |  25 +
>  include/linux/thermal.h                            |  32 +-
>  22 files changed, 1880 insertions(+), 43 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
>  create mode 100644 drivers/thermal/of-thermal.c
>  create mode 100644 include/dt-bindings/thermal/thermal.h
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
@ 2013-09-27  3:15   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:15 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni, grant.likely, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 4305 bytes --]

On 26-09-2013 23:13, Eduardo Valentin wrote:
> Hello all,
> 
> Here is the continuation of work of representing hardware thermal properties
> in device tree infrastructure. The present patch series is the fourth version
> of this work. Previous versions were sent as RFCs and can be found here:
> V3: 

Too fast, hit send too early. For those interested, here is the link to V3:
https://lkml.org/lkml/2013/9/15/122

> RFCv2: http://lkml.org/lkml/2013/8/23/594
> RFCv1: http://lkml.org/lkml/2013/7/22/319
> 
> Major difference from V3 is on the parser itself. I have updated the binding
> documentation and improved the code accordingly to previous comments mainly
> from Mark R. and Joe P.
> 
> The changes on hwmon drivers have been accepted by Guenter, and in this
> series I am including his Acked-by, as I didn't change anything on that side.
> 
> I also found a bug while using all involved code built as modules, thus
> I have reworked a bit the cooling device registration part. This is why
> there are two new patches in this series (patches 02 and 04).
> 
> Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7,
> although this series is not including the DRA7 part (I will be sending separately).
> 
> Thanks all who have been contributing reviewing this code.
> 
> All best,
> 
> Eduardo Valentin (18):
>   thermal: allow registering without .get_temp
>   thermal: core: allow binding via .bind when tzp is present
>   thermal: introduce device tree parser
>   thermal: core: introduce thermal_of_cooling_device_register
>   thermal: cpu_cooling: introduce of_cpufreq_cooling_register
>   cpufreq: cpufreq-cpu0: add dt node parsing for cooling device
>     properties
>   hwmon: lm75: expose to thermal fw via DT nodes
>   hwmon: tmp102: expose to thermal fw via DT nodes
>   thermal: ti-soc-thermal: use thermal DT infrastructure
>   arm: dts: add omap4 CPU thermal data
>   arm: dts: add omap4430 thermal data
>   arm: dts: add omap4460 thermal data
>   arm: dts: add cooling properties on omap4430 cpu node
>   arm: dts: add cooling properties on omap4460 cpu node
>   arm: dts: add omap5 GPU thermal data
>   arm: dts: add omap5 CORE thermal data
>   arm: dts: add omap5 thermal data
>   arm: dts: add cooling properties on omap5 cpu node
> 
>  .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   7 +
>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>  arch/arm/boot/dts/omap4-cpu-thermal.dtsi           |  41 +
>  arch/arm/boot/dts/omap443x.dtsi                    |  15 +-
>  arch/arm/boot/dts/omap4460.dtsi                    |  15 +-
>  arch/arm/boot/dts/omap5-core-thermal.dtsi          |  28 +
>  arch/arm/boot/dts/omap5-gpu-thermal.dtsi           |  28 +
>  arch/arm/boot/dts/omap5.dtsi                       |  15 +-
>  drivers/cpufreq/Kconfig                            |   2 +-
>  drivers/cpufreq/cpufreq-cpu0.c                     |  16 +
>  drivers/hwmon/lm75.c                               |  35 +-
>  drivers/hwmon/tmp102.c                             |  19 +
>  drivers/thermal/Kconfig                            |  14 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/cpu_cooling.c                      |  56 +-
>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>  drivers/thermal/thermal_core.c                     |  79 +-
>  drivers/thermal/thermal_core.h                     |   9 +
>  drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  77 +-
>  include/dt-bindings/thermal/thermal.h              |  27 +
>  include/linux/cpu_cooling.h                        |  25 +
>  include/linux/thermal.h                            |  32 +-
>  22 files changed, 1880 insertions(+), 43 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
>  create mode 100644 drivers/thermal/of-thermal.c
>  create mode 100644 include/dt-bindings/thermal/thermal.h
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
@ 2013-09-27  3:15   ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27  3:15 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni, grant.likely, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 4305 bytes --]

On 26-09-2013 23:13, Eduardo Valentin wrote:
> Hello all,
> 
> Here is the continuation of work of representing hardware thermal properties
> in device tree infrastructure. The present patch series is the fourth version
> of this work. Previous versions were sent as RFCs and can be found here:
> V3: 

Too fast, hit send too early. For those interested, here is the link to V3:
https://lkml.org/lkml/2013/9/15/122

> RFCv2: http://lkml.org/lkml/2013/8/23/594
> RFCv1: http://lkml.org/lkml/2013/7/22/319
> 
> Major difference from V3 is on the parser itself. I have updated the binding
> documentation and improved the code accordingly to previous comments mainly
> from Mark R. and Joe P.
> 
> The changes on hwmon drivers have been accepted by Guenter, and in this
> series I am including his Acked-by, as I didn't change anything on that side.
> 
> I also found a bug while using all involved code built as modules, thus
> I have reworked a bit the cooling device registration part. This is why
> there are two new patches in this series (patches 02 and 04).
> 
> Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7,
> although this series is not including the DRA7 part (I will be sending separately).
> 
> Thanks all who have been contributing reviewing this code.
> 
> All best,
> 
> Eduardo Valentin (18):
>   thermal: allow registering without .get_temp
>   thermal: core: allow binding via .bind when tzp is present
>   thermal: introduce device tree parser
>   thermal: core: introduce thermal_of_cooling_device_register
>   thermal: cpu_cooling: introduce of_cpufreq_cooling_register
>   cpufreq: cpufreq-cpu0: add dt node parsing for cooling device
>     properties
>   hwmon: lm75: expose to thermal fw via DT nodes
>   hwmon: tmp102: expose to thermal fw via DT nodes
>   thermal: ti-soc-thermal: use thermal DT infrastructure
>   arm: dts: add omap4 CPU thermal data
>   arm: dts: add omap4430 thermal data
>   arm: dts: add omap4460 thermal data
>   arm: dts: add cooling properties on omap4430 cpu node
>   arm: dts: add cooling properties on omap4460 cpu node
>   arm: dts: add omap5 GPU thermal data
>   arm: dts: add omap5 CORE thermal data
>   arm: dts: add omap5 thermal data
>   arm: dts: add cooling properties on omap5 cpu node
> 
>  .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |   7 +
>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>  arch/arm/boot/dts/omap4-cpu-thermal.dtsi           |  41 +
>  arch/arm/boot/dts/omap443x.dtsi                    |  15 +-
>  arch/arm/boot/dts/omap4460.dtsi                    |  15 +-
>  arch/arm/boot/dts/omap5-core-thermal.dtsi          |  28 +
>  arch/arm/boot/dts/omap5-gpu-thermal.dtsi           |  28 +
>  arch/arm/boot/dts/omap5.dtsi                       |  15 +-
>  drivers/cpufreq/Kconfig                            |   2 +-
>  drivers/cpufreq/cpufreq-cpu0.c                     |  16 +
>  drivers/hwmon/lm75.c                               |  35 +-
>  drivers/hwmon/tmp102.c                             |  19 +
>  drivers/thermal/Kconfig                            |  14 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/cpu_cooling.c                      |  56 +-
>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>  drivers/thermal/thermal_core.c                     |  79 +-
>  drivers/thermal/thermal_core.h                     |   9 +
>  drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  77 +-
>  include/dt-bindings/thermal/thermal.h              |  27 +
>  include/linux/cpu_cooling.h                        |  25 +
>  include/linux/thermal.h                            |  32 +-
>  22 files changed, 1880 insertions(+), 43 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
>  create mode 100644 drivers/thermal/of-thermal.c
>  create mode 100644 include/dt-bindings/thermal/thermal.h
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
  2013-09-27  3:13   ` Eduardo Valentin
  (?)
  (?)
@ 2013-09-27 12:24     ` Nishanth Menon
  -1 siblings, 0 replies; 101+ messages in thread
From: Nishanth Menon @ 2013-09-27 12:24 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni, devicetree, durgadoss.r, linux-pm,
	Tony Lindgren, devicetree-discuss, linux-kernel, lm-sensors,
	Benoît Cousson, grant.likely, Russell King, linux-omap,
	linux-arm-kernel

On 23:13-20130926, Eduardo Valentin wrote:
> This patch changes the dtsi entry on omap4430 to contain
> the thermal data. This data will enable the passive
> cooling with CPUfreq cooling device at 100C and the
> system will do a thermal shutdown at 125C.
> 
> Cc: "Benoît Cousson" <bcousson@baylibre.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
> index bcf455e..e9c97d6 100644
> --- a/arch/arm/boot/dts/omap443x.dtsi
> +++ b/arch/arm/boot/dts/omap443x.dtsi
> @@ -12,7 +12,7 @@
>  
>  / {
>  	cpus {
> -		cpu@0 {
> +		cpu0: cpu@0 {
>  			/* OMAP443x variants OPP50-OPPNT */
>  			operating-points = <
>  				/* kHz    uV */
> @@ -25,9 +25,15 @@
>  		};
>  	};
>  
> -	bandgap {
> +	thermal-zones{
> +		#include "omap4-cpu-thermal.dtsi"
> +	};
> +
> +	bandgap: bandgap {
>  		reg = <0x4a002260 0x4
>  		       0x4a00232C 0x4>;
>  		compatible = "ti,omap4430-bandgap";
> +
> +		#thermal-sensor-cells = <0>;
2 cents:
we might want to move bandgap under ocp?

>  	};
>  };
> -- 
> 1.8.2.1.342.gfa7285d
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 12:24     ` Nishanth Menon
  0 siblings, 0 replies; 101+ messages in thread
From: Nishanth Menon @ 2013-09-27 12:24 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: mark.rutland, devicetree, wni, durgadoss.r, ian.campbell,
	pawel.moll, swarren, Tony Lindgren, devicetree-discuss, linux-pm,
	linux-kernel, rob.herring, lm-sensors, linux-arm-kernel,
	Benoît Cousson, grant.likely, Russell King, rui.zhang,
	linux-omap, linux

On 23:13-20130926, Eduardo Valentin wrote:
> This patch changes the dtsi entry on omap4430 to contain
> the thermal data. This data will enable the passive
> cooling with CPUfreq cooling device at 100C and the
> system will do a thermal shutdown at 125C.
> 
> Cc: "Benoît Cousson" <bcousson@baylibre.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
> index bcf455e..e9c97d6 100644
> --- a/arch/arm/boot/dts/omap443x.dtsi
> +++ b/arch/arm/boot/dts/omap443x.dtsi
> @@ -12,7 +12,7 @@
>  
>  / {
>  	cpus {
> -		cpu@0 {
> +		cpu0: cpu@0 {
>  			/* OMAP443x variants OPP50-OPPNT */
>  			operating-points = <
>  				/* kHz    uV */
> @@ -25,9 +25,15 @@
>  		};
>  	};
>  
> -	bandgap {
> +	thermal-zones{
> +		#include "omap4-cpu-thermal.dtsi"
> +	};
> +
> +	bandgap: bandgap {
>  		reg = <0x4a002260 0x4
>  		       0x4a00232C 0x4>;
>  		compatible = "ti,omap4430-bandgap";
> +
> +		#thermal-sensor-cells = <0>;
2 cents:
we might want to move bandgap under ocp?

>  	};
>  };
> -- 
> 1.8.2.1.342.gfa7285d
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 12:24     ` Nishanth Menon
  0 siblings, 0 replies; 101+ messages in thread
From: Nishanth Menon @ 2013-09-27 12:24 UTC (permalink / raw)
  To: linux-arm-kernel

On 23:13-20130926, Eduardo Valentin wrote:
> This patch changes the dtsi entry on omap4430 to contain
> the thermal data. This data will enable the passive
> cooling with CPUfreq cooling device at 100C and the
> system will do a thermal shutdown at 125C.
> 
> Cc: "Beno?t Cousson" <bcousson@baylibre.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-omap at vger.kernel.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
> index bcf455e..e9c97d6 100644
> --- a/arch/arm/boot/dts/omap443x.dtsi
> +++ b/arch/arm/boot/dts/omap443x.dtsi
> @@ -12,7 +12,7 @@
>  
>  / {
>  	cpus {
> -		cpu at 0 {
> +		cpu0: cpu at 0 {
>  			/* OMAP443x variants OPP50-OPPNT */
>  			operating-points = <
>  				/* kHz    uV */
> @@ -25,9 +25,15 @@
>  		};
>  	};
>  
> -	bandgap {
> +	thermal-zones{
> +		#include "omap4-cpu-thermal.dtsi"
> +	};
> +
> +	bandgap: bandgap {
>  		reg = <0x4a002260 0x4
>  		       0x4a00232C 0x4>;
>  		compatible = "ti,omap4430-bandgap";
> +
> +		#thermal-sensor-cells = <0>;
2 cents:
we might want to move bandgap under ocp?

>  	};
>  };
> -- 
> 1.8.2.1.342.gfa7285d
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 12:24     ` Nishanth Menon
  0 siblings, 0 replies; 101+ messages in thread
From: Nishanth Menon @ 2013-09-27 12:24 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni, devicetree, durgadoss.r, linux-pm,
	Tony Lindgren, devicetree-discuss, linux-kernel, lm-sensors,
	Benoît Cousson, grant.likely, Russell King, linux-omap,
	linux-arm-kernel

On 23:13-20130926, Eduardo Valentin wrote:
> This patch changes the dtsi entry on omap4430 to contain
> the thermal data. This data will enable the passive
> cooling with CPUfreq cooling device at 100C and the
> system will do a thermal shutdown at 125C.
> 
> Cc: "Benoît Cousson" <bcousson@baylibre.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
> index bcf455e..e9c97d6 100644
> --- a/arch/arm/boot/dts/omap443x.dtsi
> +++ b/arch/arm/boot/dts/omap443x.dtsi
> @@ -12,7 +12,7 @@
>  
>  / {
>  	cpus {
> -		cpu@0 {
> +		cpu0: cpu@0 {
>  			/* OMAP443x variants OPP50-OPPNT */
>  			operating-points = <
>  				/* kHz    uV */
> @@ -25,9 +25,15 @@
>  		};
>  	};
>  
> -	bandgap {
> +	thermal-zones{
> +		#include "omap4-cpu-thermal.dtsi"
> +	};
> +
> +	bandgap: bandgap {
>  		reg = <0x4a002260 0x4
>  		       0x4a00232C 0x4>;
>  		compatible = "ti,omap4430-bandgap";
> +
> +		#thermal-sensor-cells = <0>;
2 cents:
we might want to move bandgap under ocp?

>  	};
>  };
> -- 
> 1.8.2.1.342.gfa7285d
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Regards,
Nishanth Menon

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
  2013-09-27 12:24     ` Nishanth Menon
  (?)
  (?)
@ 2013-09-27 13:20       ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:20 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Eduardo Valentin, swarren, pawel.moll, mark.rutland,
	ian.campbell, rob.herring, linux, rui.zhang, wni, devicetree,
	durgadoss.r, linux-pm, Tony Lindgren, devicetree-discuss,
	linux-kernel, lm-sensors, Benoît Cousson, grant.likely,
	Russell King, linux-omap, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

On 27-09-2013 08:24, Nishanth Menon wrote:
> On 23:13-20130926, Eduardo Valentin wrote:
>> This patch changes the dtsi entry on omap4430 to contain
>> the thermal data. This data will enable the passive
>> cooling with CPUfreq cooling device at 100C and the
>> system will do a thermal shutdown at 125C.
>>
>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>> index bcf455e..e9c97d6 100644
>> --- a/arch/arm/boot/dts/omap443x.dtsi
>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>> @@ -12,7 +12,7 @@
>>  
>>  / {
>>  	cpus {
>> -		cpu@0 {
>> +		cpu0: cpu@0 {
>>  			/* OMAP443x variants OPP50-OPPNT */
>>  			operating-points = <
>>  				/* kHz    uV */
>> @@ -25,9 +25,15 @@
>>  		};
>>  	};
>>  
>> -	bandgap {
>> +	thermal-zones{
>> +		#include "omap4-cpu-thermal.dtsi"
>> +	};
>> +
>> +	bandgap: bandgap {
>>  		reg = <0x4a002260 0x4
>>  		       0x4a00232C 0x4>;
>>  		compatible = "ti,omap4430-bandgap";
>> +
>> +		#thermal-sensor-cells = <0>;
> 2 cents:
> we might want to move bandgap under ocp?
> 

Yes, agreed. But I don't think this change is related to this patch or
to this series.

Tks Nishanth

>>  	};
>>  };
>> -- 
>> 1.8.2.1.342.gfa7285d
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:20       ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:20 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: mark.rutland, devicetree, wni, durgadoss.r, ian.campbell,
	pawel.moll, swarren, Tony Lindgren, devicetree-discuss, linux-pm,
	linux-kernel, rob.herring, lm-sensors, Eduardo Valentin,
	linux-arm-kernel, Benoît Cousson, grant.likely,
	Russell King, rui.zhang, linux-omap, linux


[-- Attachment #1.1: Type: text/plain, Size: 2008 bytes --]

On 27-09-2013 08:24, Nishanth Menon wrote:
> On 23:13-20130926, Eduardo Valentin wrote:
>> This patch changes the dtsi entry on omap4430 to contain
>> the thermal data. This data will enable the passive
>> cooling with CPUfreq cooling device at 100C and the
>> system will do a thermal shutdown at 125C.
>>
>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>> index bcf455e..e9c97d6 100644
>> --- a/arch/arm/boot/dts/omap443x.dtsi
>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>> @@ -12,7 +12,7 @@
>>  
>>  / {
>>  	cpus {
>> -		cpu@0 {
>> +		cpu0: cpu@0 {
>>  			/* OMAP443x variants OPP50-OPPNT */
>>  			operating-points = <
>>  				/* kHz    uV */
>> @@ -25,9 +25,15 @@
>>  		};
>>  	};
>>  
>> -	bandgap {
>> +	thermal-zones{
>> +		#include "omap4-cpu-thermal.dtsi"
>> +	};
>> +
>> +	bandgap: bandgap {
>>  		reg = <0x4a002260 0x4
>>  		       0x4a00232C 0x4>;
>>  		compatible = "ti,omap4430-bandgap";
>> +
>> +		#thermal-sensor-cells = <0>;
> 2 cents:
> we might want to move bandgap under ocp?
> 

Yes, agreed. But I don't think this change is related to this patch or
to this series.

Tks Nishanth

>>  	};
>>  };
>> -- 
>> 1.8.2.1.342.gfa7285d
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:20       ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:20 UTC (permalink / raw)
  To: linux-arm-kernel

On 27-09-2013 08:24, Nishanth Menon wrote:
> On 23:13-20130926, Eduardo Valentin wrote:
>> This patch changes the dtsi entry on omap4430 to contain
>> the thermal data. This data will enable the passive
>> cooling with CPUfreq cooling device at 100C and the
>> system will do a thermal shutdown at 125C.
>>
>> Cc: "Beno?t Cousson" <bcousson@baylibre.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-omap at vger.kernel.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>> index bcf455e..e9c97d6 100644
>> --- a/arch/arm/boot/dts/omap443x.dtsi
>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>> @@ -12,7 +12,7 @@
>>  
>>  / {
>>  	cpus {
>> -		cpu at 0 {
>> +		cpu0: cpu at 0 {
>>  			/* OMAP443x variants OPP50-OPPNT */
>>  			operating-points = <
>>  				/* kHz    uV */
>> @@ -25,9 +25,15 @@
>>  		};
>>  	};
>>  
>> -	bandgap {
>> +	thermal-zones{
>> +		#include "omap4-cpu-thermal.dtsi"
>> +	};
>> +
>> +	bandgap: bandgap {
>>  		reg = <0x4a002260 0x4
>>  		       0x4a00232C 0x4>;
>>  		compatible = "ti,omap4430-bandgap";
>> +
>> +		#thermal-sensor-cells = <0>;
> 2 cents:
> we might want to move bandgap under ocp?
> 

Yes, agreed. But I don't think this change is related to this patch or
to this series.

Tks Nishanth

>>  	};
>>  };
>> -- 
>> 1.8.2.1.342.gfa7285d
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130927/def0a093/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:20       ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:20 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Eduardo Valentin, swarren, pawel.moll, mark.rutland,
	ian.campbell, rob.herring, linux, rui.zhang, wni, devicetree,
	durgadoss.r, linux-pm, Tony Lindgren, devicetree-discuss,
	linux-kernel, lm-sensors, Benoît Cousson, grant.likely,
	Russell King, linux-omap, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 2008 bytes --]

On 27-09-2013 08:24, Nishanth Menon wrote:
> On 23:13-20130926, Eduardo Valentin wrote:
>> This patch changes the dtsi entry on omap4430 to contain
>> the thermal data. This data will enable the passive
>> cooling with CPUfreq cooling device at 100C and the
>> system will do a thermal shutdown at 125C.
>>
>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>> index bcf455e..e9c97d6 100644
>> --- a/arch/arm/boot/dts/omap443x.dtsi
>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>> @@ -12,7 +12,7 @@
>>  
>>  / {
>>  	cpus {
>> -		cpu@0 {
>> +		cpu0: cpu@0 {
>>  			/* OMAP443x variants OPP50-OPPNT */
>>  			operating-points = <
>>  				/* kHz    uV */
>> @@ -25,9 +25,15 @@
>>  		};
>>  	};
>>  
>> -	bandgap {
>> +	thermal-zones{
>> +		#include "omap4-cpu-thermal.dtsi"
>> +	};
>> +
>> +	bandgap: bandgap {
>>  		reg = <0x4a002260 0x4
>>  		       0x4a00232C 0x4>;
>>  		compatible = "ti,omap4430-bandgap";
>> +
>> +		#thermal-sensor-cells = <0>;
> 2 cents:
> we might want to move bandgap under ocp?
> 

Yes, agreed. But I don't think this change is related to this patch or
to this series.

Tks Nishanth

>>  	};
>>  };
>> -- 
>> 1.8.2.1.342.gfa7285d
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
  2013-09-27 13:20       ` Eduardo Valentin
  (?)
@ 2013-09-27 13:26         ` Nishanth Menon
  -1 siblings, 0 replies; 101+ messages in thread
From: Nishanth Menon @ 2013-09-27 13:26 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: Mark Rutland, dt list, wni, durgadoss.r, Ian Campbell,
	Pawel Moll, Stephen Warren, Tony Lindgren, devicetree-discuss,
	linux-pm, lkml, Rob Herring, lm-sensors, linux-arm-kernel,
	Benoît Cousson, Grant Likely, Russell King, rui.zhang,
	linux-omap, linux

On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
<eduardo.valentin@ti.com> wrote:
> On 27-09-2013 08:24, Nishanth Menon wrote:
>> On 23:13-20130926, Eduardo Valentin wrote:
>>> This patch changes the dtsi entry on omap4430 to contain
>>> the thermal data. This data will enable the passive
>>> cooling with CPUfreq cooling device at 100C and the
>>> system will do a thermal shutdown at 125C.
>>>
>>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: linux-omap@vger.kernel.org
>>> Cc: devicetree-discuss@lists.ozlabs.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>> ---
>>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>>> index bcf455e..e9c97d6 100644
>>> --- a/arch/arm/boot/dts/omap443x.dtsi
>>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>>> @@ -12,7 +12,7 @@
>>>
>>>  / {
>>>      cpus {
>>> -            cpu@0 {
>>> +            cpu0: cpu@0 {
>>>                      /* OMAP443x variants OPP50-OPPNT */
>>>                      operating-points = <
>>>                              /* kHz    uV */
>>> @@ -25,9 +25,15 @@
>>>              };
>>>      };
>>>
>>> -    bandgap {
>>> +    thermal-zones{
>>> +            #include "omap4-cpu-thermal.dtsi"
>>> +    };
>>> +
>>> +    bandgap: bandgap {
>>>              reg = <0x4a002260 0x4
>>>                     0x4a00232C 0x4>;
>>>              compatible = "ti,omap4430-bandgap";
>>> +
>>> +            #thermal-sensor-cells = <0>;
>> 2 cents:
>> we might want to move bandgap under ocp?
>>
>
> Yes, agreed. But I don't think this change is related to this patch or
> to this series.

Correct - this comment is not related to the current patch, hence my 2
cents ;) - will be nice to have it cleaned up though..

Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:26         ` Nishanth Menon
  0 siblings, 0 replies; 101+ messages in thread
From: Nishanth Menon @ 2013-09-27 13:26 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
<eduardo.valentin@ti.com> wrote:
> On 27-09-2013 08:24, Nishanth Menon wrote:
>> On 23:13-20130926, Eduardo Valentin wrote:
>>> This patch changes the dtsi entry on omap4430 to contain
>>> the thermal data. This data will enable the passive
>>> cooling with CPUfreq cooling device at 100C and the
>>> system will do a thermal shutdown at 125C.
>>>
>>> Cc: "Beno?t Cousson" <bcousson@baylibre.com>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: linux-omap at vger.kernel.org
>>> Cc: devicetree-discuss at lists.ozlabs.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-kernel at vger.kernel.org
>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>> ---
>>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>>> index bcf455e..e9c97d6 100644
>>> --- a/arch/arm/boot/dts/omap443x.dtsi
>>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>>> @@ -12,7 +12,7 @@
>>>
>>>  / {
>>>      cpus {
>>> -            cpu at 0 {
>>> +            cpu0: cpu at 0 {
>>>                      /* OMAP443x variants OPP50-OPPNT */
>>>                      operating-points = <
>>>                              /* kHz    uV */
>>> @@ -25,9 +25,15 @@
>>>              };
>>>      };
>>>
>>> -    bandgap {
>>> +    thermal-zones{
>>> +            #include "omap4-cpu-thermal.dtsi"
>>> +    };
>>> +
>>> +    bandgap: bandgap {
>>>              reg = <0x4a002260 0x4
>>>                     0x4a00232C 0x4>;
>>>              compatible = "ti,omap4430-bandgap";
>>> +
>>> +            #thermal-sensor-cells = <0>;
>> 2 cents:
>> we might want to move bandgap under ocp?
>>
>
> Yes, agreed. But I don't think this change is related to this patch or
> to this series.

Correct - this comment is not related to the current patch, hence my 2
cents ;) - will be nice to have it cleaned up though..

Regards,
Nishanth Menon

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:26         ` Nishanth Menon
  0 siblings, 0 replies; 101+ messages in thread
From: Nishanth Menon @ 2013-09-27 13:26 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: Mark Rutland, dt list, wni, durgadoss.r, Ian Campbell,
	Pawel Moll, Stephen Warren, Tony Lindgren, devicetree-discuss,
	linux-pm, lkml, Rob Herring, lm-sensors, linux-arm-kernel,
	Benoît Cousson, Grant Likely, Russell King, rui.zhang,
	linux-omap, linux

On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
<eduardo.valentin@ti.com> wrote:
> On 27-09-2013 08:24, Nishanth Menon wrote:
>> On 23:13-20130926, Eduardo Valentin wrote:
>>> This patch changes the dtsi entry on omap4430 to contain
>>> the thermal data. This data will enable the passive
>>> cooling with CPUfreq cooling device at 100C and the
>>> system will do a thermal shutdown at 125C.
>>>
>>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: linux-omap@vger.kernel.org
>>> Cc: devicetree-discuss@lists.ozlabs.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>> ---
>>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>>> index bcf455e..e9c97d6 100644
>>> --- a/arch/arm/boot/dts/omap443x.dtsi
>>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>>> @@ -12,7 +12,7 @@
>>>
>>>  / {
>>>      cpus {
>>> -            cpu@0 {
>>> +            cpu0: cpu@0 {
>>>                      /* OMAP443x variants OPP50-OPPNT */
>>>                      operating-points = <
>>>                              /* kHz    uV */
>>> @@ -25,9 +25,15 @@
>>>              };
>>>      };
>>>
>>> -    bandgap {
>>> +    thermal-zones{
>>> +            #include "omap4-cpu-thermal.dtsi"
>>> +    };
>>> +
>>> +    bandgap: bandgap {
>>>              reg = <0x4a002260 0x4
>>>                     0x4a00232C 0x4>;
>>>              compatible = "ti,omap4430-bandgap";
>>> +
>>> +            #thermal-sensor-cells = <0>;
>> 2 cents:
>> we might want to move bandgap under ocp?
>>
>
> Yes, agreed. But I don't think this change is related to this patch or
> to this series.

Correct - this comment is not related to the current patch, hence my 2
cents ;) - will be nice to have it cleaned up though..

Regards,
Nishanth Menon

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
  2013-09-27 13:26         ` Nishanth Menon
  (?)
  (?)
@ 2013-09-27 13:42           ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:42 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Eduardo Valentin, Mark Rutland, dt list, wni, durgadoss.r,
	Ian Campbell, Pawel Moll, Stephen Warren, Tony Lindgren,
	devicetree-discuss, linux-pm, lkml, Rob Herring, lm-sensors,
	linux-arm-kernel, Benoît Cousson, Grant Likely,
	Russell King, rui.zhang, linux-omap, linux

[-- Attachment #1: Type: text/plain, Size: 2346 bytes --]

On 27-09-2013 09:26, Nishanth Menon wrote:
> On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
> <eduardo.valentin@ti.com> wrote:
>> On 27-09-2013 08:24, Nishanth Menon wrote:
>>> On 23:13-20130926, Eduardo Valentin wrote:
>>>> This patch changes the dtsi entry on omap4430 to contain
>>>> the thermal data. This data will enable the passive
>>>> cooling with CPUfreq cooling device at 100C and the
>>>> system will do a thermal shutdown at 125C.
>>>>
>>>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: linux-omap@vger.kernel.org
>>>> Cc: devicetree-discuss@lists.ozlabs.org
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>> ---
>>>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>>>> index bcf455e..e9c97d6 100644
>>>> --- a/arch/arm/boot/dts/omap443x.dtsi
>>>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>>>> @@ -12,7 +12,7 @@
>>>>
>>>>  / {
>>>>      cpus {
>>>> -            cpu@0 {
>>>> +            cpu0: cpu@0 {
>>>>                      /* OMAP443x variants OPP50-OPPNT */
>>>>                      operating-points = <
>>>>                              /* kHz    uV */
>>>> @@ -25,9 +25,15 @@
>>>>              };
>>>>      };
>>>>
>>>> -    bandgap {
>>>> +    thermal-zones{
>>>> +            #include "omap4-cpu-thermal.dtsi"
>>>> +    };
>>>> +
>>>> +    bandgap: bandgap {
>>>>              reg = <0x4a002260 0x4
>>>>                     0x4a00232C 0x4>;
>>>>              compatible = "ti,omap4430-bandgap";
>>>> +
>>>> +            #thermal-sensor-cells = <0>;
>>> 2 cents:
>>> we might want to move bandgap under ocp?
>>>
>>
>> Yes, agreed. But I don't think this change is related to this patch or
>> to this series.
> 
> Correct - this comment is not related to the current patch, hence my 2
> cents ;) - will be nice to have it cleaned up though..

Yes, it will be cleaned. ;-) Tks.

> 
> Regards,
> Nishanth Menon
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:42           ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:42 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Mark Rutland, dt list, wni, durgadoss.r, Ian Campbell,
	Pawel Moll, Stephen Warren, Tony Lindgren, devicetree-discuss,
	linux-pm, lkml, Rob Herring, lm-sensors, Eduardo Valentin, linux,
	Benoît Cousson, Grant Likely, Russell King, rui.zhang,
	linux-omap, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 2346 bytes --]

On 27-09-2013 09:26, Nishanth Menon wrote:
> On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
> <eduardo.valentin@ti.com> wrote:
>> On 27-09-2013 08:24, Nishanth Menon wrote:
>>> On 23:13-20130926, Eduardo Valentin wrote:
>>>> This patch changes the dtsi entry on omap4430 to contain
>>>> the thermal data. This data will enable the passive
>>>> cooling with CPUfreq cooling device at 100C and the
>>>> system will do a thermal shutdown at 125C.
>>>>
>>>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: linux-omap@vger.kernel.org
>>>> Cc: devicetree-discuss@lists.ozlabs.org
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>> ---
>>>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>>>> index bcf455e..e9c97d6 100644
>>>> --- a/arch/arm/boot/dts/omap443x.dtsi
>>>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>>>> @@ -12,7 +12,7 @@
>>>>
>>>>  / {
>>>>      cpus {
>>>> -            cpu@0 {
>>>> +            cpu0: cpu@0 {
>>>>                      /* OMAP443x variants OPP50-OPPNT */
>>>>                      operating-points = <
>>>>                              /* kHz    uV */
>>>> @@ -25,9 +25,15 @@
>>>>              };
>>>>      };
>>>>
>>>> -    bandgap {
>>>> +    thermal-zones{
>>>> +            #include "omap4-cpu-thermal.dtsi"
>>>> +    };
>>>> +
>>>> +    bandgap: bandgap {
>>>>              reg = <0x4a002260 0x4
>>>>                     0x4a00232C 0x4>;
>>>>              compatible = "ti,omap4430-bandgap";
>>>> +
>>>> +            #thermal-sensor-cells = <0>;
>>> 2 cents:
>>> we might want to move bandgap under ocp?
>>>
>>
>> Yes, agreed. But I don't think this change is related to this patch or
>> to this series.
> 
> Correct - this comment is not related to the current patch, hence my 2
> cents ;) - will be nice to have it cleaned up though..

Yes, it will be cleaned. ;-) Tks.

> 
> Regards,
> Nishanth Menon
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:42           ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:42 UTC (permalink / raw)
  To: linux-arm-kernel

On 27-09-2013 09:26, Nishanth Menon wrote:
> On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
> <eduardo.valentin@ti.com> wrote:
>> On 27-09-2013 08:24, Nishanth Menon wrote:
>>> On 23:13-20130926, Eduardo Valentin wrote:
>>>> This patch changes the dtsi entry on omap4430 to contain
>>>> the thermal data. This data will enable the passive
>>>> cooling with CPUfreq cooling device at 100C and the
>>>> system will do a thermal shutdown at 125C.
>>>>
>>>> Cc: "Beno?t Cousson" <bcousson@baylibre.com>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: linux-omap at vger.kernel.org
>>>> Cc: devicetree-discuss at lists.ozlabs.org
>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>> Cc: linux-kernel at vger.kernel.org
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>> ---
>>>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>>>> index bcf455e..e9c97d6 100644
>>>> --- a/arch/arm/boot/dts/omap443x.dtsi
>>>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>>>> @@ -12,7 +12,7 @@
>>>>
>>>>  / {
>>>>      cpus {
>>>> -            cpu at 0 {
>>>> +            cpu0: cpu at 0 {
>>>>                      /* OMAP443x variants OPP50-OPPNT */
>>>>                      operating-points = <
>>>>                              /* kHz    uV */
>>>> @@ -25,9 +25,15 @@
>>>>              };
>>>>      };
>>>>
>>>> -    bandgap {
>>>> +    thermal-zones{
>>>> +            #include "omap4-cpu-thermal.dtsi"
>>>> +    };
>>>> +
>>>> +    bandgap: bandgap {
>>>>              reg = <0x4a002260 0x4
>>>>                     0x4a00232C 0x4>;
>>>>              compatible = "ti,omap4430-bandgap";
>>>> +
>>>> +            #thermal-sensor-cells = <0>;
>>> 2 cents:
>>> we might want to move bandgap under ocp?
>>>
>>
>> Yes, agreed. But I don't think this change is related to this patch or
>> to this series.
> 
> Correct - this comment is not related to the current patch, hence my 2
> cents ;) - will be nice to have it cleaned up though..

Yes, it will be cleaned. ;-) Tks.

> 
> Regards,
> Nishanth Menon
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130927/cc2729b9/attachment.sig>

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv4 11/18] arm: dts: add omap4430 thermal data
@ 2013-09-27 13:42           ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-27 13:42 UTC (permalink / raw)
  To: Nishanth Menon
  Cc: Eduardo Valentin, Mark Rutland, dt list, wni, durgadoss.r,
	Ian Campbell, Pawel Moll, Stephen Warren, Tony Lindgren,
	devicetree-discuss, linux-pm, lkml, Rob Herring, lm-sensors,
	linux-arm-kernel, Benoît Cousson, Grant Likely,
	Russell King, rui.zhang, linux-omap, linux


[-- Attachment #1.1: Type: text/plain, Size: 2346 bytes --]

On 27-09-2013 09:26, Nishanth Menon wrote:
> On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
> <eduardo.valentin@ti.com> wrote:
>> On 27-09-2013 08:24, Nishanth Menon wrote:
>>> On 23:13-20130926, Eduardo Valentin wrote:
>>>> This patch changes the dtsi entry on omap4430 to contain
>>>> the thermal data. This data will enable the passive
>>>> cooling with CPUfreq cooling device at 100C and the
>>>> system will do a thermal shutdown at 125C.
>>>>
>>>> Cc: "Benoît Cousson" <bcousson@baylibre.com>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: linux-omap@vger.kernel.org
>>>> Cc: devicetree-discuss@lists.ozlabs.org
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>> ---
>>>>  arch/arm/boot/dts/omap443x.dtsi | 10 ++++++++--
>>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
>>>> index bcf455e..e9c97d6 100644
>>>> --- a/arch/arm/boot/dts/omap443x.dtsi
>>>> +++ b/arch/arm/boot/dts/omap443x.dtsi
>>>> @@ -12,7 +12,7 @@
>>>>
>>>>  / {
>>>>      cpus {
>>>> -            cpu@0 {
>>>> +            cpu0: cpu@0 {
>>>>                      /* OMAP443x variants OPP50-OPPNT */
>>>>                      operating-points = <
>>>>                              /* kHz    uV */
>>>> @@ -25,9 +25,15 @@
>>>>              };
>>>>      };
>>>>
>>>> -    bandgap {
>>>> +    thermal-zones{
>>>> +            #include "omap4-cpu-thermal.dtsi"
>>>> +    };
>>>> +
>>>> +    bandgap: bandgap {
>>>>              reg = <0x4a002260 0x4
>>>>                     0x4a00232C 0x4>;
>>>>              compatible = "ti,omap4430-bandgap";
>>>> +
>>>> +            #thermal-sensor-cells = <0>;
>>> 2 cents:
>>> we might want to move bandgap under ocp?
>>>
>>
>> Yes, agreed. But I don't think this change is related to this patch or
>> to this series.
> 
> Correct - this comment is not related to the current patch, hence my 2
> cents ;) - will be nice to have it cleaned up though..

Yes, it will be cleaned. ;-) Tks.

> 
> Regards,
> Nishanth Menon
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv7 03/18] thermal: introduce device tree parser
  2013-09-27  3:13   ` Eduardo Valentin
@ 2013-09-30 15:36     ` Mark Rutland
  -1 siblings, 0 replies; 101+ messages in thread
From: Mark Rutland @ 2013-09-30 15:36 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: swarren, Pawel Moll, ian.campbell, rob.herring, linux, rui.zhang,
	wni, grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel

Hi Eduardo,

On Fri, Sep 27, 2013 at 04:13:10AM +0100, Eduardo Valentin wrote:
> This patch introduces a device tree bindings for
> describing the hardware thermal behavior and limits.
> Also a parser to read and interpret the data and feed
> it in the thermal framework is presented.
>
> This patch introduces a thermal data parser for device
> tree. The parsed data is used to build thermal zones
> and thermal binding parameters. The output data
> can then be used to deploy thermal policies.
>
> This patch adds also documentation regarding this
> API and how to define tree nodes to use
> this infrastructure.
>
> Note that, in order to be able to have control
> on the sensor registration on the DT thermal zone,
> it was required to allow changing the thermal zone
> .get_temp callback. For this reason, this patch
> also removes the 'const' modifier from the .ops
> field of thermal zone devices.
>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>
> Hello folks,
>
> For those interested on this work, here is a short changelog from v6:
> - Reviewed binding documentation and added type and size on all properties
> - Described 'thermal-zones' node in binding documentation
> - Using now cooling state terminology instead of cooling level
> - Renamed milliCelsius to millicelsius
> - Renamed cooling-attachments to 'cooling-maps'
> - Renamed sensor to thermal sensor
> - Renamed #sensor-cells to #thermal-sensor-cells
> - #thermal-sensor-cells now is allowed to be 0
> - Renamed 'sensors' property to 'thermal-sensors'
> - Changed trip type property to be now string and documented possible values
> - Described better the cooling properties
> - Now parses 'contribution' instead of 'usage'
> - Renamed cdev to cooling device
> - Renamed 'passive-delay' property to 'polling-delay-passive'
> - Fixed a couple of error messages to match the property name
> - Fixed a binding issue while using cpufreq as module
> - Reworked thermal_of_build_thermal_zone function so that it frees
> requested memory if something goes wrong and checks for sub-nodes
> with zero children.
>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>  drivers/thermal/thermal_core.c                     |   9 +-
>  drivers/thermal/thermal_core.h                     |   9 +
>  include/dt-bindings/thermal/thermal.h              |  27 +
>  include/linux/thermal.h                            |  28 +-
>  8 files changed, 1466 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 drivers/thermal/of-thermal.c
>  create mode 100644 include/dt-bindings/thermal/thermal.h
>
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..3dbc017
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,537 @@
> +* Thermal Framework Device Tree descriptor
> +
> +Generic binding to provide a way of defining hardware thermal
> +structure using device tree. A thermal structure includes thermal
> +zones and their components, such as trip points, polling intervals,
> +sensors and cooling devices binding descriptors.
> +
> +The target of device tree thermal descriptors is to describe only
> +the hardware thermal aspects, not how the system must control or which
> +algorithm or policy must be taken in place.
> +
> +There are five types of nodes involved to describe thermal bindings:
> +- sensors: used to describe the device source of temperature sensing;
> +- cooling devices: used to describe devices source of power dissipation control;
> +- trip points: used to describe points in temperature domain defined to
> +make the system aware of hardware limits;
> +- cooling maps: used to describe links between trip points and
> +cooling devices;
> +- thermal zones: used to describe thermal data within the hardware;
> +
> +It follows a description of each type of these device tree nodes.
> +
> +Note: This binding is a working in progress.

What does this mean? Is the binding expected to change in incompatible
ways?

I see we have similar wording at the top of the clock bindings, which
should probably go -- it's ABI now...

> +
> +* Thermal sensor devices
> +
> +Thermal sensor devices are nodes providing temperature sensing capabilities on
> +thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
> +nodes providing temperature data to thermal zones. Thermal sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #thermal-sensor-cells: Used to provide sensor device specific information
> +  Type: unsigned        while referring to it. Typically 0, on thermal sensor
> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
> +                        with several internal sensors, in order
> +                        to identify uniquely the sensor instances within
> +                        the IC. See thermal zone binding for more details
> +                        on how consumers refer to sensor devices.
> +
> +* Cooling device nodes
> +
> +Cooling devices are nodes providing control on power dissipation. There
> +are essentially two ways to provide control on power dissipation. First
> +is by means of regulating device performance, which is known as passive
> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
> +frequency scaling, and uses lower frequencies as cooling states.
> +Second is by means of activating devices in order to remove
> +the dissipated heat, which is known as active cooling, e.g. regulating
> +fan speeds. In both cases, cooling devices shall have a way to determine
> +the state of cooling in which the device is.
> +
> +Required property:
> +- cooling-min-state:   An integer indicating the smallest
> +  Type: unsigned       cooling state accepted. Typically 0.
> +  Size: one cell
> +
> +- cooling-max-state:   An integer indicating the largest
> +  Type: unsigned       cooling state accepted.
> +  Size: one cell
> +
> +- #cooling-cells:      Used to provide cooling device specific information
> +  Type: unsigned       while referring to it. Must be at least 2, in order
> +  Size: one cell       to specify minimum and maximum cooling state used
> +                       in the reference. The first cell is the minimum
> +                       cooling state requested and the second cell is
> +                       the maximum cooling state requested in the reference.
> +                       See Cooling device maps section below for more details
> +                       on how consumers refer to cooling devices.
> +
> +* Trip points
> +
> +The trip node is a node to describe a point in the temperature domain
> +in which the system takes an action. This node describes just the point,
> +not the action.
> +
> +Required properties:
> +- temperature:         An integer indicating the trip temperature level,
> +  Type: signed         in millicelsius.
> +  Size: one cell
> +
> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
> +  Type: unsigned       relative value, in millicelsius.
> +  Size: one cell
> +
> +- type:                        a string containing the trip type. Supported values are:

Odd spacing above.

> +       "active":       A trip point to enable active cooling
> +       "passive":      A trip point to enable passive cooling
> +       "hot":          A trip point to notify emergency
> +       "critical":     Hardware not reliable.
> +  Type: string
> +
> +There are also string constants defined at
> +include/dt-bindings/thermal/thermal.h.
> +
> +* Cooling device maps
> +
> +The cooling device maps node is a node to describe how cooling devices
> +get assigned to trip points of the zone. The cooling devices are expected
> +to be loaded in the target system.
> +
> +Required properties:
> +- cooling-device:      A phandle of a cooling device with its specifier,
> +  Type: phandle                referring to which cooling device is used in this

More odd spacing. There's a fair amount later that would be nice to fix
up too.

> +                       binding. The required specifiers are: the minimum
> +                       cooling state and the maximum cooling level used
> +                       in this map.

There seems to be some confusion as to the word "specifier". Typically,
a specifier is all the cells after the phandle described by the #*-cells
property for the node pointed to. So here there is one
cooling-specifier, which describes the min and max values, and possibly
some other values.

> +- trip:                        A phandle of a trip point node within the same thermal
> +  Type: phandle                zone.
> +
> +Optional property:
> +- contribution:                The cooling contribution to the thermal zone of the
> +  Type: unsigned       referred cooling device at the referred trip point.
> +  Size: one cell       The contribution is a ratio of the sum
> +                       of all cooling contributions within a thermal zone.
> +
> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
> +limit specifier means:
> +(i)   - minimum state allowed for minimum cooling level used in the reference.
> +(ii)  - maximum state allowed for maximum cooling level used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.

How does that work with an unsigned value? Does the code check for
0xffffffff, or compare against -1?

> +
> +* Thermal zone nodes
> +
> +The thermal zone node is the node containing all the required info
> +for describing a thermal zone, including its cooling device bindings. The
> +thermal zone node must contain, apart from its own properties, one node containing
> +trip nodes and one node containing all the zone cooling maps.
> +
> +Required properties:
> +- polling-delay-passive:       The maximum number of milliseconds to wait
> +  Type: unsigned               between polls when performing passive cooling.
> +  Size: one cell

Is this when performing passive cooling, or any passive or above (i.e.
any cooling whatsoever)?

> +
> +- polling-delay:       The maximum number of milliseconds to wait between polls
> +  Type: unsigned       when checking this thermal zone.
> +  Size: one cell
> +
> +- thermal-sensors:             A list of sensor phandles and sensor specifier
> +  Type: list of phandles       used while monitoring the thermal zone.

The type and the description don't agree here. The type description can
probably be omitted as the description describes the format of the
property.

> +
> +- trips:               A sub-node which is a container of only trip point nodes
> +  Type: sub-node       required to describe the thermal zone.
> +
> +- cooling-maps:                A sub-node which is a container of only cooling device
> +  Type: sub-node       map nodes, used to describe the relation between trips
> +                       and cooling devices.
> +
> +Optional property:
> +- thermal-sensors-names:       List of thermal sensor name strings sorted
> +  Type: list of strings                in the same order as the thermal-sensors
> +                               property.

Was there a reason for adding this?

There was some confusion over my request for cooling-specifier and
thermal-sensor-specifier terminology last time [1]. I was simply asking
for terminology, not -names properties.

> +
> +- coefficients:                An array of integers (one signed cell) containing
> +  Type: array          coefficients to compose a linear relation between
> +  Elem size: one cell  the sensors described in the thermal-sensors property.
> +  Elem type: signed    Coefficients defaults to 1, in case this property
> +                       is not specified. A simple linear polynomial is used:
> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
> +
> +                       The coefficients are ordered and they match with sensors
> +                       by means of sensor ID. Additional coefficients are
> +                       interpreted as constant offsets.
> +
> +Note: The delay properties are bound to the maximum dT/dt (temperature
> +derivative over time) in two situations for a thermal zone:
> +(i)  - when active cooling is activated (polling-delay-passive); and

Ah, so any coolnig implies the passive polling delay. That makes teh
naming confusing (active cooling means we're polling for the passive
delay). Sorry for the poor suggestion.

How about having polling-delay-cooled instead. That better describes
when it applies.

> +(ii) - when the zone just needs to be monitored (polling-delay).
> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
> +capability.

It would be nice to have another line break here.

> +The delays are chosen to account for said max dT/dt, such that a device

s/are/should be/

> +does not cross several trip boundaries unexpectedly between polls. Choosing
> +the right polling delays shall avoid having the device in temperature ranges
> +that may damage the silicon structures and reduce silicon lifetime.
> +
> +* The thermal-zones node
> +
> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
> +contain only sub-nodes describing thermal zones as in the section
> +"Thermal zone nodes".

I assume thermal-zones appears under /, rather than under a subnode? It
might be worth mentioning.

> +
> +* Examples
> +
> +Below are several examples on how to use thermal data descriptors
> +using device tree bindings:
> +
> +(a) - CPU thermal zone
> +
> +The CPU thermal zone example below describes how to setup one thermal zone
> +using one single sensor as temperature source and many cooling devices and
> +power dissipation control sources.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +cpus {
> +       cpu0: cpu@0 {
> +               ...
> +               cooling-min-state = <0>;
> +               cooling-max-state = <3>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +       ...
> +};

If we're going to give an example of cpu nodes with cooling-cells, we
should have a binding for cpu nodes explaining what the abstract cooling
properties mean for them.

What _specifically_ do each of the values 0,1,2,3 mean here? Are they
indexes of OPPs to use (which aren't shown in the example)? Are they
specific to a particular CPU (the compatible string for which is not
shown in the example)? Are they generic and applicable to all CPUs
somehow?

> +
> +&i2c1 {
> +       ...

Having a comment inline describing this fictional sensor would be
useful, something like:

	/*
	 * A simple fan controlller. Supports 10 speeds of operation
	 * (represented as 0-9).
	 */

I didn't notice the block below until already having tried to comprehend
the example. Inline comments would help in that regard.

> +       fan0: fan@0x48 {
> +               ...
> +               cooling-min-state = <0>;
> +               cooling-max-state = <9>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +};
> +

Similarly, it would be nice to have something here like:

	/*
	 * A simple IC with a single bandgap temperature sensor.
	 */

> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #thermal-sensor-cells = <0>;
> +};
> +
> +cpu-thermal: cpu-thermal {

This should be under a thermal-zones node. Similarly for the other
examples, they should have all relevant context.

> +       polling-delay-passive = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +

The comment below is no longer relevant.

> +                       /* sensor       ID */
> +        thermal-sensors = <&bandgap0>;
> +
> +        trips {
> +                cpu-alert0: cpu-alert {
> +                        temperature = <90000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_ACTIVE;

This got changed to a string in the binding, but is a CPP value here.
Similarly in many other places below.

> +                };
> +                cpu-alert1: cpu-alert {
> +                        temperature = <100000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                cpu-crit: cpu-crit {
> +                        temperature = <125000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               map0 {
> +                       trip = <&cpu-alert0>;
> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +               };
> +               map1 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +               };
> +               map2 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device =
> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
> +               };
> +       };
> +};
> +
> +In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
> +the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
> +via I2C bus 1, at adress 0x48, which has ten different cooling states.

This is a little difficult to understand. How about:

In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
different cooling states 0-9.

> +It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
> +cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
> +at 90C, as an example of active cooling. The same cooling device is used at
> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
> +using all its cooling states at trip point 'cpu-alert1',
> +which is a trip point at 100C.
> +
> +(b) - IC with several internal sensors
> +
> +The example below describes how to deploy several thermal zones based off a
> +single sensor IC, assuming it has several internal sensors. This is a common
> +case on SoC designs with several internal IPs that may need different thermal
> +requirements, and thus may have their own sensor to monitor or detect internal
> +hotspots in their silicon.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #thermal-sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +       polling-delay-passive = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        thermal-sensors = <&bandgap0     0>;
> +
> +        trips {
> +               /* each zone within the SoC may have its own trips */
> +                cpu-alert: cpu-alert {
> +                        temperature = <100000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                cpu-crit: cpu-crit {
> +                        temperature = <125000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               /* each zone within the SoC may have its own cooling */
> +               ...
> +       };
> +};
> +
> +gpu-thermal: gpu-thermal {
> +       polling-delay-passive = <120>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +                       /* sensor       ID */
> +        thermal-sensors = <&bandgap0     1>;
> +
> +        trips {
> +               /* each zone within the SoC may have its own trips */
> +                gpu-alert: gpu-alert {
> +                        temperature = <90000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                gpu-crit: gpu-crit {
> +                        temperature = <105000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               /* each zone within the SoC may have its own cooling */
> +               ...
> +       };
> +};
> +
> +dsp-thermal: dsp-thermal {
> +       polling-delay-passive = <50>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        thermal-sensors = <&bandgap0     2>;
> +
> +        trips {
> +               /* each zone within the SoC may have its own trips */
> +                dsp-alert: gpu-alert {
> +                        temperature = <90000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                dsp-crit: gpu-crit {
> +                        temperature = <135000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               /* each zone within the SoC may have its own cooling */
> +               ...
> +       };
> +};
> +
> +In the example above there is one bandgap IC which has the capability to
> +monitor three sensors. The hardware has been designed so that sensors are
> +placed on different places in the DIE to monitor different temperature
> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
> +other to monitor a DSP thermal zone.
> +
> +Thus, there is a need to assign each sensor provided by the bandgap IC
> +to different thermal zones. This is achieved by means of using the
> +#thermal-sensor-cells property and using the first specifier as sensor ID.
> +In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,

The reference to bandgap.sensor0 is confusing. How about saying
<&bandgap 0> instead? It makes it far easier to see correspondence
between the text and the dt. Similarly for the other instances below.

> +bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
> +is used to monitor DSP thermal zone. Each zone may be uncorrelated,
> +having its own dT/dt requirements, trips and cooling maps.
> +
> +
> +(c) - Several sensors within one single thermal zone
> +
> +The example below illustrates how to use more than one sensor within
> +one thermal zone.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&i2c1 {
> +       ...
> +       adc: sensor@0x49 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #thermal-sensor-cells = <0>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +       polling-delay-passive = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +                       /* sensor       ID */
> +        thermal-sensors = <&bandgap0>,
> +                         <&adc>;
> +       thermal-sensors-names = "cpu", "pcb north";
> +
> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
> +       coefficients =          <100    -120    484>;
> +
> +        trips {
> +               ...
> +        };
> +
> +       cooling-maps {
> +               ...
> +       };
> +};
> +
> +In some cases, there is a need to use more than one sensor to extrapolate
> +a thermal hotspot in the silicon. The above example illustrate this situation.

s/illustrate/illustrates/

> +For instance, it may be the case that a sensor external to CPU IP may be place

s/place/placed/

> +close to CPU hotspot and together with internal CPU sensor, it is used
> +to determine the hotspot. The hyppotetical extrapolation rule would be:

s/hyppotetical/hypothetical/

[...]

> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       /* thermal fw should take care of data->mask & (1 << trip) */

I mentioned this last time, and it's tripped me up again while reading:
It's rather too easy to read "fw" as "firmware" and get confused.

s/fw/framework/ please. :)

> +       data->trips[trip].temperature = temp;
> +
> +       return 0;
> +}

[...]

> +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 *))
> +{
> +       struct device_node *np, *child, *sensor_np;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np)
> +               return ERR_PTR(-ENODEV);
> +
> +       if (!dev || !dev->of_node)
> +               return ERR_PTR(-EINVAL);
> +
> +       sensor_np = dev->of_node;
> +
> +       for_each_child_of_node(np, child) {
> +               struct of_phandle_args sensor_specs;
> +               int ret, id;
> +
> +               /* For now, thermal framework supports only 1 sensor per zone */
> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
> +                                                "#thermal-sensor-cells",
> +                                                0, &sensor_specs);
> +               if (ret)
> +                       continue;
> +
> +               if (sensor_specs.args_count < 1)
> +                       id = 0;
> +               else
> +                       id = sensor_specs.args[0];
> +

For the moment it might be worth printing a warning if args_count > 1,
as thermal management might not function correctly.

> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
> +                       of_node_put(np);
> +                       return thermal_zone_of_add_sensor(child, sensor_np,
> +                                                         data,
> +                                                         get_temp,
> +                                                         get_trend);
> +               }
> +       }
> +       of_node_put(np);
> +
> +       return ERR_PTR(-ENODEV);
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);

Cheers,
Mark.

[1] https://lkml.org/lkml/2013/9/24/501

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv7 03/18] thermal: introduce device tree parser
@ 2013-09-30 15:36     ` Mark Rutland
  0 siblings, 0 replies; 101+ messages in thread
From: Mark Rutland @ 2013-09-30 15:36 UTC (permalink / raw)
  To: Eduardo Valentin
  Cc: swarren, Pawel Moll, ian.campbell, rob.herring, linux, rui.zhang,
	wni, grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel

Hi Eduardo,

On Fri, Sep 27, 2013 at 04:13:10AM +0100, Eduardo Valentin wrote:
> This patch introduces a device tree bindings for
> describing the hardware thermal behavior and limits.
> Also a parser to read and interpret the data and feed
> it in the thermal framework is presented.
>
> This patch introduces a thermal data parser for device
> tree. The parsed data is used to build thermal zones
> and thermal binding parameters. The output data
> can then be used to deploy thermal policies.
>
> This patch adds also documentation regarding this
> API and how to define tree nodes to use
> this infrastructure.
>
> Note that, in order to be able to have control
> on the sensor registration on the DT thermal zone,
> it was required to allow changing the thermal zone
> .get_temp callback. For this reason, this patch
> also removes the 'const' modifier from the .ops
> field of thermal zone devices.
>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>
> Hello folks,
>
> For those interested on this work, here is a short changelog from v6:
> - Reviewed binding documentation and added type and size on all properties
> - Described 'thermal-zones' node in binding documentation
> - Using now cooling state terminology instead of cooling level
> - Renamed milliCelsius to millicelsius
> - Renamed cooling-attachments to 'cooling-maps'
> - Renamed sensor to thermal sensor
> - Renamed #sensor-cells to #thermal-sensor-cells
> - #thermal-sensor-cells now is allowed to be 0
> - Renamed 'sensors' property to 'thermal-sensors'
> - Changed trip type property to be now string and documented possible values
> - Described better the cooling properties
> - Now parses 'contribution' instead of 'usage'
> - Renamed cdev to cooling device
> - Renamed 'passive-delay' property to 'polling-delay-passive'
> - Fixed a couple of error messages to match the property name
> - Fixed a binding issue while using cpufreq as module
> - Reworked thermal_of_build_thermal_zone function so that it frees
> requested memory if something goes wrong and checks for sub-nodes
> with zero children.
>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>  drivers/thermal/thermal_core.c                     |   9 +-
>  drivers/thermal/thermal_core.h                     |   9 +
>  include/dt-bindings/thermal/thermal.h              |  27 +
>  include/linux/thermal.h                            |  28 +-
>  8 files changed, 1466 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 drivers/thermal/of-thermal.c
>  create mode 100644 include/dt-bindings/thermal/thermal.h
>
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..3dbc017
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,537 @@
> +* Thermal Framework Device Tree descriptor
> +
> +Generic binding to provide a way of defining hardware thermal
> +structure using device tree. A thermal structure includes thermal
> +zones and their components, such as trip points, polling intervals,
> +sensors and cooling devices binding descriptors.
> +
> +The target of device tree thermal descriptors is to describe only
> +the hardware thermal aspects, not how the system must control or which
> +algorithm or policy must be taken in place.
> +
> +There are five types of nodes involved to describe thermal bindings:
> +- sensors: used to describe the device source of temperature sensing;
> +- cooling devices: used to describe devices source of power dissipation control;
> +- trip points: used to describe points in temperature domain defined to
> +make the system aware of hardware limits;
> +- cooling maps: used to describe links between trip points and
> +cooling devices;
> +- thermal zones: used to describe thermal data within the hardware;
> +
> +It follows a description of each type of these device tree nodes.
> +
> +Note: This binding is a working in progress.

What does this mean? Is the binding expected to change in incompatible
ways?

I see we have similar wording at the top of the clock bindings, which
should probably go -- it's ABI now...

> +
> +* Thermal sensor devices
> +
> +Thermal sensor devices are nodes providing temperature sensing capabilities on
> +thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
> +nodes providing temperature data to thermal zones. Thermal sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #thermal-sensor-cells: Used to provide sensor device specific information
> +  Type: unsigned        while referring to it. Typically 0, on thermal sensor
> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
> +                        with several internal sensors, in order
> +                        to identify uniquely the sensor instances within
> +                        the IC. See thermal zone binding for more details
> +                        on how consumers refer to sensor devices.
> +
> +* Cooling device nodes
> +
> +Cooling devices are nodes providing control on power dissipation. There
> +are essentially two ways to provide control on power dissipation. First
> +is by means of regulating device performance, which is known as passive
> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
> +frequency scaling, and uses lower frequencies as cooling states.
> +Second is by means of activating devices in order to remove
> +the dissipated heat, which is known as active cooling, e.g. regulating
> +fan speeds. In both cases, cooling devices shall have a way to determine
> +the state of cooling in which the device is.
> +
> +Required property:
> +- cooling-min-state:   An integer indicating the smallest
> +  Type: unsigned       cooling state accepted. Typically 0.
> +  Size: one cell
> +
> +- cooling-max-state:   An integer indicating the largest
> +  Type: unsigned       cooling state accepted.
> +  Size: one cell
> +
> +- #cooling-cells:      Used to provide cooling device specific information
> +  Type: unsigned       while referring to it. Must be at least 2, in order
> +  Size: one cell       to specify minimum and maximum cooling state used
> +                       in the reference. The first cell is the minimum
> +                       cooling state requested and the second cell is
> +                       the maximum cooling state requested in the reference.
> +                       See Cooling device maps section below for more details
> +                       on how consumers refer to cooling devices.
> +
> +* Trip points
> +
> +The trip node is a node to describe a point in the temperature domain
> +in which the system takes an action. This node describes just the point,
> +not the action.
> +
> +Required properties:
> +- temperature:         An integer indicating the trip temperature level,
> +  Type: signed         in millicelsius.
> +  Size: one cell
> +
> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
> +  Type: unsigned       relative value, in millicelsius.
> +  Size: one cell
> +
> +- type:                        a string containing the trip type. Supported values are:

Odd spacing above.

> +       "active":       A trip point to enable active cooling
> +       "passive":      A trip point to enable passive cooling
> +       "hot":          A trip point to notify emergency
> +       "critical":     Hardware not reliable.
> +  Type: string
> +
> +There are also string constants defined at
> +include/dt-bindings/thermal/thermal.h.
> +
> +* Cooling device maps
> +
> +The cooling device maps node is a node to describe how cooling devices
> +get assigned to trip points of the zone. The cooling devices are expected
> +to be loaded in the target system.
> +
> +Required properties:
> +- cooling-device:      A phandle of a cooling device with its specifier,
> +  Type: phandle                referring to which cooling device is used in this

More odd spacing. There's a fair amount later that would be nice to fix
up too.

> +                       binding. The required specifiers are: the minimum
> +                       cooling state and the maximum cooling level used
> +                       in this map.

There seems to be some confusion as to the word "specifier". Typically,
a specifier is all the cells after the phandle described by the #*-cells
property for the node pointed to. So here there is one
cooling-specifier, which describes the min and max values, and possibly
some other values.

> +- trip:                        A phandle of a trip point node within the same thermal
> +  Type: phandle                zone.
> +
> +Optional property:
> +- contribution:                The cooling contribution to the thermal zone of the
> +  Type: unsigned       referred cooling device at the referred trip point.
> +  Size: one cell       The contribution is a ratio of the sum
> +                       of all cooling contributions within a thermal zone.
> +
> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
> +limit specifier means:
> +(i)   - minimum state allowed for minimum cooling level used in the reference.
> +(ii)  - maximum state allowed for maximum cooling level used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.

How does that work with an unsigned value? Does the code check for
0xffffffff, or compare against -1?

> +
> +* Thermal zone nodes
> +
> +The thermal zone node is the node containing all the required info
> +for describing a thermal zone, including its cooling device bindings. The
> +thermal zone node must contain, apart from its own properties, one node containing
> +trip nodes and one node containing all the zone cooling maps.
> +
> +Required properties:
> +- polling-delay-passive:       The maximum number of milliseconds to wait
> +  Type: unsigned               between polls when performing passive cooling.
> +  Size: one cell

Is this when performing passive cooling, or any passive or above (i.e.
any cooling whatsoever)?

> +
> +- polling-delay:       The maximum number of milliseconds to wait between polls
> +  Type: unsigned       when checking this thermal zone.
> +  Size: one cell
> +
> +- thermal-sensors:             A list of sensor phandles and sensor specifier
> +  Type: list of phandles       used while monitoring the thermal zone.

The type and the description don't agree here. The type description can
probably be omitted as the description describes the format of the
property.

> +
> +- trips:               A sub-node which is a container of only trip point nodes
> +  Type: sub-node       required to describe the thermal zone.
> +
> +- cooling-maps:                A sub-node which is a container of only cooling device
> +  Type: sub-node       map nodes, used to describe the relation between trips
> +                       and cooling devices.
> +
> +Optional property:
> +- thermal-sensors-names:       List of thermal sensor name strings sorted
> +  Type: list of strings                in the same order as the thermal-sensors
> +                               property.

Was there a reason for adding this?

There was some confusion over my request for cooling-specifier and
thermal-sensor-specifier terminology last time [1]. I was simply asking
for terminology, not -names properties.

> +
> +- coefficients:                An array of integers (one signed cell) containing
> +  Type: array          coefficients to compose a linear relation between
> +  Elem size: one cell  the sensors described in the thermal-sensors property.
> +  Elem type: signed    Coefficients defaults to 1, in case this property
> +                       is not specified. A simple linear polynomial is used:
> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
> +
> +                       The coefficients are ordered and they match with sensors
> +                       by means of sensor ID. Additional coefficients are
> +                       interpreted as constant offsets.
> +
> +Note: The delay properties are bound to the maximum dT/dt (temperature
> +derivative over time) in two situations for a thermal zone:
> +(i)  - when active cooling is activated (polling-delay-passive); and

Ah, so any coolnig implies the passive polling delay. That makes teh
naming confusing (active cooling means we're polling for the passive
delay). Sorry for the poor suggestion.

How about having polling-delay-cooled instead. That better describes
when it applies.

> +(ii) - when the zone just needs to be monitored (polling-delay).
> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
> +capability.

It would be nice to have another line break here.

> +The delays are chosen to account for said max dT/dt, such that a device

s/are/should be/

> +does not cross several trip boundaries unexpectedly between polls. Choosing
> +the right polling delays shall avoid having the device in temperature ranges
> +that may damage the silicon structures and reduce silicon lifetime.
> +
> +* The thermal-zones node
> +
> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
> +contain only sub-nodes describing thermal zones as in the section
> +"Thermal zone nodes".

I assume thermal-zones appears under /, rather than under a subnode? It
might be worth mentioning.

> +
> +* Examples
> +
> +Below are several examples on how to use thermal data descriptors
> +using device tree bindings:
> +
> +(a) - CPU thermal zone
> +
> +The CPU thermal zone example below describes how to setup one thermal zone
> +using one single sensor as temperature source and many cooling devices and
> +power dissipation control sources.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +cpus {
> +       cpu0: cpu@0 {
> +               ...
> +               cooling-min-state = <0>;
> +               cooling-max-state = <3>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +       ...
> +};

If we're going to give an example of cpu nodes with cooling-cells, we
should have a binding for cpu nodes explaining what the abstract cooling
properties mean for them.

What _specifically_ do each of the values 0,1,2,3 mean here? Are they
indexes of OPPs to use (which aren't shown in the example)? Are they
specific to a particular CPU (the compatible string for which is not
shown in the example)? Are they generic and applicable to all CPUs
somehow?

> +
> +&i2c1 {
> +       ...

Having a comment inline describing this fictional sensor would be
useful, something like:

	/*
	 * A simple fan controlller. Supports 10 speeds of operation
	 * (represented as 0-9).
	 */

I didn't notice the block below until already having tried to comprehend
the example. Inline comments would help in that regard.

> +       fan0: fan@0x48 {
> +               ...
> +               cooling-min-state = <0>;
> +               cooling-max-state = <9>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +};
> +

Similarly, it would be nice to have something here like:

	/*
	 * A simple IC with a single bandgap temperature sensor.
	 */

> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #thermal-sensor-cells = <0>;
> +};
> +
> +cpu-thermal: cpu-thermal {

This should be under a thermal-zones node. Similarly for the other
examples, they should have all relevant context.

> +       polling-delay-passive = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +

The comment below is no longer relevant.

> +                       /* sensor       ID */
> +        thermal-sensors = <&bandgap0>;
> +
> +        trips {
> +                cpu-alert0: cpu-alert {
> +                        temperature = <90000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_ACTIVE;

This got changed to a string in the binding, but is a CPP value here.
Similarly in many other places below.

> +                };
> +                cpu-alert1: cpu-alert {
> +                        temperature = <100000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                cpu-crit: cpu-crit {
> +                        temperature = <125000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               map0 {
> +                       trip = <&cpu-alert0>;
> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +               };
> +               map1 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +               };
> +               map2 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device > +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
> +               };
> +       };
> +};
> +
> +In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
> +the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
> +via I2C bus 1, at adress 0x48, which has ten different cooling states.

This is a little difficult to understand. How about:

In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
different cooling states 0-9.

> +It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
> +cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
> +at 90C, as an example of active cooling. The same cooling device is used at
> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
> +using all its cooling states at trip point 'cpu-alert1',
> +which is a trip point at 100C.
> +
> +(b) - IC with several internal sensors
> +
> +The example below describes how to deploy several thermal zones based off a
> +single sensor IC, assuming it has several internal sensors. This is a common
> +case on SoC designs with several internal IPs that may need different thermal
> +requirements, and thus may have their own sensor to monitor or detect internal
> +hotspots in their silicon.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #thermal-sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +       polling-delay-passive = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        thermal-sensors = <&bandgap0     0>;
> +
> +        trips {
> +               /* each zone within the SoC may have its own trips */
> +                cpu-alert: cpu-alert {
> +                        temperature = <100000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                cpu-crit: cpu-crit {
> +                        temperature = <125000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               /* each zone within the SoC may have its own cooling */
> +               ...
> +       };
> +};
> +
> +gpu-thermal: gpu-thermal {
> +       polling-delay-passive = <120>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +                       /* sensor       ID */
> +        thermal-sensors = <&bandgap0     1>;
> +
> +        trips {
> +               /* each zone within the SoC may have its own trips */
> +                gpu-alert: gpu-alert {
> +                        temperature = <90000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                gpu-crit: gpu-crit {
> +                        temperature = <105000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               /* each zone within the SoC may have its own cooling */
> +               ...
> +       };
> +};
> +
> +dsp-thermal: dsp-thermal {
> +       polling-delay-passive = <50>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        thermal-sensors = <&bandgap0     2>;
> +
> +        trips {
> +               /* each zone within the SoC may have its own trips */
> +                dsp-alert: gpu-alert {
> +                        temperature = <90000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_PASSIVE;
> +                };
> +                dsp-crit: gpu-crit {
> +                        temperature = <135000>; /* millicelsius */
> +                        hysteresis = <2000>; /* millicelsius */
> +                        type = THERMAL_TRIP_CRITICAL;
> +                };
> +        };
> +
> +       cooling-maps {
> +               /* each zone within the SoC may have its own cooling */
> +               ...
> +       };
> +};
> +
> +In the example above there is one bandgap IC which has the capability to
> +monitor three sensors. The hardware has been designed so that sensors are
> +placed on different places in the DIE to monitor different temperature
> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
> +other to monitor a DSP thermal zone.
> +
> +Thus, there is a need to assign each sensor provided by the bandgap IC
> +to different thermal zones. This is achieved by means of using the
> +#thermal-sensor-cells property and using the first specifier as sensor ID.
> +In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,

The reference to bandgap.sensor0 is confusing. How about saying
<&bandgap 0> instead? It makes it far easier to see correspondence
between the text and the dt. Similarly for the other instances below.

> +bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
> +is used to monitor DSP thermal zone. Each zone may be uncorrelated,
> +having its own dT/dt requirements, trips and cooling maps.
> +
> +
> +(c) - Several sensors within one single thermal zone
> +
> +The example below illustrates how to use more than one sensor within
> +one thermal zone.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&i2c1 {
> +       ...
> +       adc: sensor@0x49 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #thermal-sensor-cells = <0>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +       polling-delay-passive = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +                       /* sensor       ID */
> +        thermal-sensors = <&bandgap0>,
> +                         <&adc>;
> +       thermal-sensors-names = "cpu", "pcb north";
> +
> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
> +       coefficients =          <100    -120    484>;
> +
> +        trips {
> +               ...
> +        };
> +
> +       cooling-maps {
> +               ...
> +       };
> +};
> +
> +In some cases, there is a need to use more than one sensor to extrapolate
> +a thermal hotspot in the silicon. The above example illustrate this situation.

s/illustrate/illustrates/

> +For instance, it may be the case that a sensor external to CPU IP may be place

s/place/placed/

> +close to CPU hotspot and together with internal CPU sensor, it is used
> +to determine the hotspot. The hyppotetical extrapolation rule would be:

s/hyppotetical/hypothetical/

[...]

> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       /* thermal fw should take care of data->mask & (1 << trip) */

I mentioned this last time, and it's tripped me up again while reading:
It's rather too easy to read "fw" as "firmware" and get confused.

s/fw/framework/ please. :)

> +       data->trips[trip].temperature = temp;
> +
> +       return 0;
> +}

[...]

> +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 *))
> +{
> +       struct device_node *np, *child, *sensor_np;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np)
> +               return ERR_PTR(-ENODEV);
> +
> +       if (!dev || !dev->of_node)
> +               return ERR_PTR(-EINVAL);
> +
> +       sensor_np = dev->of_node;
> +
> +       for_each_child_of_node(np, child) {
> +               struct of_phandle_args sensor_specs;
> +               int ret, id;
> +
> +               /* For now, thermal framework supports only 1 sensor per zone */
> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
> +                                                "#thermal-sensor-cells",
> +                                                0, &sensor_specs);
> +               if (ret)
> +                       continue;
> +
> +               if (sensor_specs.args_count < 1)
> +                       id = 0;
> +               else
> +                       id = sensor_specs.args[0];
> +

For the moment it might be worth printing a warning if args_count > 1,
as thermal management might not function correctly.

> +               if (sensor_specs.np = sensor_np && id = sensor_id) {
> +                       of_node_put(np);
> +                       return thermal_zone_of_add_sensor(child, sensor_np,
> +                                                         data,
> +                                                         get_temp,
> +                                                         get_trend);
> +               }
> +       }
> +       of_node_put(np);
> +
> +       return ERR_PTR(-ENODEV);
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);

Cheers,
Mark.

[1] https://lkml.org/lkml/2013/9/24/501

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv7 03/18] thermal: introduce device tree parser
@ 2013-09-30 20:47       ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-30 20:47 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	linux, rui.zhang, wni, grant.likely, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 31945 bytes --]

Hi Mark

Thanks for another good review round. I am following up your concerns
inline.

On 30-09-2013 11:36, Mark Rutland wrote:
> Hi Eduardo,
> 
> On Fri, Sep 27, 2013 at 04:13:10AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: linux-pm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>
>> Hello folks,
>>
>> For those interested on this work, here is a short changelog from v6:
>> - Reviewed binding documentation and added type and size on all properties
>> - Described 'thermal-zones' node in binding documentation
>> - Using now cooling state terminology instead of cooling level
>> - Renamed milliCelsius to millicelsius
>> - Renamed cooling-attachments to 'cooling-maps'
>> - Renamed sensor to thermal sensor
>> - Renamed #sensor-cells to #thermal-sensor-cells
>> - #thermal-sensor-cells now is allowed to be 0
>> - Renamed 'sensors' property to 'thermal-sensors'
>> - Changed trip type property to be now string and documented possible values
>> - Described better the cooling properties
>> - Now parses 'contribution' instead of 'usage'
>> - Renamed cdev to cooling device
>> - Renamed 'passive-delay' property to 'polling-delay-passive'
>> - Fixed a couple of error messages to match the property name
>> - Fixed a binding issue while using cpufreq as module
>> - Reworked thermal_of_build_thermal_zone function so that it frees
>> requested memory if something goes wrong and checks for sub-nodes
>> with zero children.
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1466 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..3dbc017
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,537 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +Generic binding to provide a way of defining hardware thermal
>> +structure using device tree. A thermal structure includes thermal
>> +zones and their components, such as trip points, polling intervals,
>> +sensors and cooling devices binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects, not how the system must control or which
>> +algorithm or policy must be taken in place.
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
>> +- cooling devices: used to describe devices source of power dissipation control;
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
>> +- cooling maps: used to describe links between trip points and
>> +cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
>> +
>> +Note: This binding is a working in progress.
> 
> What does this mean? Is the binding expected to change in incompatible
> ways?

Well, no. The note was more to say we still don't have a final
agreement. But for merging this patch, once we have agreed to get it
merged, I believe this comment can be left out.

> 
> I see we have similar wording at the top of the clock bindings, which
> should probably go -- it's ABI now...

OK.

> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0, on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling, and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
>> +
>> +Required property:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
>> +
>> +- type:                        a string containing the trip type. Supported values are:
> 
> Odd spacing above.

Do you mean we should remove one \t? While in patch format it looks odd,
but in the ending file it will be aligned to the above descriptions
(from hysteresis and temperature).

> 
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle                referring to which cooling device is used in this
> 
> More odd spacing. There's a fair amount later that would be nice to fix
> up too.

OK. It would be nice to have a suggestion of preferred spacing though.
At least to me, looks pretty good to read.

> 
>> +                       binding. The required specifiers are: the minimum
>> +                       cooling state and the maximum cooling level used
>> +                       in this map.
> 
> There seems to be some confusion as to the word "specifier". Typically,
> a specifier is all the cells after the phandle described by the #*-cells
> property for the node pointed to. So here there is one
> cooling-specifier, which describes the min and max values, and possibly
> some other values.

OK. So specifier is the set of values that describe the reference to a
phandle. I will rephrase the document accordingly.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle                zone.
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> 
> How does that work with an unsigned value? Does the code check for
> 0xffffffff, or compare against -1?

The code define is -1UL (pasting existing defines):
/* invalid cooling state */
#define THERMAL_CSTATE_INVALID -1UL

/* No upper/lower limit requirement */
#define THERMAL_NO_LIMIT	THERMAL_CSTATE_INVALID


> 
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one node containing
>> +trip nodes and one node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay-passive:       The maximum number of milliseconds to wait
>> +  Type: unsigned               between polls when performing passive cooling.
>> +  Size: one cell
> 
> Is this when performing passive cooling, or any passive or above (i.e.
> any cooling whatsoever)?

No, just when performing passive cooling.

> 
>> +
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell

While polling for this zone, in any other state other than when doing
passive cooling, the above polling value is used. Including for when
doing any other cooling whatsoever.

>> +
>> +- thermal-sensors:             A list of sensor phandles and sensor specifier
>> +  Type: list of phandles       used while monitoring the thermal zone.
> 
> The type and the description don't agree here. The type description can
> probably be omitted as the description describes the format of the
> property.

OK. I just wanted to follow one single format while describing any
property in this document.

> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- thermal-sensors-names:       List of thermal sensor name strings sorted
>> +  Type: list of strings                in the same order as the thermal-sensors
>> +                               property.
> 
> Was there a reason for adding this?
> 

The reason is to describe where (physically) the sensor is, or which
location it represents, when a thermal zone is composed by several sensors.

> There was some confusion over my request for cooling-specifier and
> thermal-sensor-specifier terminology last time [1]. I was simply asking
> for terminology, not -names properties.

I see. So, answering you question in [1], I believe comments are enough
to describe where each sensor is located, if needed while writing the
binding for a specific thermal zone. At runtime, what would really make
the difference is the usage of the 'coefficients' property below, as
there is no simple way to guess the sensor contribution in the linear
relation just based on the string names provided.  Unless there is a
need to have this information, just for hardware description purposes.

> 
>> +
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors described in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offsets.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when active cooling is activated (polling-delay-passive); and
> 
> Ah, so any coolnig implies the passive polling delay. That makes teh
> naming confusing (active cooling means we're polling for the passive
> delay). Sorry for the poor suggestion.
> 

No, that was a very mistake in my phrasing. The above sentence must be:
+(i)  - when *passive* cooling is activated (polling-delay-passive); and

> How about having polling-delay-cooled instead. That better describes
> when it applies.
> 
>> +(ii) - when the zone just needs to be monitored (polling-delay).
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability.
> 
> It would be nice to have another line break here.

OK.

> 
>> +The delays are chosen to account for said max dT/dt, such that a device
> 
> s/are/should be/

indeed.

> 
>> +does not cross several trip boundaries unexpectedly between polls. Choosing
>> +the right polling delays shall avoid having the device in temperature ranges
>> +that may damage the silicon structures and reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes".
> 
> I assume thermal-zones appears under /, rather than under a subnode? It
> might be worth mentioning.

OK. I am adding this info.

> 
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       cpu0: cpu@0 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
> 
> If we're going to give an example of cpu nodes with cooling-cells, we
> should have a binding for cpu nodes explaining what the abstract cooling
> properties mean for them.
> 
> What _specifically_ do each of the values 0,1,2,3 mean here? Are they
> indexes of OPPs to use (which aren't shown in the example)? Are they
> specific to a particular CPU (the compatible string for which is not
> shown in the example)? Are they generic and applicable to all CPUs
> somehow?

OK. They are indexes of OPPs, yes, but in reverse order. That is, in the
case the CPU has 4 OPPs, 0 means all for OPPs are allowed to be used, 1
means only 3 lower OPPs are allowed, 2 means only 2 lower OPPs are
allowed to be used and 1 means only the lowest is allowed. I will add a
more detailed example.

> 
>> +
>> +&i2c1 {
>> +       ...
> 
> Having a comment inline describing this fictional sensor would be
> useful, something like:
> 
> 	/*
> 	 * A simple fan controlller. Supports 10 speeds of operation
> 	 * (represented as 0-9).
> 	 */
> 
> I didn't notice the block below until already having tried to comprehend
> the example. Inline comments would help in that regard.
> 

OK. I will add comments to describe them briefly.

>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
> 
> Similarly, it would be nice to have something here like:
> 
> 	/*
> 	 * A simple IC with a single bandgap temperature sensor.
> 	 */
> 
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <0>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
> 
> This should be under a thermal-zones node. Similarly for the other
> examples, they should have all relevant context.

OK. I agree  to add the thermal-zones container.

> 
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
> 
> The comment below is no longer relevant.

Indeed.

> 
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0>;
>> +
>> +        trips {
>> +                cpu-alert0: cpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_ACTIVE;
> 
> This got changed to a string in the binding, but is a CPP value here.
> Similarly in many other places below.

I am not sure I follow you here. What do you mean it is a CPP value? It
is simply a macro to a string.

> 
>> +                };
>> +                cpu-alert1: cpu-alert {
>> +                        temperature = <100000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                cpu-crit: cpu-crit {
>> +                        temperature = <125000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               map0 {
>> +                       trip = <&cpu-alert0>;
>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +               };
>> +               map1 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +               };
>> +               map2 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device =
>> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
>> +the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
>> +via I2C bus 1, at adress 0x48, which has ten different cooling states.
> 
> This is a little difficult to understand. How about:
> 
> In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
> used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
> device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
> different cooling states 0-9.

Yes, it is a better phrasing. Thanks.

> 
>> +It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
>> +cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     0>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                cpu-alert: cpu-alert {
>> +                        temperature = <100000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                cpu-crit: cpu-crit {
>> +                        temperature = <125000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +gpu-thermal: gpu-thermal {
>> +       polling-delay-passive = <120>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     1>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                gpu-alert: gpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                gpu-crit: gpu-crit {
>> +                        temperature = <105000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +dsp-thermal: dsp-thermal {
>> +       polling-delay-passive = <50>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     2>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                dsp-alert: gpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                dsp-crit: gpu-crit {
>> +                        temperature = <135000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +In the example above there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first specifier as sensor ID.
>> +In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,
> 
> The reference to bandgap.sensor0 is confusing. How about saying
> <&bandgap 0> instead? It makes it far easier to see correspondence
> between the text and the dt. Similarly for the other instances below.

Agreed.

> 
>> +bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
>> +is used to monitor DSP thermal zone. Each zone may be uncorrelated,
>> +having its own dT/dt requirements, trips and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <0>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0>,
>> +                         <&adc>;
>> +       thermal-sensors-names = "cpu", "pcb north";
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +       coefficients =          <100    -120    484>;
>> +
>> +        trips {
>> +               ...
>> +        };
>> +
>> +       cooling-maps {
>> +               ...
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrate this situation.
> 
> s/illustrate/illustrates/

OK.

> 
>> +For instance, it may be the case that a sensor external to CPU IP may be place
> 
> s/place/placed/

OK.

> 
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. The hyppotetical extrapolation rule would be:
> 
> s/hyppotetical/hypothetical/

OK.

> 
> [...]
> 
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal fw should take care of data->mask & (1 << trip) */
> 
> I mentioned this last time, and it's tripped me up again while reading:
> It's rather too easy to read "fw" as "firmware" and get confused.
> 
> s/fw/framework/ please. :)

OK.

> 
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
> 
> [...]
> 
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count < 1)
>> +                       id = 0;
>> +               else
>> +                       id = sensor_specs.args[0];
>> +
> 
> For the moment it might be worth printing a warning if args_count > 1,
> as thermal management might not function correctly.

Agreed. Adding this warning.

> 
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
> 
> Cheers,
> Mark.
> 
> [1] https://lkml.org/lkml/2013/9/24/501
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv7 03/18] thermal: introduce device tree parser
@ 2013-09-30 20:47       ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-30 20:47 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren-3lzwWm7+Weoh9ZMKESR00Q, Pawel Moll,
	ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 32045 bytes --]

Hi Mark

Thanks for another good review round. I am following up your concerns
inline.

On 30-09-2013 11:36, Mark Rutland wrote:
> Hi Eduardo,
> 
> On Fri, Sep 27, 2013 at 04:13:10AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>> ---
>>
>> Hello folks,
>>
>> For those interested on this work, here is a short changelog from v6:
>> - Reviewed binding documentation and added type and size on all properties
>> - Described 'thermal-zones' node in binding documentation
>> - Using now cooling state terminology instead of cooling level
>> - Renamed milliCelsius to millicelsius
>> - Renamed cooling-attachments to 'cooling-maps'
>> - Renamed sensor to thermal sensor
>> - Renamed #sensor-cells to #thermal-sensor-cells
>> - #thermal-sensor-cells now is allowed to be 0
>> - Renamed 'sensors' property to 'thermal-sensors'
>> - Changed trip type property to be now string and documented possible values
>> - Described better the cooling properties
>> - Now parses 'contribution' instead of 'usage'
>> - Renamed cdev to cooling device
>> - Renamed 'passive-delay' property to 'polling-delay-passive'
>> - Fixed a couple of error messages to match the property name
>> - Fixed a binding issue while using cpufreq as module
>> - Reworked thermal_of_build_thermal_zone function so that it frees
>> requested memory if something goes wrong and checks for sub-nodes
>> with zero children.
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1466 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..3dbc017
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,537 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +Generic binding to provide a way of defining hardware thermal
>> +structure using device tree. A thermal structure includes thermal
>> +zones and their components, such as trip points, polling intervals,
>> +sensors and cooling devices binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects, not how the system must control or which
>> +algorithm or policy must be taken in place.
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
>> +- cooling devices: used to describe devices source of power dissipation control;
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
>> +- cooling maps: used to describe links between trip points and
>> +cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
>> +
>> +Note: This binding is a working in progress.
> 
> What does this mean? Is the binding expected to change in incompatible
> ways?

Well, no. The note was more to say we still don't have a final
agreement. But for merging this patch, once we have agreed to get it
merged, I believe this comment can be left out.

> 
> I see we have similar wording at the top of the clock bindings, which
> should probably go -- it's ABI now...

OK.

> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0, on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling, and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
>> +
>> +Required property:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
>> +
>> +- type:                        a string containing the trip type. Supported values are:
> 
> Odd spacing above.

Do you mean we should remove one \t? While in patch format it looks odd,
but in the ending file it will be aligned to the above descriptions
(from hysteresis and temperature).

> 
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle                referring to which cooling device is used in this
> 
> More odd spacing. There's a fair amount later that would be nice to fix
> up too.

OK. It would be nice to have a suggestion of preferred spacing though.
At least to me, looks pretty good to read.

> 
>> +                       binding. The required specifiers are: the minimum
>> +                       cooling state and the maximum cooling level used
>> +                       in this map.
> 
> There seems to be some confusion as to the word "specifier". Typically,
> a specifier is all the cells after the phandle described by the #*-cells
> property for the node pointed to. So here there is one
> cooling-specifier, which describes the min and max values, and possibly
> some other values.

OK. So specifier is the set of values that describe the reference to a
phandle. I will rephrase the document accordingly.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle                zone.
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> 
> How does that work with an unsigned value? Does the code check for
> 0xffffffff, or compare against -1?

The code define is -1UL (pasting existing defines):
/* invalid cooling state */
#define THERMAL_CSTATE_INVALID -1UL

/* No upper/lower limit requirement */
#define THERMAL_NO_LIMIT	THERMAL_CSTATE_INVALID


> 
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one node containing
>> +trip nodes and one node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay-passive:       The maximum number of milliseconds to wait
>> +  Type: unsigned               between polls when performing passive cooling.
>> +  Size: one cell
> 
> Is this when performing passive cooling, or any passive or above (i.e.
> any cooling whatsoever)?

No, just when performing passive cooling.

> 
>> +
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell

While polling for this zone, in any other state other than when doing
passive cooling, the above polling value is used. Including for when
doing any other cooling whatsoever.

>> +
>> +- thermal-sensors:             A list of sensor phandles and sensor specifier
>> +  Type: list of phandles       used while monitoring the thermal zone.
> 
> The type and the description don't agree here. The type description can
> probably be omitted as the description describes the format of the
> property.

OK. I just wanted to follow one single format while describing any
property in this document.

> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- thermal-sensors-names:       List of thermal sensor name strings sorted
>> +  Type: list of strings                in the same order as the thermal-sensors
>> +                               property.
> 
> Was there a reason for adding this?
> 

The reason is to describe where (physically) the sensor is, or which
location it represents, when a thermal zone is composed by several sensors.

> There was some confusion over my request for cooling-specifier and
> thermal-sensor-specifier terminology last time [1]. I was simply asking
> for terminology, not -names properties.

I see. So, answering you question in [1], I believe comments are enough
to describe where each sensor is located, if needed while writing the
binding for a specific thermal zone. At runtime, what would really make
the difference is the usage of the 'coefficients' property below, as
there is no simple way to guess the sensor contribution in the linear
relation just based on the string names provided.  Unless there is a
need to have this information, just for hardware description purposes.

> 
>> +
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors described in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offsets.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when active cooling is activated (polling-delay-passive); and
> 
> Ah, so any coolnig implies the passive polling delay. That makes teh
> naming confusing (active cooling means we're polling for the passive
> delay). Sorry for the poor suggestion.
> 

No, that was a very mistake in my phrasing. The above sentence must be:
+(i)  - when *passive* cooling is activated (polling-delay-passive); and

> How about having polling-delay-cooled instead. That better describes
> when it applies.
> 
>> +(ii) - when the zone just needs to be monitored (polling-delay).
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability.
> 
> It would be nice to have another line break here.

OK.

> 
>> +The delays are chosen to account for said max dT/dt, such that a device
> 
> s/are/should be/

indeed.

> 
>> +does not cross several trip boundaries unexpectedly between polls. Choosing
>> +the right polling delays shall avoid having the device in temperature ranges
>> +that may damage the silicon structures and reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes".
> 
> I assume thermal-zones appears under /, rather than under a subnode? It
> might be worth mentioning.

OK. I am adding this info.

> 
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       cpu0: cpu@0 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
> 
> If we're going to give an example of cpu nodes with cooling-cells, we
> should have a binding for cpu nodes explaining what the abstract cooling
> properties mean for them.
> 
> What _specifically_ do each of the values 0,1,2,3 mean here? Are they
> indexes of OPPs to use (which aren't shown in the example)? Are they
> specific to a particular CPU (the compatible string for which is not
> shown in the example)? Are they generic and applicable to all CPUs
> somehow?

OK. They are indexes of OPPs, yes, but in reverse order. That is, in the
case the CPU has 4 OPPs, 0 means all for OPPs are allowed to be used, 1
means only 3 lower OPPs are allowed, 2 means only 2 lower OPPs are
allowed to be used and 1 means only the lowest is allowed. I will add a
more detailed example.

> 
>> +
>> +&i2c1 {
>> +       ...
> 
> Having a comment inline describing this fictional sensor would be
> useful, something like:
> 
> 	/*
> 	 * A simple fan controlller. Supports 10 speeds of operation
> 	 * (represented as 0-9).
> 	 */
> 
> I didn't notice the block below until already having tried to comprehend
> the example. Inline comments would help in that regard.
> 

OK. I will add comments to describe them briefly.

>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
> 
> Similarly, it would be nice to have something here like:
> 
> 	/*
> 	 * A simple IC with a single bandgap temperature sensor.
> 	 */
> 
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <0>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
> 
> This should be under a thermal-zones node. Similarly for the other
> examples, they should have all relevant context.

OK. I agree  to add the thermal-zones container.

> 
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
> 
> The comment below is no longer relevant.

Indeed.

> 
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0>;
>> +
>> +        trips {
>> +                cpu-alert0: cpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_ACTIVE;
> 
> This got changed to a string in the binding, but is a CPP value here.
> Similarly in many other places below.

I am not sure I follow you here. What do you mean it is a CPP value? It
is simply a macro to a string.

> 
>> +                };
>> +                cpu-alert1: cpu-alert {
>> +                        temperature = <100000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                cpu-crit: cpu-crit {
>> +                        temperature = <125000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               map0 {
>> +                       trip = <&cpu-alert0>;
>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +               };
>> +               map1 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +               };
>> +               map2 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device =
>> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
>> +the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
>> +via I2C bus 1, at adress 0x48, which has ten different cooling states.
> 
> This is a little difficult to understand. How about:
> 
> In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
> used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
> device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
> different cooling states 0-9.

Yes, it is a better phrasing. Thanks.

> 
>> +It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
>> +cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     0>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                cpu-alert: cpu-alert {
>> +                        temperature = <100000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                cpu-crit: cpu-crit {
>> +                        temperature = <125000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +gpu-thermal: gpu-thermal {
>> +       polling-delay-passive = <120>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     1>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                gpu-alert: gpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                gpu-crit: gpu-crit {
>> +                        temperature = <105000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +dsp-thermal: dsp-thermal {
>> +       polling-delay-passive = <50>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     2>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                dsp-alert: gpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                dsp-crit: gpu-crit {
>> +                        temperature = <135000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +In the example above there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first specifier as sensor ID.
>> +In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,
> 
> The reference to bandgap.sensor0 is confusing. How about saying
> <&bandgap 0> instead? It makes it far easier to see correspondence
> between the text and the dt. Similarly for the other instances below.

Agreed.

> 
>> +bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
>> +is used to monitor DSP thermal zone. Each zone may be uncorrelated,
>> +having its own dT/dt requirements, trips and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <0>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0>,
>> +                         <&adc>;
>> +       thermal-sensors-names = "cpu", "pcb north";
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +       coefficients =          <100    -120    484>;
>> +
>> +        trips {
>> +               ...
>> +        };
>> +
>> +       cooling-maps {
>> +               ...
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrate this situation.
> 
> s/illustrate/illustrates/

OK.

> 
>> +For instance, it may be the case that a sensor external to CPU IP may be place
> 
> s/place/placed/

OK.

> 
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. The hyppotetical extrapolation rule would be:
> 
> s/hyppotetical/hypothetical/

OK.

> 
> [...]
> 
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal fw should take care of data->mask & (1 << trip) */
> 
> I mentioned this last time, and it's tripped me up again while reading:
> It's rather too easy to read "fw" as "firmware" and get confused.
> 
> s/fw/framework/ please. :)

OK.

> 
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
> 
> [...]
> 
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count < 1)
>> +                       id = 0;
>> +               else
>> +                       id = sensor_specs.args[0];
>> +
> 
> For the moment it might be worth printing a warning if args_count > 1,
> as thermal management might not function correctly.

Agreed. Adding this warning.

> 
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
> 
> Cheers,
> Mark.
> 
> [1] https://lkml.org/lkml/2013/9/24/501
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv7 03/18] thermal: introduce device tree parser
@ 2013-09-30 20:47       ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-09-30 20:47 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	linux, rui.zhang, wni, grant.likely, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 31945 bytes --]

Hi Mark

Thanks for another good review round. I am following up your concerns
inline.

On 30-09-2013 11:36, Mark Rutland wrote:
> Hi Eduardo,
> 
> On Fri, Sep 27, 2013 at 04:13:10AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: linux-pm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>
>> Hello folks,
>>
>> For those interested on this work, here is a short changelog from v6:
>> - Reviewed binding documentation and added type and size on all properties
>> - Described 'thermal-zones' node in binding documentation
>> - Using now cooling state terminology instead of cooling level
>> - Renamed milliCelsius to millicelsius
>> - Renamed cooling-attachments to 'cooling-maps'
>> - Renamed sensor to thermal sensor
>> - Renamed #sensor-cells to #thermal-sensor-cells
>> - #thermal-sensor-cells now is allowed to be 0
>> - Renamed 'sensors' property to 'thermal-sensors'
>> - Changed trip type property to be now string and documented possible values
>> - Described better the cooling properties
>> - Now parses 'contribution' instead of 'usage'
>> - Renamed cdev to cooling device
>> - Renamed 'passive-delay' property to 'polling-delay-passive'
>> - Fixed a couple of error messages to match the property name
>> - Fixed a binding issue while using cpufreq as module
>> - Reworked thermal_of_build_thermal_zone function so that it frees
>> requested memory if something goes wrong and checks for sub-nodes
>> with zero children.
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 537 +++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 845 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1466 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..3dbc017
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,537 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +Generic binding to provide a way of defining hardware thermal
>> +structure using device tree. A thermal structure includes thermal
>> +zones and their components, such as trip points, polling intervals,
>> +sensors and cooling devices binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects, not how the system must control or which
>> +algorithm or policy must be taken in place.
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
>> +- cooling devices: used to describe devices source of power dissipation control;
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
>> +- cooling maps: used to describe links between trip points and
>> +cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
>> +
>> +Note: This binding is a working in progress.
> 
> What does this mean? Is the binding expected to change in incompatible
> ways?

Well, no. The note was more to say we still don't have a final
agreement. But for merging this patch, once we have agreed to get it
merged, I believe this comment can be left out.

> 
> I see we have similar wording at the top of the clock bindings, which
> should probably go -- it's ABI now...

OK.

> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0, on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling, and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
>> +
>> +Required property:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
>> +
>> +- type:                        a string containing the trip type. Supported values are:
> 
> Odd spacing above.

Do you mean we should remove one \t? While in patch format it looks odd,
but in the ending file it will be aligned to the above descriptions
(from hysteresis and temperature).

> 
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle                referring to which cooling device is used in this
> 
> More odd spacing. There's a fair amount later that would be nice to fix
> up too.

OK. It would be nice to have a suggestion of preferred spacing though.
At least to me, looks pretty good to read.

> 
>> +                       binding. The required specifiers are: the minimum
>> +                       cooling state and the maximum cooling level used
>> +                       in this map.
> 
> There seems to be some confusion as to the word "specifier". Typically,
> a specifier is all the cells after the phandle described by the #*-cells
> property for the node pointed to. So here there is one
> cooling-specifier, which describes the min and max values, and possibly
> some other values.

OK. So specifier is the set of values that describe the reference to a
phandle. I will rephrase the document accordingly.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle                zone.
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> 
> How does that work with an unsigned value? Does the code check for
> 0xffffffff, or compare against -1?

The code define is -1UL (pasting existing defines):
/* invalid cooling state */
#define THERMAL_CSTATE_INVALID -1UL

/* No upper/lower limit requirement */
#define THERMAL_NO_LIMIT	THERMAL_CSTATE_INVALID


> 
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one node containing
>> +trip nodes and one node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay-passive:       The maximum number of milliseconds to wait
>> +  Type: unsigned               between polls when performing passive cooling.
>> +  Size: one cell
> 
> Is this when performing passive cooling, or any passive or above (i.e.
> any cooling whatsoever)?

No, just when performing passive cooling.

> 
>> +
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell

While polling for this zone, in any other state other than when doing
passive cooling, the above polling value is used. Including for when
doing any other cooling whatsoever.

>> +
>> +- thermal-sensors:             A list of sensor phandles and sensor specifier
>> +  Type: list of phandles       used while monitoring the thermal zone.
> 
> The type and the description don't agree here. The type description can
> probably be omitted as the description describes the format of the
> property.

OK. I just wanted to follow one single format while describing any
property in this document.

> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- thermal-sensors-names:       List of thermal sensor name strings sorted
>> +  Type: list of strings                in the same order as the thermal-sensors
>> +                               property.
> 
> Was there a reason for adding this?
> 

The reason is to describe where (physically) the sensor is, or which
location it represents, when a thermal zone is composed by several sensors.

> There was some confusion over my request for cooling-specifier and
> thermal-sensor-specifier terminology last time [1]. I was simply asking
> for terminology, not -names properties.

I see. So, answering you question in [1], I believe comments are enough
to describe where each sensor is located, if needed while writing the
binding for a specific thermal zone. At runtime, what would really make
the difference is the usage of the 'coefficients' property below, as
there is no simple way to guess the sensor contribution in the linear
relation just based on the string names provided.  Unless there is a
need to have this information, just for hardware description purposes.

> 
>> +
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors described in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offsets.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when active cooling is activated (polling-delay-passive); and
> 
> Ah, so any coolnig implies the passive polling delay. That makes teh
> naming confusing (active cooling means we're polling for the passive
> delay). Sorry for the poor suggestion.
> 

No, that was a very mistake in my phrasing. The above sentence must be:
+(i)  - when *passive* cooling is activated (polling-delay-passive); and

> How about having polling-delay-cooled instead. That better describes
> when it applies.
> 
>> +(ii) - when the zone just needs to be monitored (polling-delay).
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability.
> 
> It would be nice to have another line break here.

OK.

> 
>> +The delays are chosen to account for said max dT/dt, such that a device
> 
> s/are/should be/

indeed.

> 
>> +does not cross several trip boundaries unexpectedly between polls. Choosing
>> +the right polling delays shall avoid having the device in temperature ranges
>> +that may damage the silicon structures and reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes".
> 
> I assume thermal-zones appears under /, rather than under a subnode? It
> might be worth mentioning.

OK. I am adding this info.

> 
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       cpu0: cpu@0 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
> 
> If we're going to give an example of cpu nodes with cooling-cells, we
> should have a binding for cpu nodes explaining what the abstract cooling
> properties mean for them.
> 
> What _specifically_ do each of the values 0,1,2,3 mean here? Are they
> indexes of OPPs to use (which aren't shown in the example)? Are they
> specific to a particular CPU (the compatible string for which is not
> shown in the example)? Are they generic and applicable to all CPUs
> somehow?

OK. They are indexes of OPPs, yes, but in reverse order. That is, in the
case the CPU has 4 OPPs, 0 means all for OPPs are allowed to be used, 1
means only 3 lower OPPs are allowed, 2 means only 2 lower OPPs are
allowed to be used and 1 means only the lowest is allowed. I will add a
more detailed example.

> 
>> +
>> +&i2c1 {
>> +       ...
> 
> Having a comment inline describing this fictional sensor would be
> useful, something like:
> 
> 	/*
> 	 * A simple fan controlller. Supports 10 speeds of operation
> 	 * (represented as 0-9).
> 	 */
> 
> I didn't notice the block below until already having tried to comprehend
> the example. Inline comments would help in that regard.
> 

OK. I will add comments to describe them briefly.

>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
> 
> Similarly, it would be nice to have something here like:
> 
> 	/*
> 	 * A simple IC with a single bandgap temperature sensor.
> 	 */
> 
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <0>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
> 
> This should be under a thermal-zones node. Similarly for the other
> examples, they should have all relevant context.

OK. I agree  to add the thermal-zones container.

> 
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
> 
> The comment below is no longer relevant.

Indeed.

> 
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0>;
>> +
>> +        trips {
>> +                cpu-alert0: cpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_ACTIVE;
> 
> This got changed to a string in the binding, but is a CPP value here.
> Similarly in many other places below.

I am not sure I follow you here. What do you mean it is a CPP value? It
is simply a macro to a string.

> 
>> +                };
>> +                cpu-alert1: cpu-alert {
>> +                        temperature = <100000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                cpu-crit: cpu-crit {
>> +                        temperature = <125000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               map0 {
>> +                       trip = <&cpu-alert0>;
>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +               };
>> +               map1 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +               };
>> +               map2 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device =
>> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor at address 0x0000ED00 is used to monitor
>> +the zone 'cpu-thermal' using its the sensor 0. The fan0, a fan device controlled
>> +via I2C bus 1, at adress 0x48, which has ten different cooling states.
> 
> This is a little difficult to understand. How about:
> 
> In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
> used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
> device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
> different cooling states 0-9.

Yes, it is a better phrasing. Thanks.

> 
>> +It is used to remove the heat out of the thermal zone 'cpu-thermal' using its
>> +cooling states from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     0>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                cpu-alert: cpu-alert {
>> +                        temperature = <100000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                cpu-crit: cpu-crit {
>> +                        temperature = <125000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +gpu-thermal: gpu-thermal {
>> +       polling-delay-passive = <120>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     1>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                gpu-alert: gpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                gpu-crit: gpu-crit {
>> +                        temperature = <105000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +dsp-thermal: dsp-thermal {
>> +       polling-delay-passive = <50>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        thermal-sensors = <&bandgap0     2>;
>> +
>> +        trips {
>> +               /* each zone within the SoC may have its own trips */
>> +                dsp-alert: gpu-alert {
>> +                        temperature = <90000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_PASSIVE;
>> +                };
>> +                dsp-crit: gpu-crit {
>> +                        temperature = <135000>; /* millicelsius */
>> +                        hysteresis = <2000>; /* millicelsius */
>> +                        type = THERMAL_TRIP_CRITICAL;
>> +                };
>> +        };
>> +
>> +       cooling-maps {
>> +               /* each zone within the SoC may have its own cooling */
>> +               ...
>> +       };
>> +};
>> +
>> +In the example above there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first specifier as sensor ID.
>> +In the example, then, bandgap.sensor0 is used to monitor CPU thermal zone,
> 
> The reference to bandgap.sensor0 is confusing. How about saying
> <&bandgap 0> instead? It makes it far easier to see correspondence
> between the text and the dt. Similarly for the other instances below.

Agreed.

> 
>> +bandgap.sensor1 is used to monitor GPU thermal zone and bandgap.sensor2
>> +is used to monitor DSP thermal zone. Each zone may be uncorrelated,
>> +having its own dT/dt requirements, trips and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #thermal-sensor-cells = <0>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       polling-delay-passive = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +                       /* sensor       ID */
>> +        thermal-sensors = <&bandgap0>,
>> +                         <&adc>;
>> +       thermal-sensors-names = "cpu", "pcb north";
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +       coefficients =          <100    -120    484>;
>> +
>> +        trips {
>> +               ...
>> +        };
>> +
>> +       cooling-maps {
>> +               ...
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrate this situation.
> 
> s/illustrate/illustrates/

OK.

> 
>> +For instance, it may be the case that a sensor external to CPU IP may be place
> 
> s/place/placed/

OK.

> 
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. The hyppotetical extrapolation rule would be:
> 
> s/hyppotetical/hypothetical/

OK.

> 
> [...]
> 
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal fw should take care of data->mask & (1 << trip) */
> 
> I mentioned this last time, and it's tripped me up again while reading:
> It's rather too easy to read "fw" as "firmware" and get confused.
> 
> s/fw/framework/ please. :)

OK.

> 
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
> 
> [...]
> 
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count < 1)
>> +                       id = 0;
>> +               else
>> +                       id = sensor_specs.args[0];
>> +
> 
> For the moment it might be worth printing a warning if args_count > 1,
> as thermal management might not function correctly.

Agreed. Adding this warning.

> 
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
> 
> Cheers,
> Mark.
> 
> [1] https://lkml.org/lkml/2013/9/24/501
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCHv8 03/18] thermal: introduce device tree parser
@ 2013-10-01  2:39     ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-10-01  2:39 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
Hello Mark, folks,

So, here is v8. Pretty small changes. Most are better
English phrasing in the binding document. It follows changelog:
- Several rephrasing in the binding document, including
spelling, grammar and better phrasing.
- Removed WiP warning from binding document.
- Several spacing and formatting changes in the binding document
- Used the '-specifier' nomenclature properly in the binding doc
- Removed the optional property 'thermal-sensors-names', because
it does not provide useful runtime information
- Fixed description of 'polling-delay-passive'
- Improved examples by adding comments and better explanation
- s/fw/framework/g
- Added a WARN when sensors specifiers are greater and 1.

All best,

Eduardo

---
 .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |   9 +-
 drivers/thermal/thermal_core.h                     |   9 +
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/thermal.h                            |  28 +-
 8 files changed, 1520 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..ad06a8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,587 @@
+* Thermal Framework Device Tree descriptor
+
+This file describes a generic binding to provide a way of
+defining hardware thermal structure using device tree.
+A thermal structure includes thermal zones and their components,
+such as trip points, polling intervals, sensors and cooling devices
+binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects. The thermal device tree bindings are
+not about how the system must control or which algorithm or policy
+must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling maps: used to describe links between trip points and cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+* Thermal sensor devices
+
+Thermal sensor devices are nodes providing temperature sensing capabilities on
+thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
+nodes providing temperature data to thermal zones. Thermal sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #thermal-sensor-cells: Used to provide sensor device specific information
+  Type: unsigned	 while referring to it. Typically 0 on thermal sensor
+  Size: one cell	 nodes with only one sensor, and at least 1 on nodes
+			 with several internal sensors, in order
+			 to identify uniquely the sensor instances within
+			 the IC. See thermal zone binding for more details
+			 on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. A typical passive cooling is a CPU that has dynamic voltage and
+frequency scaling (DVFS), and uses lower frequencies as cooling states.
+Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the state of cooling in which the device is.
+
+Required properties:
+- cooling-min-state:	An integer indicating the smallest
+  Type: unsigned	cooling state accepted. Typically 0.
+  Size: one cell
+
+- cooling-max-state:	An integer indicating the largest
+  Type: unsigned	cooling state accepted.
+  Size: one cell
+
+- #cooling-cells:	Used to provide cooling device specific information
+  Type: unsigned	while referring to it. Must be at least 2, in order
+  Size: one cell      	to specify minimum and maximum cooling state used
+			in the reference. The first cell is the minimum
+			cooling state requested and the second cell is
+			the maximum cooling state requested in the reference.
+			See Cooling device maps section below for more details
+			on how consumers refer to cooling devices.
+
+* Trip points
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+Required properties:
+- temperature:		An integer indicating the trip temperature level,
+  Type: signed		in millicelsius.
+  Size: one cell
+
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+  Type: unsigned	relative value, in millicelsius.
+  Size: one cell
+
+- type:			a string containing the trip type. Supported values are:
+	"active":	A trip point to enable active cooling
+	"passive":	A trip point to enable passive cooling
+	"hot":		A trip point to notify emergency
+	"critical":	Hardware not reliable.
+  Type: string
+
+There are also string constants defined at
+include/dt-bindings/thermal/thermal.h.
+
+* Cooling device maps
+
+The cooling device maps node is a node to describe how cooling devices
+get assigned to trip points of the zone. The cooling devices are expected
+to be loaded in the target system.
+
+Required properties:
+- cooling-device:	A phandle of a cooling device with its specifier,
+  Type: phandle of	referring to which cooling device is used in this
+    cooling device	binding. In the cooling specifier, the first cell
+			is the minimum cooling state and the second cell
+			is the maximum cooling state used in this map.
+- trip:			A phandle of a trip point node within the same thermal
+  Type: phandle of	zone.
+   trip point node
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+  Type: unsigned	referred cooling device at the referred trip point.
+  Size: one cell      	The contribution is a ratio of the sum
+			of all cooling contributions within a thermal zone.
+
+Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
+limit specifier means:
+(i)   - minimum state allowed for minimum cooling state used in the reference.
+(ii)  - maximum state allowed for maximum cooling state used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zone nodes
+
+The thermal zone node is the node containing all the required info
+for describing a thermal zone, including its cooling device bindings. The
+thermal zone node must contain, apart from its own properties, one sub-node
+containing trip nodes and one sub-node containing all the zone cooling maps.
+
+Required properties:
+- polling-delay:	The maximum number of milliseconds to wait between polls
+  Type: unsigned	when checking this thermal zone.
+  Size: one cell
+
+- polling-delay-passive: The maximum number of milliseconds to wait
+  Type: unsigned	between polls when performing passive cooling.
+  Size: one cell
+
+- thermal-sensors:	A list of thermal sensor phandles and sensor specifier
+  Type: list of 	used while monitoring the thermal zone.
+  sensor phandles
+
+- trips:		A sub-node which is a container of only trip point nodes
+  Type: sub-node	required to describe the thermal zone.
+
+- cooling-maps:		A sub-node which is a container of only cooling device
+  Type: sub-node	map nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+  Type: array		coefficients to compose a linear relation between
+  Elem size: one cell	the sensors listed in the thermal-sensors property.
+  Elem type: signed	Coefficients defaults to 1, in case this property
+			is not specified. A simple linear polynomial is used:
+			Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
+
+			The coefficients are ordered and they match with sensors
+			by means of sensor ID. Additional coefficients are
+			interpreted as constant offset.
+
+Note: The delay properties are bound to the maximum dT/dt (temperature
+derivative over time) in two situations for a thermal zone:
+(i)  - when passive cooling is activated (polling-delay-passive); and
+(ii) - when the zone just needs to be monitored (polling-delay) or
+when active cooling is activated.
+
+The maximum dT/dt is highly bound to hardware power consumption and dissipation
+capability. The delays should be chosen to account for said max dT/dt,
+such that a device does not cross several trip boundaries unexpectedly
+between polls. Choosing the right polling delays shall avoid having the
+device in temperature ranges that may damage the silicon structures and
+reduce silicon lifetime.
+
+* The thermal-zones node
+
+The "thermal-zones" node is a container for all thermal zone nodes. It shall
+contain only sub-nodes describing thermal zones as in the section
+"Thermal zone nodes". The "thermal-zones" node appears under "/".
+
+* Examples
+
+Below are several examples on how to use thermal data descriptors
+using device tree bindings:
+
+(a) - CPU thermal zone
+
+The CPU thermal zone example below describes how to setup one thermal zone
+using one single sensor as temperature source and many cooling devices and
+power dissipation control sources.
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpus {
+	/*
+	 * Here is an example of describing a cooling device for a DVFS
+	 * capable CPU. The CPU node describes its four OPPs.
+	 * The cooling states possible are 0..3, and they are
+	 * used as OPP indexes. The minimum cooling state is 0, which means
+	 * all four OPPs can be available to the system. The maximum
+	 * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
+	 * can be available in the system.
+	 */
+	cpu0: cpu@0 {
+		...
+		operating-points = <
+			/* kHz    uV */
+			970000  1200000
+			792000  1100000
+			396000  950000
+			198000  850000
+		>;
+		cooling-min-state = <0>;
+		cooling-max-state = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	/*
+	 * A simple fan controller which supports 10 speeds of operation
+	 * (represented as 0-9).
+	 */
+	fan0: fan@0x48 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+ocp {
+	...
+	/*
+	 * A simple IC with a single bandgap temperature sensor.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+	        thermal-sensors = <&bandgap0>;
+
+        	trips {
+                	cpu-alert0: cpu-alert {
+                        	temperature = <90000>; /* millicelsius */
+	                        hysteresis = <2000>; /* millicelsius */
+        	                type = "active";
+	                };
+        	        cpu-alert1: cpu-alert {
+                	        temperature = <100000>; /* millicelsius */
+                        	hysteresis = <2000>; /* millicelsius */
+	                        type = "passive";
+        	        };
+                	cpu-crit: cpu-crit {
+	                        temperature = <125000>; /* millicelsius */
+        	                hysteresis = <2000>; /* millicelsius */
+                	        type = "critical";
+                	};
+        	};
+
+		cooling-maps {
+			map0 {
+				trip = <&cpu-alert0>;
+				cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+			};
+			map1 {
+				trip = <&cpu-alert1>;
+				cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+			};
+			map2 {
+				trip = <&cpu-alert1>;
+				cooling-device =
+				    <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+			};
+		};
+	};
+};
+
+In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
+used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
+device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
+different cooling states 0-9. It is used to remove the heat out of
+the thermal zone 'cpu-thermal' using its cooling states
+from its minimum to 4, when it reaches trip point 'cpu-alert0'
+at 90C, as an example of active cooling. The same cooling device is used at
+'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
+using all its cooling states at trip point 'cpu-alert1',
+which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
+temperature of 125C, represented by the trip point 'cpu-crit', the silicon
+is not reliable anymore.
+
+(b) - IC with several internal sensors
+
+The example below describes how to deploy several thermal zones based off a
+single sensor IC, assuming it has several internal sensors. This is a common
+case on SoC designs with several internal IPs that may need different thermal
+requirements, and thus may have their own sensor to monitor or detect internal
+hotspots in their silicon.
+
+#include <dt-bindings/thermal/thermal.h>
+
+ocp {
+	...
+	/*
+	 * A simple IC with several bandgap temperature sensors.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <1>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     0>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			cpu-alert: cpu-alert {
+				temperature = <100000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			cpu-crit: cpu-crit {
+				temperature = <125000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+
+	gpu-thermal: gpu-thermal {
+		polling-delay-passive = <120>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     1>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			gpu-alert: gpu-alert {
+				temperature = <90000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			gpu-crit: gpu-crit {
+				temperature = <105000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+
+	dsp-thermal: dsp-thermal {
+		polling-delay-passive = <50>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     2>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			dsp-alert: gpu-alert {
+				temperature = <90000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			dsp-crit: gpu-crit {
+				temperature = <135000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+};
+
+In the example above, there is one bandgap IC which has the capability to
+monitor three sensors. The hardware has been designed so that sensors are
+placed on different places in the DIE to monitor different temperature
+hotspots: one for CPU thermal zone, one for GPU thermal zone and the
+other to monitor a DSP thermal zone.
+
+Thus, there is a need to assign each sensor provided by the bandgap IC
+to different thermal zones. This is achieved by means of using the
+#thermal-sensor-cells property and using the first cell of the sensor
+specifier as sensor ID. In the example, then, <bandgap 0> is used to
+monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
+zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
+may be uncorrelated, having its own dT/dt requirements, trips
+and cooling maps.
+
+
+(c) - Several sensors within one single thermal zone
+
+The example below illustrates how to use more than one sensor within
+one thermal zone.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	/*
+	 * A simple IC with a single temperature sensor.
+	 */
+	adc: sensor@0x49 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+ocp {
+	...
+	/*
+	 * A simple IC with a single bandgap temperature sensor.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+		thermal-sensors = <&bandgap0>,	/* cpu */
+				  <&adc>;	/* pcb north */
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+		coefficients = 		<100	-120	484>;
+
+		trips {
+			...
+		};
+
+		cooling-maps {
+			...
+		};
+	};
+};
+
+In some cases, there is a need to use more than one sensor to extrapolate
+a thermal hotspot in the silicon. The above example illustrates this situation.
+For instance, it may be the case that a sensor external to CPU IP may be placed
+close to CPU hotspot and together with internal CPU sensor, it is used
+to determine the hotspot. Assuming this is the case for the above example,
+the hypothetical extrapolation rule would be:
+		hotspot = 100 * bandgap - 120 * adc + 484
+
+In other context, the same idea can be used to add fixed offset. For instance,
+consider the hotspot extrapolation rule below:
+		hotspot = 1 * adc + 6000
+
+In the above equation, the hotspot is always 6C higher than what is read
+from the ADC sensor. The binding would be then:
+        thermal-sensors =  <&adc>;
+
+		/* hotspot = 1 * adc + 6000 */
+	coefficients = 		<1	6000>;
+
+(d) - Board thermal
+
+The board thermal example below illustrates how to setup one thermal zone
+with many sensors and many cooling devices.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	/*
+	 * An IC with several temperature sensor.
+	 */
+	adc-dummy: sensor@0x50 {
+		...
+		#thermal-sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+thermal-zones {
+	batt-thermal {
+		polling-delay-passive = <500>; /* milliseconds */
+		polling-delay = <2500>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&adc-dummy     4>;
+
+		trips {
+			...
+		};
+
+		cooling-maps {
+			...
+		};
+	};
+
+	board-thermal: board-thermal {
+		polling-delay-passive = <1000>; /* milliseconds */
+		polling-delay = <2500>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
+				  <&adc-dummy     1>, /* lcd */
+				  <&adc-dymmy     2>; /* back cover */
+		/*
+		 * An array of coefficients describing the sensor
+		 * linear relation. E.g.:
+		 * z = c1*x1 + c2*x2 + c3*x3
+		 */
+		coefficients =		<1200	-345	890>;
+
+		trips {
+			/* Trips are based on resulting linear equation */
+			cpu-trip: cpu-trip {
+				temperature = <60000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			gpu-trip: gpu-trip {
+				temperature = <55000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			}
+			lcd-trip: lcp-trip {
+				temperature = <53000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			crit-trip: crit-trip {
+				temperature = <68000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			map0 {
+				trip = <&cpu-trip>;
+				cooling-device = <&cpu0 0 2>;
+				contribution = <55>;
+			};
+			map1 {
+				trip = <&gpu-trip>;
+				cooling-device = <&gpu0 0 2>;
+				contribution = <20>;
+			};
+			map2 {
+				trip = <&lcd-trip>;
+				cooling-device = <&lcd0 5 10>;
+				contribution = <15>;
+			};
+		};
+	};
+};
+
+The above example is a mix of previous examples, a sensor IP with several internal
+sensors used to monitor different zones, one of them is composed by several sensors and
+with different cooling devices.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dbfc390..dd81eb8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,6 +29,19 @@ config THERMAL_HWMON
 	  Say 'Y' here if you want all thermal sensors to
 	  have hwmon sysfs interface too.
 
+config THERMAL_OF
+	bool
+	prompt "APIs to parse thermal data out of device tree"
+	depends on OF
+	default y
+	help
+	  This options provides helpers to add the support to
+	  read and parse thermal data definitions out of the
+	  device tree blob.
+
+	  Say 'Y' here if you need to build thermal infrastructure
+	  based on device tree.
+
 choice
 	prompt "Default Thermal governor"
 	default THERMAL_DEFAULT_GOV_STEP_WISE
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 584b363..4b03956 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,6 +7,7 @@ thermal_sys-y			+= thermal_core.o
 
 # interface to/from other layers providing sensors
 thermal_sys-$(CONFIG_THERMAL_HWMON)		+= thermal_hwmon.o
+thermal_sys-$(CONFIG_THERMAL_OF)		+= of-thermal.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)	+= fair_share.o
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
new file mode 100644
index 0000000..66f9eb2
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,849 @@
+/*
+ *  of-thermal.c - Generic Thermal Management device tree support.
+ *
+ *  Copyright (C) 2013 Texas Instruments
+ *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ *
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/thermal.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/string.h>
+
+#include "thermal_core.h"
+
+/***   Private data structures to represent thermal device tree data ***/
+
+/**
+ * struct __thermal_trip - representation of a point in temperature domain
+ * @np: pointer to struct device_node that this trip point was created from
+ * @temperature: temperature value in miliCelsius
+ * @hysteresis: relative hysteresis in miliCelsius
+ * @type: trip point type
+ */
+
+struct __thermal_trip {
+	struct device_node *np;
+	unsigned long int temperature;
+	unsigned long int hysteresis;
+	enum thermal_trip_type type;
+};
+
+/**
+ * struct __thermal_bind_param - a match between trip and cooling device
+ * @cooling_device: a pointer to identify the referred cooling device
+ * @trip_id: the trip point index
+ * @usage: the percentage (from 0 to 100) of cooling contribution
+ * @min: minimum cooling state used at this trip point
+ * @max: maximum cooling state used at this trip point
+ */
+
+struct __thermal_bind_params {
+	struct device_node *cooling_device;
+	unsigned int trip_id;
+	unsigned int usage;
+	unsigned long min;
+	unsigned long max;
+};
+
+/**
+ * struct __thermal_zone - internal representation of a thermal zone
+ * @mode: current thermal zone device mode (enabled/disabled)
+ * @passive_delay: polling interval while passive cooling is activated
+ * @polling_delay: zone polling interval
+ * @ntrips: number of trip points
+ * @trips: an array of trip points (0..ntrips - 1)
+ * @num_tbps: number of thermal bind params
+ * @tbps: an array of thermal bind params (0..num_tbps - 1)
+ * @sensor_data: sensor private data used while reading temperature and trend
+ * @get_temp: sensor callback to read temperature
+ * @get_trend: sensor callback to read temperature trend
+ */
+
+struct __thermal_zone {
+	enum thermal_device_mode mode;
+	int passive_delay;
+	int polling_delay;
+
+	/* trip data */
+	int ntrips;
+	struct __thermal_trip *trips;
+
+	/* cooling binding data */
+	int num_tbps;
+	struct __thermal_bind_params *tbps;
+
+	/* sensor interface */
+	void *sensor_data;
+	int (*get_temp)(void *, long *);
+	int (*get_trend)(void *, long *);
+};
+
+/***   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;
+
+	if (!data->get_temp)
+		return -EINVAL;
+
+	return data->get_temp(data->sensor_data, temp);
+}
+
+static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
+				enum thermal_trend *trend)
+{
+	struct __thermal_zone *data = tz->devdata;
+	long dev_trend;
+	int r;
+
+	if (!data->get_trend)
+		return -EINVAL;
+
+	r = data->get_trend(data->sensor_data, &dev_trend);
+	if (r)
+		return r;
+
+	/* TODO: These intervals might have some thresholds, but in core code */
+	if (dev_trend > 0)
+		*trend = THERMAL_TREND_RAISING;
+	else if (dev_trend < 0)
+		*trend = THERMAL_TREND_DROPPING;
+	else
+		*trend = THERMAL_TREND_STABLE;
+
+	return 0;
+}
+
+static int of_thermal_bind(struct thermal_zone_device *thermal,
+			   struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to bind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_bind_cooling_device(thermal,
+						tbp->trip_id, cdev,
+						tbp->min,
+						tbp->max);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_unbind(struct thermal_zone_device *thermal,
+			     struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to unbind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_unbind_cooling_device(thermal,
+						tbp->trip_id, cdev);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_get_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode *mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	*mode = data->mode;
+
+	return 0;
+}
+
+static int of_thermal_set_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	mutex_lock(&tz->lock);
+
+	if (mode == THERMAL_DEVICE_ENABLED)
+		tz->polling_delay = data->polling_delay;
+	else
+		tz->polling_delay = 0;
+
+	mutex_unlock(&tz->lock);
+
+	data->mode = mode;
+	thermal_zone_device_update(tz);
+
+	return 0;
+}
+
+static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
+				    enum thermal_trip_type *type)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*type = data->trips[trip].type;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*temp = data->trips[trip].temperature;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal framework should take care of data->mask & (1 << trip) */
+	data->trips[trip].temperature = temp;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long *hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*hyst = data->trips[trip].hysteresis;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal framework should take care of data->mask & (1 << trip) */
+	data->trips[trip].hysteresis = hyst;
+
+	return 0;
+}
+
+static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+	int i;
+
+	for (i = 0; i < data->ntrips; i++)
+		if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
+			*temp = data->trips[i].temperature;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+
+static struct thermal_zone_device_ops of_thermal_ops = {
+	.get_mode = of_thermal_get_mode,
+	.set_mode = of_thermal_set_mode,
+
+	.get_trip_type = of_thermal_get_trip_type,
+	.get_trip_temp = of_thermal_get_trip_temp,
+	.set_trip_temp = of_thermal_set_trip_temp,
+	.get_trip_hyst = of_thermal_get_trip_hyst,
+	.set_trip_hyst = of_thermal_set_trip_hyst,
+	.get_crit_temp = of_thermal_get_crit_temp,
+
+	.bind = of_thermal_bind,
+	.unbind = of_thermal_unbind,
+};
+
+/***   sensor API   ***/
+
+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 *))
+{
+	struct thermal_zone_device *tzd;
+	struct __thermal_zone *tz;
+
+	tzd = thermal_zone_get_zone_by_name(zone->name);
+	if (IS_ERR(tzd))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	tz = tzd->devdata;
+
+	mutex_lock(&tzd->lock);
+	tz->get_temp = get_temp;
+	tz->get_trend = get_trend;
+	tz->sensor_data = data;
+
+	tzd->ops->get_temp = of_thermal_get_temp;
+	tzd->ops->get_trend = of_thermal_get_trend;
+	mutex_unlock(&tzd->lock);
+
+	return tzd;
+}
+
+/**
+ * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *             than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *        back, when a temperature reading is needed.
+ * @get_temp: a pointer to a function that reads the sensor temperature.
+ * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ *
+ * This function will search the list of thermal zones described in device
+ * tree and look for the zone that refer to the sensor device pointed by
+ * @dev->of_node as temperature providers. For the zone pointing to the
+ * sensor node, the sensor will be added to the DT thermal zone device.
+ *
+ * The thermal zone temperature is provided by the @get_temp function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * The thermal zone temperature trend is provided by the @get_trend function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * TODO:
+ * 01 - This function must enqueue the new sensor instead of using
+ * it as the only source of temperature values.
+ *
+ * 02 - There must be a way to match the sensor with all thermal zones
+ * that refer to it.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+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 *))
+{
+	struct device_node *np, *child, *sensor_np;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np)
+		return ERR_PTR(-ENODEV);
+
+	if (!dev || !dev->of_node)
+		return ERR_PTR(-EINVAL);
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret, id;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "thermal-sensors",
+						 "#thermal-sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count >= 1) {
+			id = sensor_specs.args[0];
+			WARN(sensor_specs.args_count > 1,
+			     "%s: too many cells in sensor specifier %d\n",
+			     sensor_specs.np->name, sensor_specs.args_count);
+		} else {
+			id = 0;
+		}
+
+		if (sensor_specs.np == sensor_np && id == sensor_id) {
+			of_node_put(np);
+			return thermal_zone_of_add_sensor(child, sensor_np,
+							  data,
+							  get_temp,
+							  get_trend);
+		}
+	}
+	of_node_put(np);
+
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
+
+/**
+ * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
+ *
+ * This function removes the sensor callbacks and private data from the
+ * thermal zone device registered with thermal_zone_of_sensor_register()
+ * API. It will also silent the zone by remove the .get_temp() and .get_trend()
+ * thermal zone device callbacks.
+ *
+ * TODO: When the support to several sensors per zone is added, this
+ * function must search the sensor list based on @dev parameter.
+ *
+ */
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tzd)
+{
+	struct __thermal_zone *tz;
+
+	if (!dev || !tzd || !tzd->devdata)
+		return;
+
+	tz = tzd->devdata;
+
+	/* no __thermal_zone, nothing to be done */
+	if (!tz)
+		return;
+
+	mutex_lock(&tzd->lock);
+	tzd->ops->get_temp = NULL;
+	tzd->ops->get_trend = NULL;
+
+	tz->get_temp = NULL;
+	tz->get_trend = NULL;
+	tz->sensor_data = NULL;
+	mutex_unlock(&tzd->lock);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
+
+/***   functions parsing device tree nodes   ***/
+
+/**
+ * thermal_of_populate_bind_params - parse and fill cooling map data
+ * @np: DT node containing a cooling-map node
+ * @__tbp: data structure to be filled with cooling map info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-map type of node represented by
+ * @np parameter and fills the read data into @__tbp data structure.
+ * It needs the already parsed array of trip points of the thermal zone
+ * in consideration.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_bind_params(struct device_node *np,
+					   struct __thermal_bind_params *__tbp,
+					   struct __thermal_trip *trips,
+					   int ntrips)
+{
+	struct of_phandle_args cooling_spec;
+	struct device_node *trip;
+	int ret, i;
+	u32 prop;
+
+	/* Default weight. Usage is optional */
+	__tbp->usage = 0;
+	ret = of_property_read_u32(np, "contribution", &prop);
+	if (ret == 0)
+		__tbp->usage = prop;
+
+	trip = of_parse_phandle(np, "trip", 0);
+	if (!trip) {
+		pr_err("missing trip property\n");
+		return -ENODEV;
+	}
+
+	/* match using device_node */
+	for (i = 0; i < ntrips; i++)
+		if (trip == trips[i].np) {
+			__tbp->trip_id = i;
+			break;
+		}
+
+	if (i == ntrips) {
+		ret = -ENODEV;
+		goto end;
+	}
+
+	ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
+					 0, &cooling_spec);
+	if (ret < 0) {
+		pr_err("missing cooling_device property\n");
+		goto end;
+	}
+	__tbp->cooling_device = cooling_spec.np;
+	if (cooling_spec.args_count >= 2) { /* at least min and max */
+		__tbp->min = cooling_spec.args[0];
+		__tbp->max = cooling_spec.args[1];
+	} else {
+		pr_err("wrong reference to cooling device, missing limits\n");
+	}
+
+end:
+	of_node_put(trip);
+
+	return ret;
+}
+
+/**
+ * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
+ * into the device tree binding of 'trip', property type.
+ */
+static const char * const trip_types[] = {
+	[THERMAL_TRIP_ACTIVE]	= "active",
+	[THERMAL_TRIP_PASSIVE]	= "passive",
+	[THERMAL_TRIP_HOT]	= "hot",
+	[THERMAL_TRIP_CRITICAL]	= "critical",
+};
+
+/**
+ * thermal_of_get_trip_type - Get phy mode for given device_node
+ * @np:	Pointer to the given device_node
+ * @type: Pointer to resulting trip type
+ *
+ * The function gets trip type string from property 'type',
+ * and store its index in trip_types table in @type,
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int thermal_of_get_trip_type(struct device_node *np,
+				    enum thermal_trip_type *type)
+{
+	const char *t;
+	int err, i;
+
+	err = of_property_read_string(np, "type", &t);
+	if (err < 0)
+		return err;
+
+	for (i = 0; i < ARRAY_SIZE(trip_types); i++)
+		if (!strcasecmp(t, trip_types[i])) {
+			*type = i;
+			return 0;
+		}
+
+	return -ENODEV;
+}
+
+/**
+ * thermal_of_populate_trip - parse and fill one trip point data
+ * @np: DT node containing a trip point node
+ * @trip: trip point data structure to be filled up
+ *
+ * This function parses a trip point type of node represented by
+ * @np parameter and fills the read data into @trip data structure.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_trip(struct device_node *np,
+				    struct __thermal_trip *trip)
+{
+	int prop;
+	int ret;
+
+	ret = of_property_read_u32(np, "temperature", &prop);
+	if (ret < 0) {
+		pr_err("missing temperature property\n");
+		return ret;
+	}
+	trip->temperature = prop;
+
+	ret = of_property_read_u32(np, "hysteresis", &prop);
+	if (ret < 0) {
+		pr_err("missing hysteresis property\n");
+		return ret;
+	}
+	trip->hysteresis = prop;
+
+	ret = thermal_of_get_trip_type(np, &trip->type);
+	if (ret < 0) {
+		pr_err("wrong trip type property\n");
+		return ret;
+	}
+
+	/* Required for cooling map matching */
+	trip->np = np;
+
+	return 0;
+}
+
+/**
+ * thermal_of_build_thermal_zone - parse and fill one thermal zone data
+ * @np: DT node containing a thermal zone node
+ *
+ * This function parses a thermal zone type of node represented by
+ * @np parameter and fills the read data into a __thermal_zone data structure
+ * and return this pointer.
+ *
+ * TODO: Missing properties to parse: thermal-sensor-names and coefficients
+ *
+ * Return: On success returns a valid struct __thermal_zone,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+static struct __thermal_zone *
+thermal_of_build_thermal_zone(struct device_node *np)
+{
+	struct device_node *child = NULL, *gchild;
+	struct __thermal_zone *tz;
+	int ret, i;
+	u32 prop;
+
+	if (!np) {
+		pr_err("no thermal zone np\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
+	if (!tz)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "polling-delay-passive", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay-passive property\n");
+		goto free_tz;
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay property\n");
+		goto free_tz;
+	}
+	tz->polling_delay = prop;
+
+	/* trips */
+	child = of_get_child_by_name(np, "trips");
+
+	/* No trips provided */
+	if (!child)
+		goto finish;
+
+	tz->ntrips = of_get_child_count(child);
+	if (tz->ntrips == 0) /* must have at least one child */
+		goto finish;
+
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips) {
+		ret = -ENOMEM;
+		goto free_tz;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild) {
+		ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
+		if (ret)
+			goto free_trips;
+	}
+
+	of_node_put(child);
+
+	/* cooling-maps */
+	child = of_get_child_by_name(np, "cooling-maps");
+
+	/* cooling-maps not provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	if (tz->num_tbps == 0)
+		goto finish;
+
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps) {
+		ret = -ENOMEM;
+		goto free_trips;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						      tz->trips, tz->ntrips);
+		if (ret)
+			goto free_tbps;
+
+finish:
+	of_node_put(child);
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+
+free_tbps:
+	kfree(tz->tbps);
+free_trips:
+	kfree(tz->trips);
+free_tz:
+	kfree(tz);
+	of_node_put(child);
+
+	return ERR_PTR(ret);
+}
+
+static inline void of_thermal_free_zone(struct __thermal_zone *tz)
+{
+	kfree(tz->tbps);
+	kfree(tz->trips);
+	kfree(tz);
+}
+
+/**
+ * of_parse_thermal_zones - parse device tree thermal data
+ *
+ * Initialization function that can be called by machine initialization
+ * code to parse thermal data and populate the thermal framework
+ * with hardware thermal zones info. This function only parses thermal zones.
+ * Cooling devices and sensor devices nodes are supposed to be parsed
+ * by their respective drivers.
+ *
+ * Return: 0 on success, proper error code otherwise
+ *
+ */
+int __init of_parse_thermal_zones(void)
+{
+	struct device_node *np, *child;
+	struct __thermal_zone *tz;
+	struct thermal_zone_device_ops *ops;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_debug("unable to find thermal zones\n");
+		return 0; /* Run successfully on systems without thermal DT */
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+		struct thermal_zone_params *tzp;
+
+		tz = thermal_of_build_thermal_zone(child);
+		if (IS_ERR(tz)) {
+			pr_err("failed to build thermal zone %s: %ld\n",
+			       child->name,
+			       PTR_ERR(tz));
+			continue;
+		}
+
+		ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			goto exit_free;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp) {
+			kfree(ops);
+			goto exit_free;
+		}
+
+		/* No hwmon because there might be hwmon drivers registering */
+		tzp->no_hwmon = true;
+
+		zone = thermal_zone_device_register(child->name, tz->ntrips,
+						    0, tz,
+						    ops, tzp,
+						    tz->passive_delay,
+						    tz->polling_delay);
+		if (IS_ERR(zone)) {
+			pr_err("Failed to build %s zone %ld\n", child->name,
+			       PTR_ERR(zone));
+			kfree(tzp);
+			kfree(ops);
+			of_thermal_free_zone(tz);
+			/* attempting to build remaining zones still */
+		}
+	}
+
+	return 0;
+
+exit_free:
+	of_thermal_free_zone(tz);
+
+	/* no memory available, so free what we have built */
+	of_thermal_destroy_zones();
+
+	return -ENOMEM;
+}
+
+/**
+ * of_thermal_destroy_zones - remove all zones parsed and allocated resources
+ *
+ * Finds all zones parsed and added to the thermal framework and remove them
+ * from the system, together with their resources.
+ *
+ */
+void __exit of_thermal_destroy_zones(void)
+{
+	struct device_node *np, *child;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_err("unable to find thermal zones\n");
+		return;
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+
+		zone = thermal_zone_get_zone_by_name(child->name);
+		if (IS_ERR(zone))
+			continue;
+
+		thermal_zone_device_unregister(zone);
+		kfree(zone->tzp);
+		kfree(zone->ops);
+		of_thermal_free_zone(zone->devdata);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index f7a9f4f..fec3351 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
  */
 struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	int trips, int mask, void *devdata,
-	const struct thermal_zone_device_ops *ops,
+	struct thermal_zone_device_ops *ops,
 	const struct thermal_zone_params *tzp,
 	int passive_delay, int polling_delay)
 {
@@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
 	if (result)
 		goto unregister_class;
 
+	result = of_parse_thermal_zones();
+	if (result)
+		goto exit_netlink;
+
 	return 0;
 
+exit_netlink:
+	genetlink_exit();
 unregister_governors:
 	thermal_unregister_governors();
 unregister_class:
@@ -1768,6 +1774,7 @@ error:
 
 static void __exit thermal_exit(void)
 {
+	of_thermal_destroy_zones();
 	genetlink_exit();
 	class_unregister(&thermal_class);
 	thermal_unregister_governors();
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 7cf2f66..3db339f 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
 static inline void thermal_gov_user_space_unregister(void) {}
 #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
 
+/* device tree support */
+#ifdef CONFIG_THERMAL_OF
+int of_parse_thermal_zones(void);
+void of_thermal_destroy_zones(void);
+#else
+static inline int of_parse_thermal_zones(void) { return 0; }
+static inline void of_thermal_destroy_zones(void) { }
+#endif
+
 #endif /* __THERMAL_CORE_H__ */
diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
new file mode 100644
index 0000000..59c4581
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal.h
@@ -0,0 +1,27 @@
+/*
+ * This header provides constants for most thermal bindings.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *	Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
+#define _DT_BINDINGS_THERMAL_THERMAL_H
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE		"active"
+#define THERMAL_TRIP_PASSIVE		"passive"
+#define THERMAL_TRIP_HOT		"hot"
+#define THERMAL_TRIP_CRITICAL		"critical"
+
+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT		(-1UL)
+
+#endif
+
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b268d3c..b780c5b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -143,6 +143,7 @@ struct thermal_cooling_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
 	struct device device;
+	struct device_node *np;
 	void *devdata;
 	const struct thermal_cooling_device_ops *ops;
 	bool updated; /* true if the cooling device does not need update */
@@ -172,7 +173,7 @@ struct thermal_zone_device {
 	int emul_temperature;
 	int passive;
 	unsigned int forced_passive;
-	const struct thermal_zone_device_ops *ops;
+	struct thermal_zone_device_ops *ops;
 	const struct thermal_zone_params *tzp;
 	struct thermal_governor *governor;
 	struct list_head thermal_instances;
@@ -242,8 +243,31 @@ struct thermal_genl_event {
 };
 
 /* Function declarations */
+#ifdef CONFIG_THERMAL_OF
+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 *));
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz);
+#else
+static inline 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 *))
+{
+	return NULL;
+}
+
+static inline
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz)
+{
+}
+
+#endif
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
-		void *, const struct thermal_zone_device_ops *,
+		void *, struct thermal_zone_device_ops *,
 		const struct thermal_zone_params *, int, int);
 void thermal_zone_device_unregister(struct thermal_zone_device *);
 
-- 
1.8.2.1.342.gfa7285d


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCHv8 03/18] thermal: introduce device tree parser
@ 2013-10-01  2:39     ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-10-01  2:39 UTC (permalink / raw)
  To: swarren-3lzwWm7+Weoh9ZMKESR00Q, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, linux-0h96xk9xTtrk1uMJSBkQmQ,
	rui.zhang-ral2JQCrhuEAvxtiuMwx3w, wni-DDmLM1+adcrQT0dZR+AlfA
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eduardo Valentin

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
---
Hello Mark, folks,

So, here is v8. Pretty small changes. Most are better
English phrasing in the binding document. It follows changelog:
- Several rephrasing in the binding document, including
spelling, grammar and better phrasing.
- Removed WiP warning from binding document.
- Several spacing and formatting changes in the binding document
- Used the '-specifier' nomenclature properly in the binding doc
- Removed the optional property 'thermal-sensors-names', because
it does not provide useful runtime information
- Fixed description of 'polling-delay-passive'
- Improved examples by adding comments and better explanation
- s/fw/framework/g
- Added a WARN when sensors specifiers are greater and 1.

All best,

Eduardo

---
 .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |   9 +-
 drivers/thermal/thermal_core.h                     |   9 +
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/thermal.h                            |  28 +-
 8 files changed, 1520 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..ad06a8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,587 @@
+* Thermal Framework Device Tree descriptor
+
+This file describes a generic binding to provide a way of
+defining hardware thermal structure using device tree.
+A thermal structure includes thermal zones and their components,
+such as trip points, polling intervals, sensors and cooling devices
+binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects. The thermal device tree bindings are
+not about how the system must control or which algorithm or policy
+must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling maps: used to describe links between trip points and cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+* Thermal sensor devices
+
+Thermal sensor devices are nodes providing temperature sensing capabilities on
+thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
+nodes providing temperature data to thermal zones. Thermal sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #thermal-sensor-cells: Used to provide sensor device specific information
+  Type: unsigned	 while referring to it. Typically 0 on thermal sensor
+  Size: one cell	 nodes with only one sensor, and at least 1 on nodes
+			 with several internal sensors, in order
+			 to identify uniquely the sensor instances within
+			 the IC. See thermal zone binding for more details
+			 on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. A typical passive cooling is a CPU that has dynamic voltage and
+frequency scaling (DVFS), and uses lower frequencies as cooling states.
+Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the state of cooling in which the device is.
+
+Required properties:
+- cooling-min-state:	An integer indicating the smallest
+  Type: unsigned	cooling state accepted. Typically 0.
+  Size: one cell
+
+- cooling-max-state:	An integer indicating the largest
+  Type: unsigned	cooling state accepted.
+  Size: one cell
+
+- #cooling-cells:	Used to provide cooling device specific information
+  Type: unsigned	while referring to it. Must be at least 2, in order
+  Size: one cell      	to specify minimum and maximum cooling state used
+			in the reference. The first cell is the minimum
+			cooling state requested and the second cell is
+			the maximum cooling state requested in the reference.
+			See Cooling device maps section below for more details
+			on how consumers refer to cooling devices.
+
+* Trip points
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+Required properties:
+- temperature:		An integer indicating the trip temperature level,
+  Type: signed		in millicelsius.
+  Size: one cell
+
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+  Type: unsigned	relative value, in millicelsius.
+  Size: one cell
+
+- type:			a string containing the trip type. Supported values are:
+	"active":	A trip point to enable active cooling
+	"passive":	A trip point to enable passive cooling
+	"hot":		A trip point to notify emergency
+	"critical":	Hardware not reliable.
+  Type: string
+
+There are also string constants defined at
+include/dt-bindings/thermal/thermal.h.
+
+* Cooling device maps
+
+The cooling device maps node is a node to describe how cooling devices
+get assigned to trip points of the zone. The cooling devices are expected
+to be loaded in the target system.
+
+Required properties:
+- cooling-device:	A phandle of a cooling device with its specifier,
+  Type: phandle of	referring to which cooling device is used in this
+    cooling device	binding. In the cooling specifier, the first cell
+			is the minimum cooling state and the second cell
+			is the maximum cooling state used in this map.
+- trip:			A phandle of a trip point node within the same thermal
+  Type: phandle of	zone.
+   trip point node
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+  Type: unsigned	referred cooling device at the referred trip point.
+  Size: one cell      	The contribution is a ratio of the sum
+			of all cooling contributions within a thermal zone.
+
+Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
+limit specifier means:
+(i)   - minimum state allowed for minimum cooling state used in the reference.
+(ii)  - maximum state allowed for maximum cooling state used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zone nodes
+
+The thermal zone node is the node containing all the required info
+for describing a thermal zone, including its cooling device bindings. The
+thermal zone node must contain, apart from its own properties, one sub-node
+containing trip nodes and one sub-node containing all the zone cooling maps.
+
+Required properties:
+- polling-delay:	The maximum number of milliseconds to wait between polls
+  Type: unsigned	when checking this thermal zone.
+  Size: one cell
+
+- polling-delay-passive: The maximum number of milliseconds to wait
+  Type: unsigned	between polls when performing passive cooling.
+  Size: one cell
+
+- thermal-sensors:	A list of thermal sensor phandles and sensor specifier
+  Type: list of 	used while monitoring the thermal zone.
+  sensor phandles
+
+- trips:		A sub-node which is a container of only trip point nodes
+  Type: sub-node	required to describe the thermal zone.
+
+- cooling-maps:		A sub-node which is a container of only cooling device
+  Type: sub-node	map nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+  Type: array		coefficients to compose a linear relation between
+  Elem size: one cell	the sensors listed in the thermal-sensors property.
+  Elem type: signed	Coefficients defaults to 1, in case this property
+			is not specified. A simple linear polynomial is used:
+			Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
+
+			The coefficients are ordered and they match with sensors
+			by means of sensor ID. Additional coefficients are
+			interpreted as constant offset.
+
+Note: The delay properties are bound to the maximum dT/dt (temperature
+derivative over time) in two situations for a thermal zone:
+(i)  - when passive cooling is activated (polling-delay-passive); and
+(ii) - when the zone just needs to be monitored (polling-delay) or
+when active cooling is activated.
+
+The maximum dT/dt is highly bound to hardware power consumption and dissipation
+capability. The delays should be chosen to account for said max dT/dt,
+such that a device does not cross several trip boundaries unexpectedly
+between polls. Choosing the right polling delays shall avoid having the
+device in temperature ranges that may damage the silicon structures and
+reduce silicon lifetime.
+
+* The thermal-zones node
+
+The "thermal-zones" node is a container for all thermal zone nodes. It shall
+contain only sub-nodes describing thermal zones as in the section
+"Thermal zone nodes". The "thermal-zones" node appears under "/".
+
+* Examples
+
+Below are several examples on how to use thermal data descriptors
+using device tree bindings:
+
+(a) - CPU thermal zone
+
+The CPU thermal zone example below describes how to setup one thermal zone
+using one single sensor as temperature source and many cooling devices and
+power dissipation control sources.
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpus {
+	/*
+	 * Here is an example of describing a cooling device for a DVFS
+	 * capable CPU. The CPU node describes its four OPPs.
+	 * The cooling states possible are 0..3, and they are
+	 * used as OPP indexes. The minimum cooling state is 0, which means
+	 * all four OPPs can be available to the system. The maximum
+	 * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
+	 * can be available in the system.
+	 */
+	cpu0: cpu@0 {
+		...
+		operating-points = <
+			/* kHz    uV */
+			970000  1200000
+			792000  1100000
+			396000  950000
+			198000  850000
+		>;
+		cooling-min-state = <0>;
+		cooling-max-state = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	/*
+	 * A simple fan controller which supports 10 speeds of operation
+	 * (represented as 0-9).
+	 */
+	fan0: fan@0x48 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+ocp {
+	...
+	/*
+	 * A simple IC with a single bandgap temperature sensor.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+	        thermal-sensors = <&bandgap0>;
+
+        	trips {
+                	cpu-alert0: cpu-alert {
+                        	temperature = <90000>; /* millicelsius */
+	                        hysteresis = <2000>; /* millicelsius */
+        	                type = "active";
+	                };
+        	        cpu-alert1: cpu-alert {
+                	        temperature = <100000>; /* millicelsius */
+                        	hysteresis = <2000>; /* millicelsius */
+	                        type = "passive";
+        	        };
+                	cpu-crit: cpu-crit {
+	                        temperature = <125000>; /* millicelsius */
+        	                hysteresis = <2000>; /* millicelsius */
+                	        type = "critical";
+                	};
+        	};
+
+		cooling-maps {
+			map0 {
+				trip = <&cpu-alert0>;
+				cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+			};
+			map1 {
+				trip = <&cpu-alert1>;
+				cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+			};
+			map2 {
+				trip = <&cpu-alert1>;
+				cooling-device =
+				    <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+			};
+		};
+	};
+};
+
+In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
+used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
+device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
+different cooling states 0-9. It is used to remove the heat out of
+the thermal zone 'cpu-thermal' using its cooling states
+from its minimum to 4, when it reaches trip point 'cpu-alert0'
+at 90C, as an example of active cooling. The same cooling device is used at
+'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
+using all its cooling states at trip point 'cpu-alert1',
+which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
+temperature of 125C, represented by the trip point 'cpu-crit', the silicon
+is not reliable anymore.
+
+(b) - IC with several internal sensors
+
+The example below describes how to deploy several thermal zones based off a
+single sensor IC, assuming it has several internal sensors. This is a common
+case on SoC designs with several internal IPs that may need different thermal
+requirements, and thus may have their own sensor to monitor or detect internal
+hotspots in their silicon.
+
+#include <dt-bindings/thermal/thermal.h>
+
+ocp {
+	...
+	/*
+	 * A simple IC with several bandgap temperature sensors.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <1>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     0>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			cpu-alert: cpu-alert {
+				temperature = <100000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			cpu-crit: cpu-crit {
+				temperature = <125000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+
+	gpu-thermal: gpu-thermal {
+		polling-delay-passive = <120>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     1>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			gpu-alert: gpu-alert {
+				temperature = <90000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			gpu-crit: gpu-crit {
+				temperature = <105000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+
+	dsp-thermal: dsp-thermal {
+		polling-delay-passive = <50>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     2>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			dsp-alert: gpu-alert {
+				temperature = <90000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			dsp-crit: gpu-crit {
+				temperature = <135000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+};
+
+In the example above, there is one bandgap IC which has the capability to
+monitor three sensors. The hardware has been designed so that sensors are
+placed on different places in the DIE to monitor different temperature
+hotspots: one for CPU thermal zone, one for GPU thermal zone and the
+other to monitor a DSP thermal zone.
+
+Thus, there is a need to assign each sensor provided by the bandgap IC
+to different thermal zones. This is achieved by means of using the
+#thermal-sensor-cells property and using the first cell of the sensor
+specifier as sensor ID. In the example, then, <bandgap 0> is used to
+monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
+zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
+may be uncorrelated, having its own dT/dt requirements, trips
+and cooling maps.
+
+
+(c) - Several sensors within one single thermal zone
+
+The example below illustrates how to use more than one sensor within
+one thermal zone.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	/*
+	 * A simple IC with a single temperature sensor.
+	 */
+	adc: sensor@0x49 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+ocp {
+	...
+	/*
+	 * A simple IC with a single bandgap temperature sensor.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+		thermal-sensors = <&bandgap0>,	/* cpu */
+				  <&adc>;	/* pcb north */
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+		coefficients = 		<100	-120	484>;
+
+		trips {
+			...
+		};
+
+		cooling-maps {
+			...
+		};
+	};
+};
+
+In some cases, there is a need to use more than one sensor to extrapolate
+a thermal hotspot in the silicon. The above example illustrates this situation.
+For instance, it may be the case that a sensor external to CPU IP may be placed
+close to CPU hotspot and together with internal CPU sensor, it is used
+to determine the hotspot. Assuming this is the case for the above example,
+the hypothetical extrapolation rule would be:
+		hotspot = 100 * bandgap - 120 * adc + 484
+
+In other context, the same idea can be used to add fixed offset. For instance,
+consider the hotspot extrapolation rule below:
+		hotspot = 1 * adc + 6000
+
+In the above equation, the hotspot is always 6C higher than what is read
+from the ADC sensor. The binding would be then:
+        thermal-sensors =  <&adc>;
+
+		/* hotspot = 1 * adc + 6000 */
+	coefficients = 		<1	6000>;
+
+(d) - Board thermal
+
+The board thermal example below illustrates how to setup one thermal zone
+with many sensors and many cooling devices.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	/*
+	 * An IC with several temperature sensor.
+	 */
+	adc-dummy: sensor@0x50 {
+		...
+		#thermal-sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+thermal-zones {
+	batt-thermal {
+		polling-delay-passive = <500>; /* milliseconds */
+		polling-delay = <2500>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&adc-dummy     4>;
+
+		trips {
+			...
+		};
+
+		cooling-maps {
+			...
+		};
+	};
+
+	board-thermal: board-thermal {
+		polling-delay-passive = <1000>; /* milliseconds */
+		polling-delay = <2500>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
+				  <&adc-dummy     1>, /* lcd */
+				  <&adc-dymmy     2>; /* back cover */
+		/*
+		 * An array of coefficients describing the sensor
+		 * linear relation. E.g.:
+		 * z = c1*x1 + c2*x2 + c3*x3
+		 */
+		coefficients =		<1200	-345	890>;
+
+		trips {
+			/* Trips are based on resulting linear equation */
+			cpu-trip: cpu-trip {
+				temperature = <60000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			gpu-trip: gpu-trip {
+				temperature = <55000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			}
+			lcd-trip: lcp-trip {
+				temperature = <53000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			crit-trip: crit-trip {
+				temperature = <68000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			map0 {
+				trip = <&cpu-trip>;
+				cooling-device = <&cpu0 0 2>;
+				contribution = <55>;
+			};
+			map1 {
+				trip = <&gpu-trip>;
+				cooling-device = <&gpu0 0 2>;
+				contribution = <20>;
+			};
+			map2 {
+				trip = <&lcd-trip>;
+				cooling-device = <&lcd0 5 10>;
+				contribution = <15>;
+			};
+		};
+	};
+};
+
+The above example is a mix of previous examples, a sensor IP with several internal
+sensors used to monitor different zones, one of them is composed by several sensors and
+with different cooling devices.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dbfc390..dd81eb8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,6 +29,19 @@ config THERMAL_HWMON
 	  Say 'Y' here if you want all thermal sensors to
 	  have hwmon sysfs interface too.
 
+config THERMAL_OF
+	bool
+	prompt "APIs to parse thermal data out of device tree"
+	depends on OF
+	default y
+	help
+	  This options provides helpers to add the support to
+	  read and parse thermal data definitions out of the
+	  device tree blob.
+
+	  Say 'Y' here if you need to build thermal infrastructure
+	  based on device tree.
+
 choice
 	prompt "Default Thermal governor"
 	default THERMAL_DEFAULT_GOV_STEP_WISE
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 584b363..4b03956 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,6 +7,7 @@ thermal_sys-y			+= thermal_core.o
 
 # interface to/from other layers providing sensors
 thermal_sys-$(CONFIG_THERMAL_HWMON)		+= thermal_hwmon.o
+thermal_sys-$(CONFIG_THERMAL_OF)		+= of-thermal.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)	+= fair_share.o
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
new file mode 100644
index 0000000..66f9eb2
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,849 @@
+/*
+ *  of-thermal.c - Generic Thermal Management device tree support.
+ *
+ *  Copyright (C) 2013 Texas Instruments
+ *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
+ *
+ *
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/thermal.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/string.h>
+
+#include "thermal_core.h"
+
+/***   Private data structures to represent thermal device tree data ***/
+
+/**
+ * struct __thermal_trip - representation of a point in temperature domain
+ * @np: pointer to struct device_node that this trip point was created from
+ * @temperature: temperature value in miliCelsius
+ * @hysteresis: relative hysteresis in miliCelsius
+ * @type: trip point type
+ */
+
+struct __thermal_trip {
+	struct device_node *np;
+	unsigned long int temperature;
+	unsigned long int hysteresis;
+	enum thermal_trip_type type;
+};
+
+/**
+ * struct __thermal_bind_param - a match between trip and cooling device
+ * @cooling_device: a pointer to identify the referred cooling device
+ * @trip_id: the trip point index
+ * @usage: the percentage (from 0 to 100) of cooling contribution
+ * @min: minimum cooling state used at this trip point
+ * @max: maximum cooling state used at this trip point
+ */
+
+struct __thermal_bind_params {
+	struct device_node *cooling_device;
+	unsigned int trip_id;
+	unsigned int usage;
+	unsigned long min;
+	unsigned long max;
+};
+
+/**
+ * struct __thermal_zone - internal representation of a thermal zone
+ * @mode: current thermal zone device mode (enabled/disabled)
+ * @passive_delay: polling interval while passive cooling is activated
+ * @polling_delay: zone polling interval
+ * @ntrips: number of trip points
+ * @trips: an array of trip points (0..ntrips - 1)
+ * @num_tbps: number of thermal bind params
+ * @tbps: an array of thermal bind params (0..num_tbps - 1)
+ * @sensor_data: sensor private data used while reading temperature and trend
+ * @get_temp: sensor callback to read temperature
+ * @get_trend: sensor callback to read temperature trend
+ */
+
+struct __thermal_zone {
+	enum thermal_device_mode mode;
+	int passive_delay;
+	int polling_delay;
+
+	/* trip data */
+	int ntrips;
+	struct __thermal_trip *trips;
+
+	/* cooling binding data */
+	int num_tbps;
+	struct __thermal_bind_params *tbps;
+
+	/* sensor interface */
+	void *sensor_data;
+	int (*get_temp)(void *, long *);
+	int (*get_trend)(void *, long *);
+};
+
+/***   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;
+
+	if (!data->get_temp)
+		return -EINVAL;
+
+	return data->get_temp(data->sensor_data, temp);
+}
+
+static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
+				enum thermal_trend *trend)
+{
+	struct __thermal_zone *data = tz->devdata;
+	long dev_trend;
+	int r;
+
+	if (!data->get_trend)
+		return -EINVAL;
+
+	r = data->get_trend(data->sensor_data, &dev_trend);
+	if (r)
+		return r;
+
+	/* TODO: These intervals might have some thresholds, but in core code */
+	if (dev_trend > 0)
+		*trend = THERMAL_TREND_RAISING;
+	else if (dev_trend < 0)
+		*trend = THERMAL_TREND_DROPPING;
+	else
+		*trend = THERMAL_TREND_STABLE;
+
+	return 0;
+}
+
+static int of_thermal_bind(struct thermal_zone_device *thermal,
+			   struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to bind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_bind_cooling_device(thermal,
+						tbp->trip_id, cdev,
+						tbp->min,
+						tbp->max);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_unbind(struct thermal_zone_device *thermal,
+			     struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to unbind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device == cdev->np) {
+			int ret;
+
+			ret = thermal_zone_unbind_cooling_device(thermal,
+						tbp->trip_id, cdev);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_get_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode *mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	*mode = data->mode;
+
+	return 0;
+}
+
+static int of_thermal_set_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	mutex_lock(&tz->lock);
+
+	if (mode == THERMAL_DEVICE_ENABLED)
+		tz->polling_delay = data->polling_delay;
+	else
+		tz->polling_delay = 0;
+
+	mutex_unlock(&tz->lock);
+
+	data->mode = mode;
+	thermal_zone_device_update(tz);
+
+	return 0;
+}
+
+static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
+				    enum thermal_trip_type *type)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*type = data->trips[trip].type;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*temp = data->trips[trip].temperature;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal framework should take care of data->mask & (1 << trip) */
+	data->trips[trip].temperature = temp;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long *hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*hyst = data->trips[trip].hysteresis;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal framework should take care of data->mask & (1 << trip) */
+	data->trips[trip].hysteresis = hyst;
+
+	return 0;
+}
+
+static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+	int i;
+
+	for (i = 0; i < data->ntrips; i++)
+		if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
+			*temp = data->trips[i].temperature;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+
+static struct thermal_zone_device_ops of_thermal_ops = {
+	.get_mode = of_thermal_get_mode,
+	.set_mode = of_thermal_set_mode,
+
+	.get_trip_type = of_thermal_get_trip_type,
+	.get_trip_temp = of_thermal_get_trip_temp,
+	.set_trip_temp = of_thermal_set_trip_temp,
+	.get_trip_hyst = of_thermal_get_trip_hyst,
+	.set_trip_hyst = of_thermal_set_trip_hyst,
+	.get_crit_temp = of_thermal_get_crit_temp,
+
+	.bind = of_thermal_bind,
+	.unbind = of_thermal_unbind,
+};
+
+/***   sensor API   ***/
+
+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 *))
+{
+	struct thermal_zone_device *tzd;
+	struct __thermal_zone *tz;
+
+	tzd = thermal_zone_get_zone_by_name(zone->name);
+	if (IS_ERR(tzd))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	tz = tzd->devdata;
+
+	mutex_lock(&tzd->lock);
+	tz->get_temp = get_temp;
+	tz->get_trend = get_trend;
+	tz->sensor_data = data;
+
+	tzd->ops->get_temp = of_thermal_get_temp;
+	tzd->ops->get_trend = of_thermal_get_trend;
+	mutex_unlock(&tzd->lock);
+
+	return tzd;
+}
+
+/**
+ * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *             than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *        back, when a temperature reading is needed.
+ * @get_temp: a pointer to a function that reads the sensor temperature.
+ * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ *
+ * This function will search the list of thermal zones described in device
+ * tree and look for the zone that refer to the sensor device pointed by
+ * @dev->of_node as temperature providers. For the zone pointing to the
+ * sensor node, the sensor will be added to the DT thermal zone device.
+ *
+ * The thermal zone temperature is provided by the @get_temp function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * The thermal zone temperature trend is provided by the @get_trend function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * TODO:
+ * 01 - This function must enqueue the new sensor instead of using
+ * it as the only source of temperature values.
+ *
+ * 02 - There must be a way to match the sensor with all thermal zones
+ * that refer to it.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+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 *))
+{
+	struct device_node *np, *child, *sensor_np;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np)
+		return ERR_PTR(-ENODEV);
+
+	if (!dev || !dev->of_node)
+		return ERR_PTR(-EINVAL);
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret, id;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "thermal-sensors",
+						 "#thermal-sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count >= 1) {
+			id = sensor_specs.args[0];
+			WARN(sensor_specs.args_count > 1,
+			     "%s: too many cells in sensor specifier %d\n",
+			     sensor_specs.np->name, sensor_specs.args_count);
+		} else {
+			id = 0;
+		}
+
+		if (sensor_specs.np == sensor_np && id == sensor_id) {
+			of_node_put(np);
+			return thermal_zone_of_add_sensor(child, sensor_np,
+							  data,
+							  get_temp,
+							  get_trend);
+		}
+	}
+	of_node_put(np);
+
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
+
+/**
+ * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
+ *
+ * This function removes the sensor callbacks and private data from the
+ * thermal zone device registered with thermal_zone_of_sensor_register()
+ * API. It will also silent the zone by remove the .get_temp() and .get_trend()
+ * thermal zone device callbacks.
+ *
+ * TODO: When the support to several sensors per zone is added, this
+ * function must search the sensor list based on @dev parameter.
+ *
+ */
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tzd)
+{
+	struct __thermal_zone *tz;
+
+	if (!dev || !tzd || !tzd->devdata)
+		return;
+
+	tz = tzd->devdata;
+
+	/* no __thermal_zone, nothing to be done */
+	if (!tz)
+		return;
+
+	mutex_lock(&tzd->lock);
+	tzd->ops->get_temp = NULL;
+	tzd->ops->get_trend = NULL;
+
+	tz->get_temp = NULL;
+	tz->get_trend = NULL;
+	tz->sensor_data = NULL;
+	mutex_unlock(&tzd->lock);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
+
+/***   functions parsing device tree nodes   ***/
+
+/**
+ * thermal_of_populate_bind_params - parse and fill cooling map data
+ * @np: DT node containing a cooling-map node
+ * @__tbp: data structure to be filled with cooling map info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-map type of node represented by
+ * @np parameter and fills the read data into @__tbp data structure.
+ * It needs the already parsed array of trip points of the thermal zone
+ * in consideration.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_bind_params(struct device_node *np,
+					   struct __thermal_bind_params *__tbp,
+					   struct __thermal_trip *trips,
+					   int ntrips)
+{
+	struct of_phandle_args cooling_spec;
+	struct device_node *trip;
+	int ret, i;
+	u32 prop;
+
+	/* Default weight. Usage is optional */
+	__tbp->usage = 0;
+	ret = of_property_read_u32(np, "contribution", &prop);
+	if (ret == 0)
+		__tbp->usage = prop;
+
+	trip = of_parse_phandle(np, "trip", 0);
+	if (!trip) {
+		pr_err("missing trip property\n");
+		return -ENODEV;
+	}
+
+	/* match using device_node */
+	for (i = 0; i < ntrips; i++)
+		if (trip == trips[i].np) {
+			__tbp->trip_id = i;
+			break;
+		}
+
+	if (i == ntrips) {
+		ret = -ENODEV;
+		goto end;
+	}
+
+	ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
+					 0, &cooling_spec);
+	if (ret < 0) {
+		pr_err("missing cooling_device property\n");
+		goto end;
+	}
+	__tbp->cooling_device = cooling_spec.np;
+	if (cooling_spec.args_count >= 2) { /* at least min and max */
+		__tbp->min = cooling_spec.args[0];
+		__tbp->max = cooling_spec.args[1];
+	} else {
+		pr_err("wrong reference to cooling device, missing limits\n");
+	}
+
+end:
+	of_node_put(trip);
+
+	return ret;
+}
+
+/**
+ * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
+ * into the device tree binding of 'trip', property type.
+ */
+static const char * const trip_types[] = {
+	[THERMAL_TRIP_ACTIVE]	= "active",
+	[THERMAL_TRIP_PASSIVE]	= "passive",
+	[THERMAL_TRIP_HOT]	= "hot",
+	[THERMAL_TRIP_CRITICAL]	= "critical",
+};
+
+/**
+ * thermal_of_get_trip_type - Get phy mode for given device_node
+ * @np:	Pointer to the given device_node
+ * @type: Pointer to resulting trip type
+ *
+ * The function gets trip type string from property 'type',
+ * and store its index in trip_types table in @type,
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int thermal_of_get_trip_type(struct device_node *np,
+				    enum thermal_trip_type *type)
+{
+	const char *t;
+	int err, i;
+
+	err = of_property_read_string(np, "type", &t);
+	if (err < 0)
+		return err;
+
+	for (i = 0; i < ARRAY_SIZE(trip_types); i++)
+		if (!strcasecmp(t, trip_types[i])) {
+			*type = i;
+			return 0;
+		}
+
+	return -ENODEV;
+}
+
+/**
+ * thermal_of_populate_trip - parse and fill one trip point data
+ * @np: DT node containing a trip point node
+ * @trip: trip point data structure to be filled up
+ *
+ * This function parses a trip point type of node represented by
+ * @np parameter and fills the read data into @trip data structure.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_trip(struct device_node *np,
+				    struct __thermal_trip *trip)
+{
+	int prop;
+	int ret;
+
+	ret = of_property_read_u32(np, "temperature", &prop);
+	if (ret < 0) {
+		pr_err("missing temperature property\n");
+		return ret;
+	}
+	trip->temperature = prop;
+
+	ret = of_property_read_u32(np, "hysteresis", &prop);
+	if (ret < 0) {
+		pr_err("missing hysteresis property\n");
+		return ret;
+	}
+	trip->hysteresis = prop;
+
+	ret = thermal_of_get_trip_type(np, &trip->type);
+	if (ret < 0) {
+		pr_err("wrong trip type property\n");
+		return ret;
+	}
+
+	/* Required for cooling map matching */
+	trip->np = np;
+
+	return 0;
+}
+
+/**
+ * thermal_of_build_thermal_zone - parse and fill one thermal zone data
+ * @np: DT node containing a thermal zone node
+ *
+ * This function parses a thermal zone type of node represented by
+ * @np parameter and fills the read data into a __thermal_zone data structure
+ * and return this pointer.
+ *
+ * TODO: Missing properties to parse: thermal-sensor-names and coefficients
+ *
+ * Return: On success returns a valid struct __thermal_zone,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+static struct __thermal_zone *
+thermal_of_build_thermal_zone(struct device_node *np)
+{
+	struct device_node *child = NULL, *gchild;
+	struct __thermal_zone *tz;
+	int ret, i;
+	u32 prop;
+
+	if (!np) {
+		pr_err("no thermal zone np\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
+	if (!tz)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "polling-delay-passive", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay-passive property\n");
+		goto free_tz;
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay property\n");
+		goto free_tz;
+	}
+	tz->polling_delay = prop;
+
+	/* trips */
+	child = of_get_child_by_name(np, "trips");
+
+	/* No trips provided */
+	if (!child)
+		goto finish;
+
+	tz->ntrips = of_get_child_count(child);
+	if (tz->ntrips == 0) /* must have at least one child */
+		goto finish;
+
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips) {
+		ret = -ENOMEM;
+		goto free_tz;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild) {
+		ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
+		if (ret)
+			goto free_trips;
+	}
+
+	of_node_put(child);
+
+	/* cooling-maps */
+	child = of_get_child_by_name(np, "cooling-maps");
+
+	/* cooling-maps not provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	if (tz->num_tbps == 0)
+		goto finish;
+
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps) {
+		ret = -ENOMEM;
+		goto free_trips;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						      tz->trips, tz->ntrips);
+		if (ret)
+			goto free_tbps;
+
+finish:
+	of_node_put(child);
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+
+free_tbps:
+	kfree(tz->tbps);
+free_trips:
+	kfree(tz->trips);
+free_tz:
+	kfree(tz);
+	of_node_put(child);
+
+	return ERR_PTR(ret);
+}
+
+static inline void of_thermal_free_zone(struct __thermal_zone *tz)
+{
+	kfree(tz->tbps);
+	kfree(tz->trips);
+	kfree(tz);
+}
+
+/**
+ * of_parse_thermal_zones - parse device tree thermal data
+ *
+ * Initialization function that can be called by machine initialization
+ * code to parse thermal data and populate the thermal framework
+ * with hardware thermal zones info. This function only parses thermal zones.
+ * Cooling devices and sensor devices nodes are supposed to be parsed
+ * by their respective drivers.
+ *
+ * Return: 0 on success, proper error code otherwise
+ *
+ */
+int __init of_parse_thermal_zones(void)
+{
+	struct device_node *np, *child;
+	struct __thermal_zone *tz;
+	struct thermal_zone_device_ops *ops;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_debug("unable to find thermal zones\n");
+		return 0; /* Run successfully on systems without thermal DT */
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+		struct thermal_zone_params *tzp;
+
+		tz = thermal_of_build_thermal_zone(child);
+		if (IS_ERR(tz)) {
+			pr_err("failed to build thermal zone %s: %ld\n",
+			       child->name,
+			       PTR_ERR(tz));
+			continue;
+		}
+
+		ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			goto exit_free;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp) {
+			kfree(ops);
+			goto exit_free;
+		}
+
+		/* No hwmon because there might be hwmon drivers registering */
+		tzp->no_hwmon = true;
+
+		zone = thermal_zone_device_register(child->name, tz->ntrips,
+						    0, tz,
+						    ops, tzp,
+						    tz->passive_delay,
+						    tz->polling_delay);
+		if (IS_ERR(zone)) {
+			pr_err("Failed to build %s zone %ld\n", child->name,
+			       PTR_ERR(zone));
+			kfree(tzp);
+			kfree(ops);
+			of_thermal_free_zone(tz);
+			/* attempting to build remaining zones still */
+		}
+	}
+
+	return 0;
+
+exit_free:
+	of_thermal_free_zone(tz);
+
+	/* no memory available, so free what we have built */
+	of_thermal_destroy_zones();
+
+	return -ENOMEM;
+}
+
+/**
+ * of_thermal_destroy_zones - remove all zones parsed and allocated resources
+ *
+ * Finds all zones parsed and added to the thermal framework and remove them
+ * from the system, together with their resources.
+ *
+ */
+void __exit of_thermal_destroy_zones(void)
+{
+	struct device_node *np, *child;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_err("unable to find thermal zones\n");
+		return;
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+
+		zone = thermal_zone_get_zone_by_name(child->name);
+		if (IS_ERR(zone))
+			continue;
+
+		thermal_zone_device_unregister(zone);
+		kfree(zone->tzp);
+		kfree(zone->ops);
+		of_thermal_free_zone(zone->devdata);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index f7a9f4f..fec3351 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
  */
 struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	int trips, int mask, void *devdata,
-	const struct thermal_zone_device_ops *ops,
+	struct thermal_zone_device_ops *ops,
 	const struct thermal_zone_params *tzp,
 	int passive_delay, int polling_delay)
 {
@@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
 	if (result)
 		goto unregister_class;
 
+	result = of_parse_thermal_zones();
+	if (result)
+		goto exit_netlink;
+
 	return 0;
 
+exit_netlink:
+	genetlink_exit();
 unregister_governors:
 	thermal_unregister_governors();
 unregister_class:
@@ -1768,6 +1774,7 @@ error:
 
 static void __exit thermal_exit(void)
 {
+	of_thermal_destroy_zones();
 	genetlink_exit();
 	class_unregister(&thermal_class);
 	thermal_unregister_governors();
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 7cf2f66..3db339f 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
 static inline void thermal_gov_user_space_unregister(void) {}
 #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
 
+/* device tree support */
+#ifdef CONFIG_THERMAL_OF
+int of_parse_thermal_zones(void);
+void of_thermal_destroy_zones(void);
+#else
+static inline int of_parse_thermal_zones(void) { return 0; }
+static inline void of_thermal_destroy_zones(void) { }
+#endif
+
 #endif /* __THERMAL_CORE_H__ */
diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
new file mode 100644
index 0000000..59c4581
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal.h
@@ -0,0 +1,27 @@
+/*
+ * This header provides constants for most thermal bindings.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *	Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
+ *
+ * GPLv2 only
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
+#define _DT_BINDINGS_THERMAL_THERMAL_H
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE		"active"
+#define THERMAL_TRIP_PASSIVE		"passive"
+#define THERMAL_TRIP_HOT		"hot"
+#define THERMAL_TRIP_CRITICAL		"critical"
+
+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT		(-1UL)
+
+#endif
+
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b268d3c..b780c5b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -143,6 +143,7 @@ struct thermal_cooling_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
 	struct device device;
+	struct device_node *np;
 	void *devdata;
 	const struct thermal_cooling_device_ops *ops;
 	bool updated; /* true if the cooling device does not need update */
@@ -172,7 +173,7 @@ struct thermal_zone_device {
 	int emul_temperature;
 	int passive;
 	unsigned int forced_passive;
-	const struct thermal_zone_device_ops *ops;
+	struct thermal_zone_device_ops *ops;
 	const struct thermal_zone_params *tzp;
 	struct thermal_governor *governor;
 	struct list_head thermal_instances;
@@ -242,8 +243,31 @@ struct thermal_genl_event {
 };
 
 /* Function declarations */
+#ifdef CONFIG_THERMAL_OF
+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 *));
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz);
+#else
+static inline 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 *))
+{
+	return NULL;
+}
+
+static inline
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz)
+{
+}
+
+#endif
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
-		void *, const struct thermal_zone_device_ops *,
+		void *, struct thermal_zone_device_ops *,
 		const struct thermal_zone_params *, int, int);
 void thermal_zone_device_unregister(struct thermal_zone_device *);
 
-- 
1.8.2.1.342.gfa7285d

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [lm-sensors] [PATCHv8 03/18] thermal: introduce device tree parser
@ 2013-10-01  2:39     ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-10-01  2:39 UTC (permalink / raw)
  To: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
	linux, rui.zhang, wni
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel, Eduardo Valentin

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
Hello Mark, folks,

So, here is v8. Pretty small changes. Most are better
English phrasing in the binding document. It follows changelog:
- Several rephrasing in the binding document, including
spelling, grammar and better phrasing.
- Removed WiP warning from binding document.
- Several spacing and formatting changes in the binding document
- Used the '-specifier' nomenclature properly in the binding doc
- Removed the optional property 'thermal-sensors-names', because
it does not provide useful runtime information
- Fixed description of 'polling-delay-passive'
- Improved examples by adding comments and better explanation
- s/fw/framework/g
- Added a WARN when sensors specifiers are greater and 1.

All best,

Eduardo

---
 .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |   9 +-
 drivers/thermal/thermal_core.h                     |   9 +
 include/dt-bindings/thermal/thermal.h              |  27 +
 include/linux/thermal.h                            |  28 +-
 8 files changed, 1520 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..ad06a8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,587 @@
+* Thermal Framework Device Tree descriptor
+
+This file describes a generic binding to provide a way of
+defining hardware thermal structure using device tree.
+A thermal structure includes thermal zones and their components,
+such as trip points, polling intervals, sensors and cooling devices
+binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects. The thermal device tree bindings are
+not about how the system must control or which algorithm or policy
+must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling maps: used to describe links between trip points and cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+* Thermal sensor devices
+
+Thermal sensor devices are nodes providing temperature sensing capabilities on
+thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
+nodes providing temperature data to thermal zones. Thermal sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #thermal-sensor-cells: Used to provide sensor device specific information
+  Type: unsigned	 while referring to it. Typically 0 on thermal sensor
+  Size: one cell	 nodes with only one sensor, and at least 1 on nodes
+			 with several internal sensors, in order
+			 to identify uniquely the sensor instances within
+			 the IC. See thermal zone binding for more details
+			 on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. A typical passive cooling is a CPU that has dynamic voltage and
+frequency scaling (DVFS), and uses lower frequencies as cooling states.
+Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the state of cooling in which the device is.
+
+Required properties:
+- cooling-min-state:	An integer indicating the smallest
+  Type: unsigned	cooling state accepted. Typically 0.
+  Size: one cell
+
+- cooling-max-state:	An integer indicating the largest
+  Type: unsigned	cooling state accepted.
+  Size: one cell
+
+- #cooling-cells:	Used to provide cooling device specific information
+  Type: unsigned	while referring to it. Must be at least 2, in order
+  Size: one cell      	to specify minimum and maximum cooling state used
+			in the reference. The first cell is the minimum
+			cooling state requested and the second cell is
+			the maximum cooling state requested in the reference.
+			See Cooling device maps section below for more details
+			on how consumers refer to cooling devices.
+
+* Trip points
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+Required properties:
+- temperature:		An integer indicating the trip temperature level,
+  Type: signed		in millicelsius.
+  Size: one cell
+
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+  Type: unsigned	relative value, in millicelsius.
+  Size: one cell
+
+- type:			a string containing the trip type. Supported values are:
+	"active":	A trip point to enable active cooling
+	"passive":	A trip point to enable passive cooling
+	"hot":		A trip point to notify emergency
+	"critical":	Hardware not reliable.
+  Type: string
+
+There are also string constants defined at
+include/dt-bindings/thermal/thermal.h.
+
+* Cooling device maps
+
+The cooling device maps node is a node to describe how cooling devices
+get assigned to trip points of the zone. The cooling devices are expected
+to be loaded in the target system.
+
+Required properties:
+- cooling-device:	A phandle of a cooling device with its specifier,
+  Type: phandle of	referring to which cooling device is used in this
+    cooling device	binding. In the cooling specifier, the first cell
+			is the minimum cooling state and the second cell
+			is the maximum cooling state used in this map.
+- trip:			A phandle of a trip point node within the same thermal
+  Type: phandle of	zone.
+   trip point node
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+  Type: unsigned	referred cooling device at the referred trip point.
+  Size: one cell      	The contribution is a ratio of the sum
+			of all cooling contributions within a thermal zone.
+
+Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
+limit specifier means:
+(i)   - minimum state allowed for minimum cooling state used in the reference.
+(ii)  - maximum state allowed for maximum cooling state used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zone nodes
+
+The thermal zone node is the node containing all the required info
+for describing a thermal zone, including its cooling device bindings. The
+thermal zone node must contain, apart from its own properties, one sub-node
+containing trip nodes and one sub-node containing all the zone cooling maps.
+
+Required properties:
+- polling-delay:	The maximum number of milliseconds to wait between polls
+  Type: unsigned	when checking this thermal zone.
+  Size: one cell
+
+- polling-delay-passive: The maximum number of milliseconds to wait
+  Type: unsigned	between polls when performing passive cooling.
+  Size: one cell
+
+- thermal-sensors:	A list of thermal sensor phandles and sensor specifier
+  Type: list of 	used while monitoring the thermal zone.
+  sensor phandles
+
+- trips:		A sub-node which is a container of only trip point nodes
+  Type: sub-node	required to describe the thermal zone.
+
+- cooling-maps:		A sub-node which is a container of only cooling device
+  Type: sub-node	map nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+  Type: array		coefficients to compose a linear relation between
+  Elem size: one cell	the sensors listed in the thermal-sensors property.
+  Elem type: signed	Coefficients defaults to 1, in case this property
+			is not specified. A simple linear polynomial is used:
+			Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
+
+			The coefficients are ordered and they match with sensors
+			by means of sensor ID. Additional coefficients are
+			interpreted as constant offset.
+
+Note: The delay properties are bound to the maximum dT/dt (temperature
+derivative over time) in two situations for a thermal zone:
+(i)  - when passive cooling is activated (polling-delay-passive); and
+(ii) - when the zone just needs to be monitored (polling-delay) or
+when active cooling is activated.
+
+The maximum dT/dt is highly bound to hardware power consumption and dissipation
+capability. The delays should be chosen to account for said max dT/dt,
+such that a device does not cross several trip boundaries unexpectedly
+between polls. Choosing the right polling delays shall avoid having the
+device in temperature ranges that may damage the silicon structures and
+reduce silicon lifetime.
+
+* The thermal-zones node
+
+The "thermal-zones" node is a container for all thermal zone nodes. It shall
+contain only sub-nodes describing thermal zones as in the section
+"Thermal zone nodes". The "thermal-zones" node appears under "/".
+
+* Examples
+
+Below are several examples on how to use thermal data descriptors
+using device tree bindings:
+
+(a) - CPU thermal zone
+
+The CPU thermal zone example below describes how to setup one thermal zone
+using one single sensor as temperature source and many cooling devices and
+power dissipation control sources.
+
+#include <dt-bindings/thermal/thermal.h>
+
+cpus {
+	/*
+	 * Here is an example of describing a cooling device for a DVFS
+	 * capable CPU. The CPU node describes its four OPPs.
+	 * The cooling states possible are 0..3, and they are
+	 * used as OPP indexes. The minimum cooling state is 0, which means
+	 * all four OPPs can be available to the system. The maximum
+	 * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
+	 * can be available in the system.
+	 */
+	cpu0: cpu@0 {
+		...
+		operating-points = <
+			/* kHz    uV */
+			970000  1200000
+			792000  1100000
+			396000  950000
+			198000  850000
+		>;
+		cooling-min-state = <0>;
+		cooling-max-state = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	/*
+	 * A simple fan controller which supports 10 speeds of operation
+	 * (represented as 0-9).
+	 */
+	fan0: fan@0x48 {
+		...
+		cooling-min-state = <0>;
+		cooling-max-state = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+ocp {
+	...
+	/*
+	 * A simple IC with a single bandgap temperature sensor.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+	        thermal-sensors = <&bandgap0>;
+
+        	trips {
+                	cpu-alert0: cpu-alert {
+                        	temperature = <90000>; /* millicelsius */
+	                        hysteresis = <2000>; /* millicelsius */
+        	                type = "active";
+	                };
+        	        cpu-alert1: cpu-alert {
+                	        temperature = <100000>; /* millicelsius */
+                        	hysteresis = <2000>; /* millicelsius */
+	                        type = "passive";
+        	        };
+                	cpu-crit: cpu-crit {
+	                        temperature = <125000>; /* millicelsius */
+        	                hysteresis = <2000>; /* millicelsius */
+                	        type = "critical";
+                	};
+        	};
+
+		cooling-maps {
+			map0 {
+				trip = <&cpu-alert0>;
+				cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+			};
+			map1 {
+				trip = <&cpu-alert1>;
+				cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+			};
+			map2 {
+				trip = <&cpu-alert1>;
+				cooling-device +				    <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+			};
+		};
+	};
+};
+
+In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
+used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
+device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
+different cooling states 0-9. It is used to remove the heat out of
+the thermal zone 'cpu-thermal' using its cooling states
+from its minimum to 4, when it reaches trip point 'cpu-alert0'
+at 90C, as an example of active cooling. The same cooling device is used at
+'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
+using all its cooling states at trip point 'cpu-alert1',
+which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
+temperature of 125C, represented by the trip point 'cpu-crit', the silicon
+is not reliable anymore.
+
+(b) - IC with several internal sensors
+
+The example below describes how to deploy several thermal zones based off a
+single sensor IC, assuming it has several internal sensors. This is a common
+case on SoC designs with several internal IPs that may need different thermal
+requirements, and thus may have their own sensor to monitor or detect internal
+hotspots in their silicon.
+
+#include <dt-bindings/thermal/thermal.h>
+
+ocp {
+	...
+	/*
+	 * A simple IC with several bandgap temperature sensors.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <1>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     0>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			cpu-alert: cpu-alert {
+				temperature = <100000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			cpu-crit: cpu-crit {
+				temperature = <125000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+
+	gpu-thermal: gpu-thermal {
+		polling-delay-passive = <120>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     1>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			gpu-alert: gpu-alert {
+				temperature = <90000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			gpu-crit: gpu-crit {
+				temperature = <105000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+
+	dsp-thermal: dsp-thermal {
+		polling-delay-passive = <50>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&bandgap0     2>;
+
+		trips {
+			/* each zone within the SoC may have its own trips */
+			dsp-alert: gpu-alert {
+				temperature = <90000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			dsp-crit: gpu-crit {
+				temperature = <135000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			/* each zone within the SoC may have its own cooling */
+			...
+		};
+	};
+};
+
+In the example above, there is one bandgap IC which has the capability to
+monitor three sensors. The hardware has been designed so that sensors are
+placed on different places in the DIE to monitor different temperature
+hotspots: one for CPU thermal zone, one for GPU thermal zone and the
+other to monitor a DSP thermal zone.
+
+Thus, there is a need to assign each sensor provided by the bandgap IC
+to different thermal zones. This is achieved by means of using the
+#thermal-sensor-cells property and using the first cell of the sensor
+specifier as sensor ID. In the example, then, <bandgap 0> is used to
+monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
+zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
+may be uncorrelated, having its own dT/dt requirements, trips
+and cooling maps.
+
+
+(c) - Several sensors within one single thermal zone
+
+The example below illustrates how to use more than one sensor within
+one thermal zone.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	/*
+	 * A simple IC with a single temperature sensor.
+	 */
+	adc: sensor@0x49 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+ocp {
+	...
+	/*
+	 * A simple IC with a single bandgap temperature sensor.
+	 */
+	bandgap0: bandgap@0x0000ED00 {
+		...
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+thermal-zones {
+	cpu-thermal: cpu-thermal {
+		polling-delay-passive = <250>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+
+		thermal-sensors = <&bandgap0>,	/* cpu */
+				  <&adc>;	/* pcb north */
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+		coefficients = 		<100	-120	484>;
+
+		trips {
+			...
+		};
+
+		cooling-maps {
+			...
+		};
+	};
+};
+
+In some cases, there is a need to use more than one sensor to extrapolate
+a thermal hotspot in the silicon. The above example illustrates this situation.
+For instance, it may be the case that a sensor external to CPU IP may be placed
+close to CPU hotspot and together with internal CPU sensor, it is used
+to determine the hotspot. Assuming this is the case for the above example,
+the hypothetical extrapolation rule would be:
+		hotspot = 100 * bandgap - 120 * adc + 484
+
+In other context, the same idea can be used to add fixed offset. For instance,
+consider the hotspot extrapolation rule below:
+		hotspot = 1 * adc + 6000
+
+In the above equation, the hotspot is always 6C higher than what is read
+from the ADC sensor. The binding would be then:
+        thermal-sensors =  <&adc>;
+
+		/* hotspot = 1 * adc + 6000 */
+	coefficients = 		<1	6000>;
+
+(d) - Board thermal
+
+The board thermal example below illustrates how to setup one thermal zone
+with many sensors and many cooling devices.
+
+#include <dt-bindings/thermal/thermal.h>
+
+&i2c1 {
+	...
+	/*
+	 * An IC with several temperature sensor.
+	 */
+	adc-dummy: sensor@0x50 {
+		...
+		#thermal-sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+thermal-zones {
+	batt-thermal {
+		polling-delay-passive = <500>; /* milliseconds */
+		polling-delay = <2500>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&adc-dummy     4>;
+
+		trips {
+			...
+		};
+
+		cooling-maps {
+			...
+		};
+	};
+
+	board-thermal: board-thermal {
+		polling-delay-passive = <1000>; /* milliseconds */
+		polling-delay = <2500>; /* milliseconds */
+
+				/* sensor       ID */
+		thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
+				  <&adc-dummy     1>, /* lcd */
+				  <&adc-dymmy     2>; /* back cover */
+		/*
+		 * An array of coefficients describing the sensor
+		 * linear relation. E.g.:
+		 * z = c1*x1 + c2*x2 + c3*x3
+		 */
+		coefficients =		<1200	-345	890>;
+
+		trips {
+			/* Trips are based on resulting linear equation */
+			cpu-trip: cpu-trip {
+				temperature = <60000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			gpu-trip: gpu-trip {
+				temperature = <55000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			}
+			lcd-trip: lcp-trip {
+				temperature = <53000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "passive";
+			};
+			crit-trip: crit-trip {
+				temperature = <68000>; /* millicelsius */
+				hysteresis = <2000>; /* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			map0 {
+				trip = <&cpu-trip>;
+				cooling-device = <&cpu0 0 2>;
+				contribution = <55>;
+			};
+			map1 {
+				trip = <&gpu-trip>;
+				cooling-device = <&gpu0 0 2>;
+				contribution = <20>;
+			};
+			map2 {
+				trip = <&lcd-trip>;
+				cooling-device = <&lcd0 5 10>;
+				contribution = <15>;
+			};
+		};
+	};
+};
+
+The above example is a mix of previous examples, a sensor IP with several internal
+sensors used to monitor different zones, one of them is composed by several sensors and
+with different cooling devices.
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dbfc390..dd81eb8 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,6 +29,19 @@ config THERMAL_HWMON
 	  Say 'Y' here if you want all thermal sensors to
 	  have hwmon sysfs interface too.
 
+config THERMAL_OF
+	bool
+	prompt "APIs to parse thermal data out of device tree"
+	depends on OF
+	default y
+	help
+	  This options provides helpers to add the support to
+	  read and parse thermal data definitions out of the
+	  device tree blob.
+
+	  Say 'Y' here if you need to build thermal infrastructure
+	  based on device tree.
+
 choice
 	prompt "Default Thermal governor"
 	default THERMAL_DEFAULT_GOV_STEP_WISE
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 584b363..4b03956 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,6 +7,7 @@ thermal_sys-y			+= thermal_core.o
 
 # interface to/from other layers providing sensors
 thermal_sys-$(CONFIG_THERMAL_HWMON)		+= thermal_hwmon.o
+thermal_sys-$(CONFIG_THERMAL_OF)		+= of-thermal.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)	+= fair_share.o
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
new file mode 100644
index 0000000..66f9eb2
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,849 @@
+/*
+ *  of-thermal.c - Generic Thermal Management device tree support.
+ *
+ *  Copyright (C) 2013 Texas Instruments
+ *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ *
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/thermal.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/string.h>
+
+#include "thermal_core.h"
+
+/***   Private data structures to represent thermal device tree data ***/
+
+/**
+ * struct __thermal_trip - representation of a point in temperature domain
+ * @np: pointer to struct device_node that this trip point was created from
+ * @temperature: temperature value in miliCelsius
+ * @hysteresis: relative hysteresis in miliCelsius
+ * @type: trip point type
+ */
+
+struct __thermal_trip {
+	struct device_node *np;
+	unsigned long int temperature;
+	unsigned long int hysteresis;
+	enum thermal_trip_type type;
+};
+
+/**
+ * struct __thermal_bind_param - a match between trip and cooling device
+ * @cooling_device: a pointer to identify the referred cooling device
+ * @trip_id: the trip point index
+ * @usage: the percentage (from 0 to 100) of cooling contribution
+ * @min: minimum cooling state used at this trip point
+ * @max: maximum cooling state used at this trip point
+ */
+
+struct __thermal_bind_params {
+	struct device_node *cooling_device;
+	unsigned int trip_id;
+	unsigned int usage;
+	unsigned long min;
+	unsigned long max;
+};
+
+/**
+ * struct __thermal_zone - internal representation of a thermal zone
+ * @mode: current thermal zone device mode (enabled/disabled)
+ * @passive_delay: polling interval while passive cooling is activated
+ * @polling_delay: zone polling interval
+ * @ntrips: number of trip points
+ * @trips: an array of trip points (0..ntrips - 1)
+ * @num_tbps: number of thermal bind params
+ * @tbps: an array of thermal bind params (0..num_tbps - 1)
+ * @sensor_data: sensor private data used while reading temperature and trend
+ * @get_temp: sensor callback to read temperature
+ * @get_trend: sensor callback to read temperature trend
+ */
+
+struct __thermal_zone {
+	enum thermal_device_mode mode;
+	int passive_delay;
+	int polling_delay;
+
+	/* trip data */
+	int ntrips;
+	struct __thermal_trip *trips;
+
+	/* cooling binding data */
+	int num_tbps;
+	struct __thermal_bind_params *tbps;
+
+	/* sensor interface */
+	void *sensor_data;
+	int (*get_temp)(void *, long *);
+	int (*get_trend)(void *, long *);
+};
+
+/***   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;
+
+	if (!data->get_temp)
+		return -EINVAL;
+
+	return data->get_temp(data->sensor_data, temp);
+}
+
+static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
+				enum thermal_trend *trend)
+{
+	struct __thermal_zone *data = tz->devdata;
+	long dev_trend;
+	int r;
+
+	if (!data->get_trend)
+		return -EINVAL;
+
+	r = data->get_trend(data->sensor_data, &dev_trend);
+	if (r)
+		return r;
+
+	/* TODO: These intervals might have some thresholds, but in core code */
+	if (dev_trend > 0)
+		*trend = THERMAL_TREND_RAISING;
+	else if (dev_trend < 0)
+		*trend = THERMAL_TREND_DROPPING;
+	else
+		*trend = THERMAL_TREND_STABLE;
+
+	return 0;
+}
+
+static int of_thermal_bind(struct thermal_zone_device *thermal,
+			   struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to bind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device = cdev->np) {
+			int ret;
+
+			ret = thermal_zone_bind_cooling_device(thermal,
+						tbp->trip_id, cdev,
+						tbp->min,
+						tbp->max);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_unbind(struct thermal_zone_device *thermal,
+			     struct thermal_cooling_device *cdev)
+{
+	struct __thermal_zone *data = thermal->devdata;
+	int i;
+
+	if (!data || IS_ERR(data))
+		return -ENODEV;
+
+	/* find where to unbind */
+	for (i = 0; i < data->num_tbps; i++) {
+		struct __thermal_bind_params *tbp = data->tbps + i;
+
+		if (tbp->cooling_device = cdev->np) {
+			int ret;
+
+			ret = thermal_zone_unbind_cooling_device(thermal,
+						tbp->trip_id, cdev);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int of_thermal_get_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode *mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	*mode = data->mode;
+
+	return 0;
+}
+
+static int of_thermal_set_mode(struct thermal_zone_device *tz,
+			       enum thermal_device_mode mode)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	mutex_lock(&tz->lock);
+
+	if (mode = THERMAL_DEVICE_ENABLED)
+		tz->polling_delay = data->polling_delay;
+	else
+		tz->polling_delay = 0;
+
+	mutex_unlock(&tz->lock);
+
+	data->mode = mode;
+	thermal_zone_device_update(tz);
+
+	return 0;
+}
+
+static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
+				    enum thermal_trip_type *type)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*type = data->trips[trip].type;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*temp = data->trips[trip].temperature;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
+				    unsigned long temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal framework should take care of data->mask & (1 << trip) */
+	data->trips[trip].temperature = temp;
+
+	return 0;
+}
+
+static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long *hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	*hyst = data->trips[trip].hysteresis;
+
+	return 0;
+}
+
+static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
+				    unsigned long hyst)
+{
+	struct __thermal_zone *data = tz->devdata;
+
+	if (trip >= data->ntrips || trip < 0)
+		return -EDOM;
+
+	/* thermal framework should take care of data->mask & (1 << trip) */
+	data->trips[trip].hysteresis = hyst;
+
+	return 0;
+}
+
+static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
+				    unsigned long *temp)
+{
+	struct __thermal_zone *data = tz->devdata;
+	int i;
+
+	for (i = 0; i < data->ntrips; i++)
+		if (data->trips[i].type = THERMAL_TRIP_CRITICAL) {
+			*temp = data->trips[i].temperature;
+			return 0;
+		}
+
+	return -EINVAL;
+}
+
+static struct thermal_zone_device_ops of_thermal_ops = {
+	.get_mode = of_thermal_get_mode,
+	.set_mode = of_thermal_set_mode,
+
+	.get_trip_type = of_thermal_get_trip_type,
+	.get_trip_temp = of_thermal_get_trip_temp,
+	.set_trip_temp = of_thermal_set_trip_temp,
+	.get_trip_hyst = of_thermal_get_trip_hyst,
+	.set_trip_hyst = of_thermal_set_trip_hyst,
+	.get_crit_temp = of_thermal_get_crit_temp,
+
+	.bind = of_thermal_bind,
+	.unbind = of_thermal_unbind,
+};
+
+/***   sensor API   ***/
+
+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 *))
+{
+	struct thermal_zone_device *tzd;
+	struct __thermal_zone *tz;
+
+	tzd = thermal_zone_get_zone_by_name(zone->name);
+	if (IS_ERR(tzd))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	tz = tzd->devdata;
+
+	mutex_lock(&tzd->lock);
+	tz->get_temp = get_temp;
+	tz->get_trend = get_trend;
+	tz->sensor_data = data;
+
+	tzd->ops->get_temp = of_thermal_get_temp;
+	tzd->ops->get_trend = of_thermal_get_trend;
+	mutex_unlock(&tzd->lock);
+
+	return tzd;
+}
+
+/**
+ * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *             than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *        back, when a temperature reading is needed.
+ * @get_temp: a pointer to a function that reads the sensor temperature.
+ * @get_trend: a pointer to a function that reads the sensor temperature trend.
+ *
+ * This function will search the list of thermal zones described in device
+ * tree and look for the zone that refer to the sensor device pointed by
+ * @dev->of_node as temperature providers. For the zone pointing to the
+ * sensor node, the sensor will be added to the DT thermal zone device.
+ *
+ * The thermal zone temperature is provided by the @get_temp function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * The thermal zone temperature trend is provided by the @get_trend function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * TODO:
+ * 01 - This function must enqueue the new sensor instead of using
+ * it as the only source of temperature values.
+ *
+ * 02 - There must be a way to match the sensor with all thermal zones
+ * that refer to it.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+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 *))
+{
+	struct device_node *np, *child, *sensor_np;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np)
+		return ERR_PTR(-ENODEV);
+
+	if (!dev || !dev->of_node)
+		return ERR_PTR(-EINVAL);
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret, id;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "thermal-sensors",
+						 "#thermal-sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count >= 1) {
+			id = sensor_specs.args[0];
+			WARN(sensor_specs.args_count > 1,
+			     "%s: too many cells in sensor specifier %d\n",
+			     sensor_specs.np->name, sensor_specs.args_count);
+		} else {
+			id = 0;
+		}
+
+		if (sensor_specs.np = sensor_np && id = sensor_id) {
+			of_node_put(np);
+			return thermal_zone_of_add_sensor(child, sensor_np,
+							  data,
+							  get_temp,
+							  get_trend);
+		}
+	}
+	of_node_put(np);
+
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
+
+/**
+ * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
+ *
+ * This function removes the sensor callbacks and private data from the
+ * thermal zone device registered with thermal_zone_of_sensor_register()
+ * API. It will also silent the zone by remove the .get_temp() and .get_trend()
+ * thermal zone device callbacks.
+ *
+ * TODO: When the support to several sensors per zone is added, this
+ * function must search the sensor list based on @dev parameter.
+ *
+ */
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tzd)
+{
+	struct __thermal_zone *tz;
+
+	if (!dev || !tzd || !tzd->devdata)
+		return;
+
+	tz = tzd->devdata;
+
+	/* no __thermal_zone, nothing to be done */
+	if (!tz)
+		return;
+
+	mutex_lock(&tzd->lock);
+	tzd->ops->get_temp = NULL;
+	tzd->ops->get_trend = NULL;
+
+	tz->get_temp = NULL;
+	tz->get_trend = NULL;
+	tz->sensor_data = NULL;
+	mutex_unlock(&tzd->lock);
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
+
+/***   functions parsing device tree nodes   ***/
+
+/**
+ * thermal_of_populate_bind_params - parse and fill cooling map data
+ * @np: DT node containing a cooling-map node
+ * @__tbp: data structure to be filled with cooling map info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-map type of node represented by
+ * @np parameter and fills the read data into @__tbp data structure.
+ * It needs the already parsed array of trip points of the thermal zone
+ * in consideration.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_bind_params(struct device_node *np,
+					   struct __thermal_bind_params *__tbp,
+					   struct __thermal_trip *trips,
+					   int ntrips)
+{
+	struct of_phandle_args cooling_spec;
+	struct device_node *trip;
+	int ret, i;
+	u32 prop;
+
+	/* Default weight. Usage is optional */
+	__tbp->usage = 0;
+	ret = of_property_read_u32(np, "contribution", &prop);
+	if (ret = 0)
+		__tbp->usage = prop;
+
+	trip = of_parse_phandle(np, "trip", 0);
+	if (!trip) {
+		pr_err("missing trip property\n");
+		return -ENODEV;
+	}
+
+	/* match using device_node */
+	for (i = 0; i < ntrips; i++)
+		if (trip = trips[i].np) {
+			__tbp->trip_id = i;
+			break;
+		}
+
+	if (i = ntrips) {
+		ret = -ENODEV;
+		goto end;
+	}
+
+	ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
+					 0, &cooling_spec);
+	if (ret < 0) {
+		pr_err("missing cooling_device property\n");
+		goto end;
+	}
+	__tbp->cooling_device = cooling_spec.np;
+	if (cooling_spec.args_count >= 2) { /* at least min and max */
+		__tbp->min = cooling_spec.args[0];
+		__tbp->max = cooling_spec.args[1];
+	} else {
+		pr_err("wrong reference to cooling device, missing limits\n");
+	}
+
+end:
+	of_node_put(trip);
+
+	return ret;
+}
+
+/**
+ * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
+ * into the device tree binding of 'trip', property type.
+ */
+static const char * const trip_types[] = {
+	[THERMAL_TRIP_ACTIVE]	= "active",
+	[THERMAL_TRIP_PASSIVE]	= "passive",
+	[THERMAL_TRIP_HOT]	= "hot",
+	[THERMAL_TRIP_CRITICAL]	= "critical",
+};
+
+/**
+ * thermal_of_get_trip_type - Get phy mode for given device_node
+ * @np:	Pointer to the given device_node
+ * @type: Pointer to resulting trip type
+ *
+ * The function gets trip type string from property 'type',
+ * and store its index in trip_types table in @type,
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int thermal_of_get_trip_type(struct device_node *np,
+				    enum thermal_trip_type *type)
+{
+	const char *t;
+	int err, i;
+
+	err = of_property_read_string(np, "type", &t);
+	if (err < 0)
+		return err;
+
+	for (i = 0; i < ARRAY_SIZE(trip_types); i++)
+		if (!strcasecmp(t, trip_types[i])) {
+			*type = i;
+			return 0;
+		}
+
+	return -ENODEV;
+}
+
+/**
+ * thermal_of_populate_trip - parse and fill one trip point data
+ * @np: DT node containing a trip point node
+ * @trip: trip point data structure to be filled up
+ *
+ * This function parses a trip point type of node represented by
+ * @np parameter and fills the read data into @trip data structure.
+ *
+ * Return: 0 on success, proper error code otherwise
+ */
+static int thermal_of_populate_trip(struct device_node *np,
+				    struct __thermal_trip *trip)
+{
+	int prop;
+	int ret;
+
+	ret = of_property_read_u32(np, "temperature", &prop);
+	if (ret < 0) {
+		pr_err("missing temperature property\n");
+		return ret;
+	}
+	trip->temperature = prop;
+
+	ret = of_property_read_u32(np, "hysteresis", &prop);
+	if (ret < 0) {
+		pr_err("missing hysteresis property\n");
+		return ret;
+	}
+	trip->hysteresis = prop;
+
+	ret = thermal_of_get_trip_type(np, &trip->type);
+	if (ret < 0) {
+		pr_err("wrong trip type property\n");
+		return ret;
+	}
+
+	/* Required for cooling map matching */
+	trip->np = np;
+
+	return 0;
+}
+
+/**
+ * thermal_of_build_thermal_zone - parse and fill one thermal zone data
+ * @np: DT node containing a thermal zone node
+ *
+ * This function parses a thermal zone type of node represented by
+ * @np parameter and fills the read data into a __thermal_zone data structure
+ * and return this pointer.
+ *
+ * TODO: Missing properties to parse: thermal-sensor-names and coefficients
+ *
+ * Return: On success returns a valid struct __thermal_zone,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+static struct __thermal_zone *
+thermal_of_build_thermal_zone(struct device_node *np)
+{
+	struct device_node *child = NULL, *gchild;
+	struct __thermal_zone *tz;
+	int ret, i;
+	u32 prop;
+
+	if (!np) {
+		pr_err("no thermal zone np\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
+	if (!tz)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "polling-delay-passive", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay-passive property\n");
+		goto free_tz;
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling-delay property\n");
+		goto free_tz;
+	}
+	tz->polling_delay = prop;
+
+	/* trips */
+	child = of_get_child_by_name(np, "trips");
+
+	/* No trips provided */
+	if (!child)
+		goto finish;
+
+	tz->ntrips = of_get_child_count(child);
+	if (tz->ntrips = 0) /* must have at least one child */
+		goto finish;
+
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips) {
+		ret = -ENOMEM;
+		goto free_tz;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild) {
+		ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
+		if (ret)
+			goto free_trips;
+	}
+
+	of_node_put(child);
+
+	/* cooling-maps */
+	child = of_get_child_by_name(np, "cooling-maps");
+
+	/* cooling-maps not provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	if (tz->num_tbps = 0)
+		goto finish;
+
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps) {
+		ret = -ENOMEM;
+		goto free_trips;
+	}
+
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						      tz->trips, tz->ntrips);
+		if (ret)
+			goto free_tbps;
+
+finish:
+	of_node_put(child);
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+
+free_tbps:
+	kfree(tz->tbps);
+free_trips:
+	kfree(tz->trips);
+free_tz:
+	kfree(tz);
+	of_node_put(child);
+
+	return ERR_PTR(ret);
+}
+
+static inline void of_thermal_free_zone(struct __thermal_zone *tz)
+{
+	kfree(tz->tbps);
+	kfree(tz->trips);
+	kfree(tz);
+}
+
+/**
+ * of_parse_thermal_zones - parse device tree thermal data
+ *
+ * Initialization function that can be called by machine initialization
+ * code to parse thermal data and populate the thermal framework
+ * with hardware thermal zones info. This function only parses thermal zones.
+ * Cooling devices and sensor devices nodes are supposed to be parsed
+ * by their respective drivers.
+ *
+ * Return: 0 on success, proper error code otherwise
+ *
+ */
+int __init of_parse_thermal_zones(void)
+{
+	struct device_node *np, *child;
+	struct __thermal_zone *tz;
+	struct thermal_zone_device_ops *ops;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_debug("unable to find thermal zones\n");
+		return 0; /* Run successfully on systems without thermal DT */
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+		struct thermal_zone_params *tzp;
+
+		tz = thermal_of_build_thermal_zone(child);
+		if (IS_ERR(tz)) {
+			pr_err("failed to build thermal zone %s: %ld\n",
+			       child->name,
+			       PTR_ERR(tz));
+			continue;
+		}
+
+		ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			goto exit_free;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp) {
+			kfree(ops);
+			goto exit_free;
+		}
+
+		/* No hwmon because there might be hwmon drivers registering */
+		tzp->no_hwmon = true;
+
+		zone = thermal_zone_device_register(child->name, tz->ntrips,
+						    0, tz,
+						    ops, tzp,
+						    tz->passive_delay,
+						    tz->polling_delay);
+		if (IS_ERR(zone)) {
+			pr_err("Failed to build %s zone %ld\n", child->name,
+			       PTR_ERR(zone));
+			kfree(tzp);
+			kfree(ops);
+			of_thermal_free_zone(tz);
+			/* attempting to build remaining zones still */
+		}
+	}
+
+	return 0;
+
+exit_free:
+	of_thermal_free_zone(tz);
+
+	/* no memory available, so free what we have built */
+	of_thermal_destroy_zones();
+
+	return -ENOMEM;
+}
+
+/**
+ * of_thermal_destroy_zones - remove all zones parsed and allocated resources
+ *
+ * Finds all zones parsed and added to the thermal framework and remove them
+ * from the system, together with their resources.
+ *
+ */
+void __exit of_thermal_destroy_zones(void)
+{
+	struct device_node *np, *child;
+
+	np = of_find_node_by_name(NULL, "thermal-zones");
+	if (!np) {
+		pr_err("unable to find thermal zones\n");
+		return;
+	}
+
+	for_each_child_of_node(np, child) {
+		struct thermal_zone_device *zone;
+
+		zone = thermal_zone_get_zone_by_name(child->name);
+		if (IS_ERR(zone))
+			continue;
+
+		thermal_zone_device_unregister(zone);
+		kfree(zone->tzp);
+		kfree(zone->ops);
+		of_thermal_free_zone(zone->devdata);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index f7a9f4f..fec3351 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
  */
 struct thermal_zone_device *thermal_zone_device_register(const char *type,
 	int trips, int mask, void *devdata,
-	const struct thermal_zone_device_ops *ops,
+	struct thermal_zone_device_ops *ops,
 	const struct thermal_zone_params *tzp,
 	int passive_delay, int polling_delay)
 {
@@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
 	if (result)
 		goto unregister_class;
 
+	result = of_parse_thermal_zones();
+	if (result)
+		goto exit_netlink;
+
 	return 0;
 
+exit_netlink:
+	genetlink_exit();
 unregister_governors:
 	thermal_unregister_governors();
 unregister_class:
@@ -1768,6 +1774,7 @@ error:
 
 static void __exit thermal_exit(void)
 {
+	of_thermal_destroy_zones();
 	genetlink_exit();
 	class_unregister(&thermal_class);
 	thermal_unregister_governors();
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 7cf2f66..3db339f 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
 static inline void thermal_gov_user_space_unregister(void) {}
 #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
 
+/* device tree support */
+#ifdef CONFIG_THERMAL_OF
+int of_parse_thermal_zones(void);
+void of_thermal_destroy_zones(void);
+#else
+static inline int of_parse_thermal_zones(void) { return 0; }
+static inline void of_thermal_destroy_zones(void) { }
+#endif
+
 #endif /* __THERMAL_CORE_H__ */
diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
new file mode 100644
index 0000000..59c4581
--- /dev/null
+++ b/include/dt-bindings/thermal/thermal.h
@@ -0,0 +1,27 @@
+/*
+ * This header provides constants for most thermal bindings.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *	Eduardo Valentin <eduardo.valentin@ti.com>
+ *
+ * GPLv2 only
+ */
+
+#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
+#define _DT_BINDINGS_THERMAL_THERMAL_H
+
+/*
+ * Here are the thermal trip types. This must
+ * match with enum thermal_trip_type at
+ * include/linux/thermal.h
+ */
+#define THERMAL_TRIP_ACTIVE		"active"
+#define THERMAL_TRIP_PASSIVE		"passive"
+#define THERMAL_TRIP_HOT		"hot"
+#define THERMAL_TRIP_CRITICAL		"critical"
+
+/* On cooling devices upper and lower limits */
+#define THERMAL_NO_LIMIT		(-1UL)
+
+#endif
+
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index b268d3c..b780c5b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -143,6 +143,7 @@ struct thermal_cooling_device {
 	int id;
 	char type[THERMAL_NAME_LENGTH];
 	struct device device;
+	struct device_node *np;
 	void *devdata;
 	const struct thermal_cooling_device_ops *ops;
 	bool updated; /* true if the cooling device does not need update */
@@ -172,7 +173,7 @@ struct thermal_zone_device {
 	int emul_temperature;
 	int passive;
 	unsigned int forced_passive;
-	const struct thermal_zone_device_ops *ops;
+	struct thermal_zone_device_ops *ops;
 	const struct thermal_zone_params *tzp;
 	struct thermal_governor *governor;
 	struct list_head thermal_instances;
@@ -242,8 +243,31 @@ struct thermal_genl_event {
 };
 
 /* Function declarations */
+#ifdef CONFIG_THERMAL_OF
+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 *));
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz);
+#else
+static inline 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 *))
+{
+	return NULL;
+}
+
+static inline
+void thermal_zone_of_sensor_unregister(struct device *dev,
+				       struct thermal_zone_device *tz)
+{
+}
+
+#endif
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
-		void *, const struct thermal_zone_device_ops *,
+		void *, struct thermal_zone_device_ops *,
 		const struct thermal_zone_params *, int, int);
 void thermal_zone_device_unregister(struct thermal_zone_device *);
 
-- 
1.8.2.1.342.gfa7285d


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* Re: [PATCHv8 03/18] thermal: introduce device tree parser
  2013-10-01  2:39     ` Eduardo Valentin
@ 2013-10-07 20:51       ` Mark Rutland
  -1 siblings, 0 replies; 101+ messages in thread
From: Mark Rutland @ 2013-10-07 20:51 UTC (permalink / raw)
  To: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	grant.likely
  Cc: linux, rui.zhang, wni, durgadoss.r, linux-pm, devicetree,
	lm-sensors, linux-kernel

Hi all,

Given that this is a complex new class of binding, I'd appreciate if at least
one other device tree maintainer could also take a look over this and voice any
concerns or suggestions. I've left the entire patch context for this.

Apologies for the munged whitespace -- my mail server appears to have helpfully
and irreparably replaced all tabs with spaces.

On Tue, Oct 01, 2013 at 03:39:26AM +0100, Eduardo Valentin wrote:
> This patch introduces a device tree bindings for
> describing the hardware thermal behavior and limits.
> Also a parser to read and interpret the data and feed
> it in the thermal framework is presented.
>
> This patch introduces a thermal data parser for device
> tree. The parsed data is used to build thermal zones
> and thermal binding parameters. The output data
> can then be used to deploy thermal policies.
>
> This patch adds also documentation regarding this
> API and how to define tree nodes to use
> this infrastructure.
>
> Note that, in order to be able to have control
> on the sensor registration on the DT thermal zone,
> it was required to allow changing the thermal zone
> .get_temp callback. For this reason, this patch
> also removes the 'const' modifier from the .ops
> field of thermal zone devices.
>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
> Hello Mark, folks,
>
> So, here is v8. Pretty small changes. Most are better
> English phrasing in the binding document. It follows changelog:
> - Several rephrasing in the binding document, including
> spelling, grammar and better phrasing.
> - Removed WiP warning from binding document.
> - Several spacing and formatting changes in the binding document
> - Used the '-specifier' nomenclature properly in the binding doc
> - Removed the optional property 'thermal-sensors-names', because
> it does not provide useful runtime information
> - Fixed description of 'polling-delay-passive'
> - Improved examples by adding comments and better explanation
> - s/fw/framework/g
> - Added a WARN when sensors specifiers are greater and 1.
>
> All best,
>
> Eduardo
>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
>  drivers/thermal/thermal_core.c                     |   9 +-
>  drivers/thermal/thermal_core.h                     |   9 +
>  include/dt-bindings/thermal/thermal.h              |  27 +
>  include/linux/thermal.h                            |  28 +-
>  8 files changed, 1520 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 drivers/thermal/of-thermal.c
>  create mode 100644 include/dt-bindings/thermal/thermal.h
>
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..ad06a8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,587 @@
> +* Thermal Framework Device Tree descriptor
> +
> +This file describes a generic binding to provide a way of
> +defining hardware thermal structure using device tree.

s/defining/describing/

> +A thermal structure includes thermal zones and their components,
> +such as trip points, polling intervals, sensors and cooling devices
> +binding descriptors.
> +
> +The target of device tree thermal descriptors is to describe only
> +the hardware thermal aspects. The thermal device tree bindings are
> +not about how the system must control or which algorithm or policy
> +must be taken in place.

I'm not quite sure what this is saying -- it seems to contradict the
design of the binding where trip points get linked to cooling device
configuration, and thus we're defining a policy along the lines of "when
sensor $W hits temperature $X, configure cooling device $Y with value
$Z". I don't see how that can't be considered policy.

At best, we can say that policy is being defined because describing the
physical properties of a device and dealing with this at runtime is not
feasible.

> +
> +There are five types of nodes involved to describe thermal bindings:
> +- sensors: used to describe the device source of temperature sensing;

- thermal sensors: devices which may be used to take temperature
  measurements.

> +- cooling devices: used to describe devices source of power dissipation control;

- cooling devices: devices which may be used to dissipate heat.

> +- trip points: used to describe points in temperature domain defined to
> +make the system aware of hardware limits;

- trip points: describe key temperatures at which cooling is recommended. The
  set of points should be chosen based on hardware limits.

> +- cooling maps: used to describe links between trip points and cooling devices;
> +- thermal zones: used to describe thermal data within the hardware;
> +
> +It follows a description of each type of these device tree nodes.

How about:

The following is a description of each of these node types.

> +
> +* Thermal sensor devices
> +
> +Thermal sensor devices are nodes providing temperature sensing capabilities on
> +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
> +nodes providing temperature data to thermal zones. Thermal sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #thermal-sensor-cells: Used to provide sensor device specific information
> +  Type: unsigned        while referring to it. Typically 0 on thermal sensor
> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
> +                        with several internal sensors, in order
> +                        to identify uniquely the sensor instances within
> +                        the IC. See thermal zone binding for more details
> +                        on how consumers refer to sensor devices.
> +
> +* Cooling device nodes
> +
> +Cooling devices are nodes providing control on power dissipation. There
> +are essentially two ways to provide control on power dissipation. First
> +is by means of regulating device performance, which is known as passive
> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
> +frequency scaling (DVFS), and uses lower frequencies as cooling states.
> +Second is by means of activating devices in order to remove
> +the dissipated heat, which is known as active cooling, e.g. regulating
> +fan speeds. In both cases, cooling devices shall have a way to determine
> +the state of cooling in which the device is.

I'd probably say "heat dissipation" rather than "power dissipation", unless
this is a technical term I am not aware of?

Why is the determination of the state of the cooling device important?

> +
> +Required properties:
> +- cooling-min-state:   An integer indicating the smallest
> +  Type: unsigned       cooling state accepted. Typically 0.
> +  Size: one cell
> +
> +- cooling-max-state:   An integer indicating the largest
> +  Type: unsigned       cooling state accepted.
> +  Size: one cell
> +
> +- #cooling-cells:      Used to provide cooling device specific information
> +  Type: unsigned       while referring to it. Must be at least 2, in order
> +  Size: one cell       to specify minimum and maximum cooling state used
> +                       in the reference. The first cell is the minimum
> +                       cooling state requested and the second cell is
> +                       the maximum cooling state requested in the reference.
> +                       See Cooling device maps section below for more details
> +                       on how consumers refer to cooling devices.

Is it assumed that all the values between min and max are valid, or might this
be a sparse set of cooling values?

> +
> +* Trip points
> +
> +The trip node is a node to describe a point in the temperature domain
> +in which the system takes an action. This node describes just the point,
> +not the action.
> +
> +Required properties:
> +- temperature:         An integer indicating the trip temperature level,
> +  Type: signed         in millicelsius.
> +  Size: one cell
> +
> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
> +  Type: unsigned       relative value, in millicelsius.
> +  Size: one cell

What is it relative to?

Why is 'temperature' in quotes?

> +
> +- type:                        a string containing the trip type. Supported values are:
> +       "active":       A trip point to enable active cooling
> +       "passive":      A trip point to enable passive cooling
> +       "hot":          A trip point to notify emergency
> +       "critical":     Hardware not reliable.
> +  Type: string
> +
> +There are also string constants defined at
> +include/dt-bindings/thermal/thermal.h.

Why?

> +
> +* Cooling device maps
> +
> +The cooling device maps node is a node to describe how cooling devices
> +get assigned to trip points of the zone. The cooling devices are expected
> +to be loaded in the target system.
> +
> +Required properties:
> +- cooling-device:      A phandle of a cooling device with its specifier,
> +  Type: phandle of     referring to which cooling device is used in this
> +    cooling device     binding. In the cooling specifier, the first cell
> +                       is the minimum cooling state and the second cell
> +                       is the maximum cooling state used in this map.

The type is wrong here -- it's a phandle + cooling-cells, not just a phandle.

> +- trip:                        A phandle of a trip point node within the same thermal
> +  Type: phandle of     zone.
> +   trip point node
> +
> +Optional property:
> +- contribution:                The cooling contribution to the thermal zone of the
> +  Type: unsigned       referred cooling device at the referred trip point.
> +  Size: one cell       The contribution is a ratio of the sum
> +                       of all cooling contributions within a thermal zone.
> +
> +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
> +limit specifier means:
> +(i)   - minimum state allowed for minimum cooling state used in the reference.
> +(ii)  - maximum state allowed for maximum cooling state used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> +
> +* Thermal zone nodes
> +
> +The thermal zone node is the node containing all the required info
> +for describing a thermal zone, including its cooling device bindings. The
> +thermal zone node must contain, apart from its own properties, one sub-node
> +containing trip nodes and one sub-node containing all the zone cooling maps.
> +
> +Required properties:
> +- polling-delay:       The maximum number of milliseconds to wait between polls
> +  Type: unsigned       when checking this thermal zone.
> +  Size: one cell
> +
> +- polling-delay-passive: The maximum number of milliseconds to wait
> +  Type: unsigned       between polls when performing passive cooling.
> +  Size: one cell
> +
> +- thermal-sensors:     A list of thermal sensor phandles and sensor specifier
> +  Type: list of        used while monitoring the thermal zone.
> +  sensor phandles

The type is wrong here. A list of phandle + sensor specifiers.

> +
> +- trips:               A sub-node which is a container of only trip point nodes
> +  Type: sub-node       required to describe the thermal zone.
> +
> +- cooling-maps:                A sub-node which is a container of only cooling device
> +  Type: sub-node       map nodes, used to describe the relation between trips
> +                       and cooling devices.
> +
> +Optional property:
> +- coefficients:                An array of integers (one signed cell) containing
> +  Type: array          coefficients to compose a linear relation between
> +  Elem size: one cell  the sensors listed in the thermal-sensors property.
> +  Elem type: signed    Coefficients defaults to 1, in case this property
> +                       is not specified. A simple linear polynomial is used:
> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
> +
> +                       The coefficients are ordered and they match with sensors
> +                       by means of sensor ID. Additional coefficients are
> +                       interpreted as constant offset.
> +
> +Note: The delay properties are bound to the maximum dT/dt (temperature
> +derivative over time) in two situations for a thermal zone:
> +(i)  - when passive cooling is activated (polling-delay-passive); and
> +(ii) - when the zone just needs to be monitored (polling-delay) or
> +when active cooling is activated.
> +
> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
> +capability. The delays should be chosen to account for said max dT/dt,
> +such that a device does not cross several trip boundaries unexpectedly
> +between polls. Choosing the right polling delays shall avoid having the
> +device in temperature ranges that may damage the silicon structures and
> +reduce silicon lifetime.
> +
> +* The thermal-zones node
> +
> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
> +contain only sub-nodes describing thermal zones as in the section
> +"Thermal zone nodes". The "thermal-zones" node appears under "/".
> +
> +* Examples
> +
> +Below are several examples on how to use thermal data descriptors
> +using device tree bindings:
> +
> +(a) - CPU thermal zone
> +
> +The CPU thermal zone example below describes how to setup one thermal zone
> +using one single sensor as temperature source and many cooling devices and
> +power dissipation control sources.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +cpus {
> +       /*
> +        * Here is an example of describing a cooling device for a DVFS
> +        * capable CPU. The CPU node describes its four OPPs.
> +        * The cooling states possible are 0..3, and they are
> +        * used as OPP indexes. The minimum cooling state is 0, which means
> +        * all four OPPs can be available to the system. The maximum
> +        * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
> +        * can be available in the system.
> +        */
> +       cpu0: cpu@0 {
> +               ...
> +               operating-points = <
> +                       /* kHz    uV */
> +                       970000  1200000
> +                       792000  1100000
> +                       396000  950000
> +                       198000  850000
> +               >;
> +               cooling-min-state = <0>;
> +               cooling-max-state = <3>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +       ...
> +};
> +
> +&i2c1 {
> +       ...
> +       /*
> +        * A simple fan controller which supports 10 speeds of operation
> +        * (represented as 0-9).
> +        */
> +       fan0: fan@0x48 {
> +               ...
> +               cooling-min-state = <0>;
> +               cooling-max-state = <9>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +};
> +
> +ocp {
> +       ...
> +       /*
> +        * A simple IC with a single bandgap temperature sensor.
> +        */
> +       bandgap0: bandgap@0x0000ED00 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +thermal-zones {
> +       cpu-thermal: cpu-thermal {
> +               polling-delay-passive = <250>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +               thermal-sensors = <&bandgap0>;
> +
> +               trips {
> +                       cpu-alert0: cpu-alert {
> +                               temperature = <90000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "active";
> +                       };
> +                       cpu-alert1: cpu-alert {
> +                               temperature = <100000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       cpu-crit: cpu-crit {
> +                               temperature = <125000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       map0 {
> +                               trip = <&cpu-alert0>;
> +                               cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +                       };
> +                       map1 {
> +                               trip = <&cpu-alert1>;
> +                               cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +                       };
> +                       map2 {
> +                               trip = <&cpu-alert1>;
> +                               cooling-device =
> +                                   <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
> +                       };
> +               };
> +       };
> +};
> +
> +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
> +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
> +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
> +different cooling states 0-9. It is used to remove the heat out of
> +the thermal zone 'cpu-thermal' using its cooling states
> +from its minimum to 4, when it reaches trip point 'cpu-alert0'
> +at 90C, as an example of active cooling. The same cooling device is used at
> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
> +using all its cooling states at trip point 'cpu-alert1',
> +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
> +temperature of 125C, represented by the trip point 'cpu-crit', the silicon
> +is not reliable anymore.
> +
> +(b) - IC with several internal sensors
> +
> +The example below describes how to deploy several thermal zones based off a
> +single sensor IC, assuming it has several internal sensors. This is a common
> +case on SoC designs with several internal IPs that may need different thermal
> +requirements, and thus may have their own sensor to monitor or detect internal
> +hotspots in their silicon.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +ocp {
> +       ...
> +       /*
> +        * A simple IC with several bandgap temperature sensors.
> +        */
> +       bandgap0: bandgap@0x0000ED00 {
> +               ...
> +               #thermal-sensor-cells = <1>;
> +       };
> +};
> +
> +thermal-zones {
> +       cpu-thermal: cpu-thermal {
> +               polling-delay-passive = <250>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&bandgap0     0>;
> +
> +               trips {
> +                       /* each zone within the SoC may have its own trips */
> +                       cpu-alert: cpu-alert {
> +                               temperature = <100000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       cpu-crit: cpu-crit {
> +                               temperature = <125000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       /* each zone within the SoC may have its own cooling */
> +                       ...
> +               };
> +       };
> +
> +       gpu-thermal: gpu-thermal {
> +               polling-delay-passive = <120>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&bandgap0     1>;
> +
> +               trips {
> +                       /* each zone within the SoC may have its own trips */
> +                       gpu-alert: gpu-alert {
> +                               temperature = <90000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       gpu-crit: gpu-crit {
> +                               temperature = <105000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       /* each zone within the SoC may have its own cooling */
> +                       ...
> +               };
> +       };
> +
> +       dsp-thermal: dsp-thermal {
> +               polling-delay-passive = <50>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&bandgap0     2>;
> +
> +               trips {
> +                       /* each zone within the SoC may have its own trips */
> +                       dsp-alert: gpu-alert {
> +                               temperature = <90000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       dsp-crit: gpu-crit {
> +                               temperature = <135000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       /* each zone within the SoC may have its own cooling */
> +                       ...
> +               };
> +       };
> +};
> +
> +In the example above, there is one bandgap IC which has the capability to
> +monitor three sensors. The hardware has been designed so that sensors are
> +placed on different places in the DIE to monitor different temperature
> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
> +other to monitor a DSP thermal zone.
> +
> +Thus, there is a need to assign each sensor provided by the bandgap IC
> +to different thermal zones. This is achieved by means of using the
> +#thermal-sensor-cells property and using the first cell of the sensor
> +specifier as sensor ID. In the example, then, <bandgap 0> is used to
> +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
> +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
> +may be uncorrelated, having its own dT/dt requirements, trips
> +and cooling maps.
> +
> +
> +(c) - Several sensors within one single thermal zone
> +
> +The example below illustrates how to use more than one sensor within
> +one thermal zone.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&i2c1 {
> +       ...
> +       /*
> +        * A simple IC with a single temperature sensor.
> +        */
> +       adc: sensor@0x49 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +ocp {
> +       ...
> +       /*
> +        * A simple IC with a single bandgap temperature sensor.
> +        */
> +       bandgap0: bandgap@0x0000ED00 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +thermal-zones {
> +       cpu-thermal: cpu-thermal {
> +               polling-delay-passive = <250>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +               thermal-sensors = <&bandgap0>,  /* cpu */
> +                                 <&adc>;       /* pcb north */
> +
> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
> +               coefficients =          <100    -120    484>;
> +
> +               trips {
> +                       ...
> +               };
> +
> +               cooling-maps {
> +                       ...
> +               };
> +       };
> +};
> +
> +In some cases, there is a need to use more than one sensor to extrapolate
> +a thermal hotspot in the silicon. The above example illustrates this situation.
> +For instance, it may be the case that a sensor external to CPU IP may be placed
> +close to CPU hotspot and together with internal CPU sensor, it is used
> +to determine the hotspot. Assuming this is the case for the above example,
> +the hypothetical extrapolation rule would be:
> +               hotspot = 100 * bandgap - 120 * adc + 484
> +
> +In other context, the same idea can be used to add fixed offset. For instance,
> +consider the hotspot extrapolation rule below:
> +               hotspot = 1 * adc + 6000
> +
> +In the above equation, the hotspot is always 6C higher than what is read
> +from the ADC sensor. The binding would be then:
> +        thermal-sensors =  <&adc>;
> +
> +               /* hotspot = 1 * adc + 6000 */
> +       coefficients =          <1      6000>;
> +
> +(d) - Board thermal
> +
> +The board thermal example below illustrates how to setup one thermal zone
> +with many sensors and many cooling devices.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&i2c1 {
> +       ...
> +       /*
> +        * An IC with several temperature sensor.
> +        */
> +       adc-dummy: sensor@0x50 {
> +               ...
> +               #thermal-sensor-cells = <1>; /* sensor internal ID */
> +       };
> +};
> +
> +thermal-zones {
> +       batt-thermal {
> +               polling-delay-passive = <500>; /* milliseconds */
> +               polling-delay = <2500>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&adc-dummy     4>;
> +
> +               trips {
> +                       ...
> +               };
> +
> +               cooling-maps {
> +                       ...
> +               };
> +       };
> +
> +       board-thermal: board-thermal {
> +               polling-delay-passive = <1000>; /* milliseconds */
> +               polling-delay = <2500>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
> +                                 <&adc-dummy     1>, /* lcd */
> +                                 <&adc-dymmy     2>; /* back cover */
> +               /*
> +                * An array of coefficients describing the sensor
> +                * linear relation. E.g.:
> +                * z = c1*x1 + c2*x2 + c3*x3
> +                */
> +               coefficients =          <1200   -345    890>;
> +
> +               trips {
> +                       /* Trips are based on resulting linear equation */
> +                       cpu-trip: cpu-trip {
> +                               temperature = <60000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       gpu-trip: gpu-trip {
> +                               temperature = <55000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       }
> +                       lcd-trip: lcp-trip {
> +                               temperature = <53000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       crit-trip: crit-trip {
> +                               temperature = <68000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       map0 {
> +                               trip = <&cpu-trip>;
> +                               cooling-device = <&cpu0 0 2>;
> +                               contribution = <55>;
> +                       };
> +                       map1 {
> +                               trip = <&gpu-trip>;
> +                               cooling-device = <&gpu0 0 2>;
> +                               contribution = <20>;
> +                       };
> +                       map2 {
> +                               trip = <&lcd-trip>;
> +                               cooling-device = <&lcd0 5 10>;
> +                               contribution = <15>;
> +                       };
> +               };
> +       };
> +};
> +
> +The above example is a mix of previous examples, a sensor IP with several internal
> +sensors used to monitor different zones, one of them is composed by several sensors and
> +with different cooling devices.
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index dbfc390..dd81eb8 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -29,6 +29,19 @@ config THERMAL_HWMON
>           Say 'Y' here if you want all thermal sensors to
>           have hwmon sysfs interface too.
>
> +config THERMAL_OF
> +       bool
> +       prompt "APIs to parse thermal data out of device tree"
> +       depends on OF
> +       default y
> +       help
> +         This options provides helpers to add the support to
> +         read and parse thermal data definitions out of the
> +         device tree blob.
> +
> +         Say 'Y' here if you need to build thermal infrastructure
> +         based on device tree.
> +
>  choice
>         prompt "Default Thermal governor"
>         default THERMAL_DEFAULT_GOV_STEP_WISE
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 584b363..4b03956 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -7,6 +7,7 @@ thermal_sys-y                   += thermal_core.o
>
>  # interface to/from other layers providing sensors
>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
> +thermal_sys-$(CONFIG_THERMAL_OF)               += of-thermal.o
>
>  # governors
>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> new file mode 100644
> index 0000000..66f9eb2
> --- /dev/null
> +++ b/drivers/thermal/of-thermal.c
> @@ -0,0 +1,849 @@
> +/*
> + *  of-thermal.c - Generic Thermal Management device tree support.
> + *
> + *  Copyright (C) 2013 Texas Instruments
> + *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
> + *
> + *
> + *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; version 2 of the License.
> + *
> + *  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.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +#include <linux/thermal.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/string.h>
> +
> +#include "thermal_core.h"
> +
> +/***   Private data structures to represent thermal device tree data ***/
> +
> +/**
> + * struct __thermal_trip - representation of a point in temperature domain
> + * @np: pointer to struct device_node that this trip point was created from
> + * @temperature: temperature value in miliCelsius
> + * @hysteresis: relative hysteresis in miliCelsius
> + * @type: trip point type
> + */
> +
> +struct __thermal_trip {
> +       struct device_node *np;
> +       unsigned long int temperature;
> +       unsigned long int hysteresis;
> +       enum thermal_trip_type type;
> +};
> +
> +/**
> + * struct __thermal_bind_param - a match between trip and cooling device
> + * @cooling_device: a pointer to identify the referred cooling device
> + * @trip_id: the trip point index
> + * @usage: the percentage (from 0 to 100) of cooling contribution
> + * @min: minimum cooling state used at this trip point
> + * @max: maximum cooling state used at this trip point
> + */
> +
> +struct __thermal_bind_params {
> +       struct device_node *cooling_device;
> +       unsigned int trip_id;
> +       unsigned int usage;
> +       unsigned long min;
> +       unsigned long max;
> +};
> +
> +/**
> + * struct __thermal_zone - internal representation of a thermal zone
> + * @mode: current thermal zone device mode (enabled/disabled)
> + * @passive_delay: polling interval while passive cooling is activated
> + * @polling_delay: zone polling interval
> + * @ntrips: number of trip points
> + * @trips: an array of trip points (0..ntrips - 1)
> + * @num_tbps: number of thermal bind params
> + * @tbps: an array of thermal bind params (0..num_tbps - 1)
> + * @sensor_data: sensor private data used while reading temperature and trend
> + * @get_temp: sensor callback to read temperature
> + * @get_trend: sensor callback to read temperature trend
> + */
> +
> +struct __thermal_zone {
> +       enum thermal_device_mode mode;
> +       int passive_delay;
> +       int polling_delay;
> +
> +       /* trip data */
> +       int ntrips;
> +       struct __thermal_trip *trips;
> +
> +       /* cooling binding data */
> +       int num_tbps;
> +       struct __thermal_bind_params *tbps;
> +
> +       /* sensor interface */
> +       void *sensor_data;
> +       int (*get_temp)(void *, long *);
> +       int (*get_trend)(void *, long *);
> +};
> +
> +/***   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;
> +
> +       if (!data->get_temp)
> +               return -EINVAL;
> +
> +       return data->get_temp(data->sensor_data, temp);
> +}
> +
> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
> +                               enum thermal_trend *trend)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +       long dev_trend;
> +       int r;
> +
> +       if (!data->get_trend)
> +               return -EINVAL;
> +
> +       r = data->get_trend(data->sensor_data, &dev_trend);
> +       if (r)
> +               return r;
> +
> +       /* TODO: These intervals might have some thresholds, but in core code */
> +       if (dev_trend > 0)
> +               *trend = THERMAL_TREND_RAISING;
> +       else if (dev_trend < 0)
> +               *trend = THERMAL_TREND_DROPPING;
> +       else
> +               *trend = THERMAL_TREND_STABLE;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_bind(struct thermal_zone_device *thermal,
> +                          struct thermal_cooling_device *cdev)
> +{
> +       struct __thermal_zone *data = thermal->devdata;
> +       int i;
> +
> +       if (!data || IS_ERR(data))
> +               return -ENODEV;
> +
> +       /* find where to bind */
> +       for (i = 0; i < data->num_tbps; i++) {
> +               struct __thermal_bind_params *tbp = data->tbps + i;
> +
> +               if (tbp->cooling_device == cdev->np) {
> +                       int ret;
> +
> +                       ret = thermal_zone_bind_cooling_device(thermal,
> +                                               tbp->trip_id, cdev,
> +                                               tbp->min,
> +                                               tbp->max);
> +                       if (ret)
> +                               return ret;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
> +static int of_thermal_unbind(struct thermal_zone_device *thermal,
> +                            struct thermal_cooling_device *cdev)
> +{
> +       struct __thermal_zone *data = thermal->devdata;
> +       int i;
> +
> +       if (!data || IS_ERR(data))
> +               return -ENODEV;
> +
> +       /* find where to unbind */
> +       for (i = 0; i < data->num_tbps; i++) {
> +               struct __thermal_bind_params *tbp = data->tbps + i;
> +
> +               if (tbp->cooling_device == cdev->np) {
> +                       int ret;
> +
> +                       ret = thermal_zone_unbind_cooling_device(thermal,
> +                                               tbp->trip_id, cdev);
> +                       if (ret)
> +                               return ret;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_mode(struct thermal_zone_device *tz,
> +                              enum thermal_device_mode *mode)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       *mode = data->mode;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_set_mode(struct thermal_zone_device *tz,
> +                              enum thermal_device_mode mode)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       mutex_lock(&tz->lock);
> +
> +       if (mode == THERMAL_DEVICE_ENABLED)
> +               tz->polling_delay = data->polling_delay;
> +       else
> +               tz->polling_delay = 0;
> +
> +       mutex_unlock(&tz->lock);
> +
> +       data->mode = mode;
> +       thermal_zone_device_update(tz);
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
> +                                   enum thermal_trip_type *type)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       *type = data->trips[trip].type;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long *temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       *temp = data->trips[trip].temperature;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       /* thermal framework should take care of data->mask & (1 << trip) */
> +       data->trips[trip].temperature = temp;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long *hyst)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       *hyst = data->trips[trip].hysteresis;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long hyst)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       /* thermal framework should take care of data->mask & (1 << trip) */
> +       data->trips[trip].hysteresis = hyst;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
> +                                   unsigned long *temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +       int i;
> +
> +       for (i = 0; i < data->ntrips; i++)
> +               if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
> +                       *temp = data->trips[i].temperature;
> +                       return 0;
> +               }
> +
> +       return -EINVAL;
> +}
> +
> +static struct thermal_zone_device_ops of_thermal_ops = {
> +       .get_mode = of_thermal_get_mode,
> +       .set_mode = of_thermal_set_mode,
> +
> +       .get_trip_type = of_thermal_get_trip_type,
> +       .get_trip_temp = of_thermal_get_trip_temp,
> +       .set_trip_temp = of_thermal_set_trip_temp,
> +       .get_trip_hyst = of_thermal_get_trip_hyst,
> +       .set_trip_hyst = of_thermal_set_trip_hyst,
> +       .get_crit_temp = of_thermal_get_crit_temp,
> +
> +       .bind = of_thermal_bind,
> +       .unbind = of_thermal_unbind,
> +};
> +
> +/***   sensor API   ***/
> +
> +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 *))
> +{
> +       struct thermal_zone_device *tzd;
> +       struct __thermal_zone *tz;
> +
> +       tzd = thermal_zone_get_zone_by_name(zone->name);
> +       if (IS_ERR(tzd))
> +               return ERR_PTR(-EPROBE_DEFER);
> +
> +       tz = tzd->devdata;
> +
> +       mutex_lock(&tzd->lock);
> +       tz->get_temp = get_temp;
> +       tz->get_trend = get_trend;
> +       tz->sensor_data = data;
> +
> +       tzd->ops->get_temp = of_thermal_get_temp;
> +       tzd->ops->get_trend = of_thermal_get_trend;
> +       mutex_unlock(&tzd->lock);
> +
> +       return tzd;
> +}
> +
> +/**
> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
> + * @dev: a valid struct device pointer of a sensor device. Must contain
> + *       a valid .of_node, for the sensor node.
> + * @sensor_id: a sensor identifier, in case the sensor IP has more
> + *             than one sensors
> + * @data: a private pointer (owned by the caller) that will be passed
> + *        back, when a temperature reading is needed.
> + * @get_temp: a pointer to a function that reads the sensor temperature.
> + * @get_trend: a pointer to a function that reads the sensor temperature trend.
> + *
> + * This function will search the list of thermal zones described in device
> + * tree and look for the zone that refer to the sensor device pointed by
> + * @dev->of_node as temperature providers. For the zone pointing to the
> + * sensor node, the sensor will be added to the DT thermal zone device.
> + *
> + * The thermal zone temperature is provided by the @get_temp function
> + * pointer. When called, it will have the private pointer @data back.
> + *
> + * The thermal zone temperature trend is provided by the @get_trend function
> + * pointer. When called, it will have the private pointer @data back.
> + *
> + * TODO:
> + * 01 - This function must enqueue the new sensor instead of using
> + * it as the only source of temperature values.
> + *
> + * 02 - There must be a way to match the sensor with all thermal zones
> + * that refer to it.
> + *
> + * Return: On success returns a valid struct thermal_zone_device,
> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
> + * check the return value with help of IS_ERR() helper.
> + */
> +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 *))
> +{
> +       struct device_node *np, *child, *sensor_np;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np)
> +               return ERR_PTR(-ENODEV);
> +
> +       if (!dev || !dev->of_node)
> +               return ERR_PTR(-EINVAL);
> +
> +       sensor_np = dev->of_node;
> +
> +       for_each_child_of_node(np, child) {
> +               struct of_phandle_args sensor_specs;
> +               int ret, id;
> +
> +               /* For now, thermal framework supports only 1 sensor per zone */
> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
> +                                                "#thermal-sensor-cells",
> +                                                0, &sensor_specs);
> +               if (ret)
> +                       continue;
> +
> +               if (sensor_specs.args_count >= 1) {
> +                       id = sensor_specs.args[0];
> +                       WARN(sensor_specs.args_count > 1,
> +                            "%s: too many cells in sensor specifier %d\n",
> +                            sensor_specs.np->name, sensor_specs.args_count);
> +               } else {
> +                       id = 0;
> +               }
> +
> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
> +                       of_node_put(np);
> +                       return thermal_zone_of_add_sensor(child, sensor_np,
> +                                                         data,
> +                                                         get_temp,
> +                                                         get_trend);
> +               }
> +       }
> +       of_node_put(np);
> +
> +       return ERR_PTR(-ENODEV);
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
> +
> +/**
> + * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
> + * @dev: a valid struct device pointer of a sensor device. Must contain
> + *       a valid .of_node, for the sensor node.
> + * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
> + *
> + * This function removes the sensor callbacks and private data from the
> + * thermal zone device registered with thermal_zone_of_sensor_register()
> + * API. It will also silent the zone by remove the .get_temp() and .get_trend()
> + * thermal zone device callbacks.
> + *
> + * TODO: When the support to several sensors per zone is added, this
> + * function must search the sensor list based on @dev parameter.
> + *
> + */
> +void thermal_zone_of_sensor_unregister(struct device *dev,
> +                                      struct thermal_zone_device *tzd)
> +{
> +       struct __thermal_zone *tz;
> +
> +       if (!dev || !tzd || !tzd->devdata)
> +               return;
> +
> +       tz = tzd->devdata;
> +
> +       /* no __thermal_zone, nothing to be done */
> +       if (!tz)
> +               return;
> +
> +       mutex_lock(&tzd->lock);
> +       tzd->ops->get_temp = NULL;
> +       tzd->ops->get_trend = NULL;
> +
> +       tz->get_temp = NULL;
> +       tz->get_trend = NULL;
> +       tz->sensor_data = NULL;
> +       mutex_unlock(&tzd->lock);
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
> +
> +/***   functions parsing device tree nodes   ***/
> +
> +/**
> + * thermal_of_populate_bind_params - parse and fill cooling map data
> + * @np: DT node containing a cooling-map node
> + * @__tbp: data structure to be filled with cooling map info
> + * @trips: array of thermal zone trip points
> + * @ntrips: number of trip points inside trips.
> + *
> + * This function parses a cooling-map type of node represented by
> + * @np parameter and fills the read data into @__tbp data structure.
> + * It needs the already parsed array of trip points of the thermal zone
> + * in consideration.
> + *
> + * Return: 0 on success, proper error code otherwise
> + */
> +static int thermal_of_populate_bind_params(struct device_node *np,
> +                                          struct __thermal_bind_params *__tbp,
> +                                          struct __thermal_trip *trips,
> +                                          int ntrips)
> +{
> +       struct of_phandle_args cooling_spec;
> +       struct device_node *trip;
> +       int ret, i;
> +       u32 prop;
> +
> +       /* Default weight. Usage is optional */
> +       __tbp->usage = 0;
> +       ret = of_property_read_u32(np, "contribution", &prop);
> +       if (ret == 0)
> +               __tbp->usage = prop;
> +
> +       trip = of_parse_phandle(np, "trip", 0);
> +       if (!trip) {
> +               pr_err("missing trip property\n");
> +               return -ENODEV;
> +       }
> +
> +       /* match using device_node */
> +       for (i = 0; i < ntrips; i++)
> +               if (trip == trips[i].np) {
> +                       __tbp->trip_id = i;
> +                       break;
> +               }
> +
> +       if (i == ntrips) {
> +               ret = -ENODEV;
> +               goto end;
> +       }
> +
> +       ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
> +                                        0, &cooling_spec);
> +       if (ret < 0) {
> +               pr_err("missing cooling_device property\n");
> +               goto end;
> +       }
> +       __tbp->cooling_device = cooling_spec.np;
> +       if (cooling_spec.args_count >= 2) { /* at least min and max */
> +               __tbp->min = cooling_spec.args[0];
> +               __tbp->max = cooling_spec.args[1];
> +       } else {
> +               pr_err("wrong reference to cooling device, missing limits\n");
> +       }
> +
> +end:
> +       of_node_put(trip);
> +
> +       return ret;
> +}
> +
> +/**
> + * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
> + * into the device tree binding of 'trip', property type.
> + */
> +static const char * const trip_types[] = {
> +       [THERMAL_TRIP_ACTIVE]   = "active",
> +       [THERMAL_TRIP_PASSIVE]  = "passive",
> +       [THERMAL_TRIP_HOT]      = "hot",
> +       [THERMAL_TRIP_CRITICAL] = "critical",
> +};
> +
> +/**
> + * thermal_of_get_trip_type - Get phy mode for given device_node
> + * @np:        Pointer to the given device_node
> + * @type: Pointer to resulting trip type
> + *
> + * The function gets trip type string from property 'type',
> + * and store its index in trip_types table in @type,
> + *
> + * Return: 0 on success, or errno in error case.
> + */
> +static int thermal_of_get_trip_type(struct device_node *np,
> +                                   enum thermal_trip_type *type)
> +{
> +       const char *t;
> +       int err, i;
> +
> +       err = of_property_read_string(np, "type", &t);
> +       if (err < 0)
> +               return err;
> +
> +       for (i = 0; i < ARRAY_SIZE(trip_types); i++)
> +               if (!strcasecmp(t, trip_types[i])) {
> +                       *type = i;
> +                       return 0;
> +               }
> +
> +       return -ENODEV;
> +}
> +
> +/**
> + * thermal_of_populate_trip - parse and fill one trip point data
> + * @np: DT node containing a trip point node
> + * @trip: trip point data structure to be filled up
> + *
> + * This function parses a trip point type of node represented by
> + * @np parameter and fills the read data into @trip data structure.
> + *
> + * Return: 0 on success, proper error code otherwise
> + */
> +static int thermal_of_populate_trip(struct device_node *np,
> +                                   struct __thermal_trip *trip)
> +{
> +       int prop;
> +       int ret;
> +
> +       ret = of_property_read_u32(np, "temperature", &prop);
> +       if (ret < 0) {
> +               pr_err("missing temperature property\n");
> +               return ret;
> +       }
> +       trip->temperature = prop;
> +
> +       ret = of_property_read_u32(np, "hysteresis", &prop);
> +       if (ret < 0) {
> +               pr_err("missing hysteresis property\n");
> +               return ret;
> +       }
> +       trip->hysteresis = prop;
> +
> +       ret = thermal_of_get_trip_type(np, &trip->type);
> +       if (ret < 0) {
> +               pr_err("wrong trip type property\n");
> +               return ret;
> +       }
> +
> +       /* Required for cooling map matching */
> +       trip->np = np;
> +
> +       return 0;
> +}
> +
> +/**
> + * thermal_of_build_thermal_zone - parse and fill one thermal zone data
> + * @np: DT node containing a thermal zone node
> + *
> + * This function parses a thermal zone type of node represented by
> + * @np parameter and fills the read data into a __thermal_zone data structure
> + * and return this pointer.
> + *
> + * TODO: Missing properties to parse: thermal-sensor-names and coefficients
> + *
> + * Return: On success returns a valid struct __thermal_zone,
> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
> + * check the return value with help of IS_ERR() helper.
> + */
> +static struct __thermal_zone *
> +thermal_of_build_thermal_zone(struct device_node *np)
> +{
> +       struct device_node *child = NULL, *gchild;
> +       struct __thermal_zone *tz;
> +       int ret, i;
> +       u32 prop;
> +
> +       if (!np) {
> +               pr_err("no thermal zone np\n");
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       tz = kzalloc(sizeof(*tz), GFP_KERNEL);
> +       if (!tz)
> +               return ERR_PTR(-ENOMEM);
> +
> +       ret = of_property_read_u32(np, "polling-delay-passive", &prop);
> +       if (ret < 0) {
> +               pr_err("missing polling-delay-passive property\n");
> +               goto free_tz;
> +       }
> +       tz->passive_delay = prop;
> +
> +       ret = of_property_read_u32(np, "polling-delay", &prop);
> +       if (ret < 0) {
> +               pr_err("missing polling-delay property\n");
> +               goto free_tz;
> +       }
> +       tz->polling_delay = prop;
> +
> +       /* trips */
> +       child = of_get_child_by_name(np, "trips");
> +
> +       /* No trips provided */
> +       if (!child)
> +               goto finish;
> +
> +       tz->ntrips = of_get_child_count(child);
> +       if (tz->ntrips == 0) /* must have at least one child */
> +               goto finish;
> +
> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
> +       if (!tz->trips) {
> +               ret = -ENOMEM;
> +               goto free_tz;
> +       }
> +
> +       i = 0;
> +       for_each_child_of_node(child, gchild) {
> +               ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
> +               if (ret)
> +                       goto free_trips;
> +       }
> +
> +       of_node_put(child);
> +
> +       /* cooling-maps */
> +       child = of_get_child_by_name(np, "cooling-maps");
> +
> +       /* cooling-maps not provided */
> +       if (!child)
> +               goto finish;
> +
> +       tz->num_tbps = of_get_child_count(child);
> +       if (tz->num_tbps == 0)
> +               goto finish;
> +
> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
> +       if (!tz->tbps) {
> +               ret = -ENOMEM;
> +               goto free_trips;
> +       }
> +
> +       i = 0;
> +       for_each_child_of_node(child, gchild)
> +               ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
> +                                                     tz->trips, tz->ntrips);
> +               if (ret)
> +                       goto free_tbps;
> +
> +finish:
> +       of_node_put(child);
> +       tz->mode = THERMAL_DEVICE_DISABLED;
> +
> +       return tz;
> +
> +free_tbps:
> +       kfree(tz->tbps);
> +free_trips:
> +       kfree(tz->trips);
> +free_tz:
> +       kfree(tz);
> +       of_node_put(child);
> +
> +       return ERR_PTR(ret);
> +}
> +
> +static inline void of_thermal_free_zone(struct __thermal_zone *tz)
> +{
> +       kfree(tz->tbps);
> +       kfree(tz->trips);
> +       kfree(tz);
> +}
> +
> +/**
> + * of_parse_thermal_zones - parse device tree thermal data
> + *
> + * Initialization function that can be called by machine initialization
> + * code to parse thermal data and populate the thermal framework
> + * with hardware thermal zones info. This function only parses thermal zones.
> + * Cooling devices and sensor devices nodes are supposed to be parsed
> + * by their respective drivers.
> + *
> + * Return: 0 on success, proper error code otherwise
> + *
> + */
> +int __init of_parse_thermal_zones(void)
> +{
> +       struct device_node *np, *child;
> +       struct __thermal_zone *tz;
> +       struct thermal_zone_device_ops *ops;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np) {
> +               pr_debug("unable to find thermal zones\n");
> +               return 0; /* Run successfully on systems without thermal DT */
> +       }
> +
> +       for_each_child_of_node(np, child) {
> +               struct thermal_zone_device *zone;
> +               struct thermal_zone_params *tzp;
> +
> +               tz = thermal_of_build_thermal_zone(child);
> +               if (IS_ERR(tz)) {
> +                       pr_err("failed to build thermal zone %s: %ld\n",
> +                              child->name,
> +                              PTR_ERR(tz));
> +                       continue;
> +               }
> +
> +               ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
> +               if (!ops)
> +                       goto exit_free;
> +
> +               tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +               if (!tzp) {
> +                       kfree(ops);
> +                       goto exit_free;
> +               }
> +
> +               /* No hwmon because there might be hwmon drivers registering */
> +               tzp->no_hwmon = true;
> +
> +               zone = thermal_zone_device_register(child->name, tz->ntrips,
> +                                                   0, tz,
> +                                                   ops, tzp,
> +                                                   tz->passive_delay,
> +                                                   tz->polling_delay);
> +               if (IS_ERR(zone)) {
> +                       pr_err("Failed to build %s zone %ld\n", child->name,
> +                              PTR_ERR(zone));
> +                       kfree(tzp);
> +                       kfree(ops);
> +                       of_thermal_free_zone(tz);
> +                       /* attempting to build remaining zones still */
> +               }
> +       }
> +
> +       return 0;
> +
> +exit_free:
> +       of_thermal_free_zone(tz);
> +
> +       /* no memory available, so free what we have built */
> +       of_thermal_destroy_zones();
> +
> +       return -ENOMEM;
> +}
> +
> +/**
> + * of_thermal_destroy_zones - remove all zones parsed and allocated resources
> + *
> + * Finds all zones parsed and added to the thermal framework and remove them
> + * from the system, together with their resources.
> + *
> + */
> +void __exit of_thermal_destroy_zones(void)
> +{
> +       struct device_node *np, *child;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np) {
> +               pr_err("unable to find thermal zones\n");
> +               return;
> +       }
> +
> +       for_each_child_of_node(np, child) {
> +               struct thermal_zone_device *zone;
> +
> +               zone = thermal_zone_get_zone_by_name(child->name);
> +               if (IS_ERR(zone))
> +                       continue;
> +
> +               thermal_zone_device_unregister(zone);
> +               kfree(zone->tzp);
> +               kfree(zone->ops);
> +               of_thermal_free_zone(zone->devdata);
> +       }
> +}
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index f7a9f4f..fec3351 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
>   */
>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
>         int trips, int mask, void *devdata,
> -       const struct thermal_zone_device_ops *ops,
> +       struct thermal_zone_device_ops *ops,
>         const struct thermal_zone_params *tzp,
>         int passive_delay, int polling_delay)
>  {
> @@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
>         if (result)
>                 goto unregister_class;
>
> +       result = of_parse_thermal_zones();
> +       if (result)
> +               goto exit_netlink;
> +
>         return 0;
>
> +exit_netlink:
> +       genetlink_exit();
>  unregister_governors:
>         thermal_unregister_governors();
>  unregister_class:
> @@ -1768,6 +1774,7 @@ error:
>
>  static void __exit thermal_exit(void)
>  {
> +       of_thermal_destroy_zones();
>         genetlink_exit();
>         class_unregister(&thermal_class);
>         thermal_unregister_governors();
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index 7cf2f66..3db339f 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
>  static inline void thermal_gov_user_space_unregister(void) {}
>  #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
>
> +/* device tree support */
> +#ifdef CONFIG_THERMAL_OF
> +int of_parse_thermal_zones(void);
> +void of_thermal_destroy_zones(void);
> +#else
> +static inline int of_parse_thermal_zones(void) { return 0; }
> +static inline void of_thermal_destroy_zones(void) { }
> +#endif
> +
>  #endif /* __THERMAL_CORE_H__ */
> diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
> new file mode 100644
> index 0000000..59c4581
> --- /dev/null
> +++ b/include/dt-bindings/thermal/thermal.h
> @@ -0,0 +1,27 @@
> +/*
> + * This header provides constants for most thermal bindings.
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *     Eduardo Valentin <eduardo.valentin@ti.com>
> + *
> + * GPLv2 only
> + */
> +
> +#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
> +#define _DT_BINDINGS_THERMAL_THERMAL_H
> +
> +/*
> + * Here are the thermal trip types. This must
> + * match with enum thermal_trip_type at
> + * include/linux/thermal.h
> + */
> +#define THERMAL_TRIP_ACTIVE            "active"
> +#define THERMAL_TRIP_PASSIVE           "passive"
> +#define THERMAL_TRIP_HOT               "hot"
> +#define THERMAL_TRIP_CRITICAL          "critical"

I don't like this. If someone wants to include this in a C file they can't do so
at the same time as include/linux/thermal.h. The defined names are longer than
the actual string values, and the comment makes it sound like these could be
modified rather than being a fixed ABI.

I do not see the point of these constants.

Thanks,
Mark.

> +
> +/* On cooling devices upper and lower limits */
> +#define THERMAL_NO_LIMIT               (-1UL)
> +
> +#endif
> +
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index b268d3c..b780c5b 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -143,6 +143,7 @@ struct thermal_cooling_device {
>         int id;
>         char type[THERMAL_NAME_LENGTH];
>         struct device device;
> +       struct device_node *np;
>         void *devdata;
>         const struct thermal_cooling_device_ops *ops;
>         bool updated; /* true if the cooling device does not need update */
> @@ -172,7 +173,7 @@ struct thermal_zone_device {
>         int emul_temperature;
>         int passive;
>         unsigned int forced_passive;
> -       const struct thermal_zone_device_ops *ops;
> +       struct thermal_zone_device_ops *ops;
>         const struct thermal_zone_params *tzp;
>         struct thermal_governor *governor;
>         struct list_head thermal_instances;
> @@ -242,8 +243,31 @@ struct thermal_genl_event {
>  };
>
>  /* Function declarations */
> +#ifdef CONFIG_THERMAL_OF
> +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 *));
> +void thermal_zone_of_sensor_unregister(struct device *dev,
> +                                      struct thermal_zone_device *tz);
> +#else
> +static inline 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 *))
> +{
> +       return NULL;
> +}
> +
> +static inline
> +void thermal_zone_of_sensor_unregister(struct device *dev,
> +                                      struct thermal_zone_device *tz)
> +{
> +}
> +
> +#endif
>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
> -               void *, const struct thermal_zone_device_ops *,
> +               void *, struct thermal_zone_device_ops *,
>                 const struct thermal_zone_params *, int, int);
>  void thermal_zone_device_unregister(struct thermal_zone_device *);
>
> --
> 1.8.2.1.342.gfa7285d
>
>

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv8 03/18] thermal: introduce device tree parser
@ 2013-10-07 20:51       ` Mark Rutland
  0 siblings, 0 replies; 101+ messages in thread
From: Mark Rutland @ 2013-10-07 20:51 UTC (permalink / raw)
  To: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	grant.likely
  Cc: linux, rui.zhang, wni, durgadoss.r, linux-pm, devicetree,
	lm-sensors, linux-kernel

Hi all,

Given that this is a complex new class of binding, I'd appreciate if at least
one other device tree maintainer could also take a look over this and voice any
concerns or suggestions. I've left the entire patch context for this.

Apologies for the munged whitespace -- my mail server appears to have helpfully
and irreparably replaced all tabs with spaces.

On Tue, Oct 01, 2013 at 03:39:26AM +0100, Eduardo Valentin wrote:
> This patch introduces a device tree bindings for
> describing the hardware thermal behavior and limits.
> Also a parser to read and interpret the data and feed
> it in the thermal framework is presented.
>
> This patch introduces a thermal data parser for device
> tree. The parsed data is used to build thermal zones
> and thermal binding parameters. The output data
> can then be used to deploy thermal policies.
>
> This patch adds also documentation regarding this
> API and how to define tree nodes to use
> this infrastructure.
>
> Note that, in order to be able to have control
> on the sensor registration on the DT thermal zone,
> it was required to allow changing the thermal zone
> .get_temp callback. For this reason, this patch
> also removes the 'const' modifier from the .ops
> field of thermal zone devices.
>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
> Hello Mark, folks,
>
> So, here is v8. Pretty small changes. Most are better
> English phrasing in the binding document. It follows changelog:
> - Several rephrasing in the binding document, including
> spelling, grammar and better phrasing.
> - Removed WiP warning from binding document.
> - Several spacing and formatting changes in the binding document
> - Used the '-specifier' nomenclature properly in the binding doc
> - Removed the optional property 'thermal-sensors-names', because
> it does not provide useful runtime information
> - Fixed description of 'polling-delay-passive'
> - Improved examples by adding comments and better explanation
> - s/fw/framework/g
> - Added a WARN when sensors specifiers are greater and 1.
>
> All best,
>
> Eduardo
>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
>  drivers/thermal/thermal_core.c                     |   9 +-
>  drivers/thermal/thermal_core.h                     |   9 +
>  include/dt-bindings/thermal/thermal.h              |  27 +
>  include/linux/thermal.h                            |  28 +-
>  8 files changed, 1520 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>  create mode 100644 drivers/thermal/of-thermal.c
>  create mode 100644 include/dt-bindings/thermal/thermal.h
>
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..ad06a8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,587 @@
> +* Thermal Framework Device Tree descriptor
> +
> +This file describes a generic binding to provide a way of
> +defining hardware thermal structure using device tree.

s/defining/describing/

> +A thermal structure includes thermal zones and their components,
> +such as trip points, polling intervals, sensors and cooling devices
> +binding descriptors.
> +
> +The target of device tree thermal descriptors is to describe only
> +the hardware thermal aspects. The thermal device tree bindings are
> +not about how the system must control or which algorithm or policy
> +must be taken in place.

I'm not quite sure what this is saying -- it seems to contradict the
design of the binding where trip points get linked to cooling device
configuration, and thus we're defining a policy along the lines of "when
sensor $W hits temperature $X, configure cooling device $Y with value
$Z". I don't see how that can't be considered policy.

At best, we can say that policy is being defined because describing the
physical properties of a device and dealing with this at runtime is not
feasible.

> +
> +There are five types of nodes involved to describe thermal bindings:
> +- sensors: used to describe the device source of temperature sensing;

- thermal sensors: devices which may be used to take temperature
  measurements.

> +- cooling devices: used to describe devices source of power dissipation control;

- cooling devices: devices which may be used to dissipate heat.

> +- trip points: used to describe points in temperature domain defined to
> +make the system aware of hardware limits;

- trip points: describe key temperatures at which cooling is recommended. The
  set of points should be chosen based on hardware limits.

> +- cooling maps: used to describe links between trip points and cooling devices;
> +- thermal zones: used to describe thermal data within the hardware;
> +
> +It follows a description of each type of these device tree nodes.

How about:

The following is a description of each of these node types.

> +
> +* Thermal sensor devices
> +
> +Thermal sensor devices are nodes providing temperature sensing capabilities on
> +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
> +nodes providing temperature data to thermal zones. Thermal sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #thermal-sensor-cells: Used to provide sensor device specific information
> +  Type: unsigned        while referring to it. Typically 0 on thermal sensor
> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
> +                        with several internal sensors, in order
> +                        to identify uniquely the sensor instances within
> +                        the IC. See thermal zone binding for more details
> +                        on how consumers refer to sensor devices.
> +
> +* Cooling device nodes
> +
> +Cooling devices are nodes providing control on power dissipation. There
> +are essentially two ways to provide control on power dissipation. First
> +is by means of regulating device performance, which is known as passive
> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
> +frequency scaling (DVFS), and uses lower frequencies as cooling states.
> +Second is by means of activating devices in order to remove
> +the dissipated heat, which is known as active cooling, e.g. regulating
> +fan speeds. In both cases, cooling devices shall have a way to determine
> +the state of cooling in which the device is.

I'd probably say "heat dissipation" rather than "power dissipation", unless
this is a technical term I am not aware of?

Why is the determination of the state of the cooling device important?

> +
> +Required properties:
> +- cooling-min-state:   An integer indicating the smallest
> +  Type: unsigned       cooling state accepted. Typically 0.
> +  Size: one cell
> +
> +- cooling-max-state:   An integer indicating the largest
> +  Type: unsigned       cooling state accepted.
> +  Size: one cell
> +
> +- #cooling-cells:      Used to provide cooling device specific information
> +  Type: unsigned       while referring to it. Must be at least 2, in order
> +  Size: one cell       to specify minimum and maximum cooling state used
> +                       in the reference. The first cell is the minimum
> +                       cooling state requested and the second cell is
> +                       the maximum cooling state requested in the reference.
> +                       See Cooling device maps section below for more details
> +                       on how consumers refer to cooling devices.

Is it assumed that all the values between min and max are valid, or might this
be a sparse set of cooling values?

> +
> +* Trip points
> +
> +The trip node is a node to describe a point in the temperature domain
> +in which the system takes an action. This node describes just the point,
> +not the action.
> +
> +Required properties:
> +- temperature:         An integer indicating the trip temperature level,
> +  Type: signed         in millicelsius.
> +  Size: one cell
> +
> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
> +  Type: unsigned       relative value, in millicelsius.
> +  Size: one cell

What is it relative to?

Why is 'temperature' in quotes?

> +
> +- type:                        a string containing the trip type. Supported values are:
> +       "active":       A trip point to enable active cooling
> +       "passive":      A trip point to enable passive cooling
> +       "hot":          A trip point to notify emergency
> +       "critical":     Hardware not reliable.
> +  Type: string
> +
> +There are also string constants defined at
> +include/dt-bindings/thermal/thermal.h.

Why?

> +
> +* Cooling device maps
> +
> +The cooling device maps node is a node to describe how cooling devices
> +get assigned to trip points of the zone. The cooling devices are expected
> +to be loaded in the target system.
> +
> +Required properties:
> +- cooling-device:      A phandle of a cooling device with its specifier,
> +  Type: phandle of     referring to which cooling device is used in this
> +    cooling device     binding. In the cooling specifier, the first cell
> +                       is the minimum cooling state and the second cell
> +                       is the maximum cooling state used in this map.

The type is wrong here -- it's a phandle + cooling-cells, not just a phandle.

> +- trip:                        A phandle of a trip point node within the same thermal
> +  Type: phandle of     zone.
> +   trip point node
> +
> +Optional property:
> +- contribution:                The cooling contribution to the thermal zone of the
> +  Type: unsigned       referred cooling device at the referred trip point.
> +  Size: one cell       The contribution is a ratio of the sum
> +                       of all cooling contributions within a thermal zone.
> +
> +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
> +limit specifier means:
> +(i)   - minimum state allowed for minimum cooling state used in the reference.
> +(ii)  - maximum state allowed for maximum cooling state used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> +
> +* Thermal zone nodes
> +
> +The thermal zone node is the node containing all the required info
> +for describing a thermal zone, including its cooling device bindings. The
> +thermal zone node must contain, apart from its own properties, one sub-node
> +containing trip nodes and one sub-node containing all the zone cooling maps.
> +
> +Required properties:
> +- polling-delay:       The maximum number of milliseconds to wait between polls
> +  Type: unsigned       when checking this thermal zone.
> +  Size: one cell
> +
> +- polling-delay-passive: The maximum number of milliseconds to wait
> +  Type: unsigned       between polls when performing passive cooling.
> +  Size: one cell
> +
> +- thermal-sensors:     A list of thermal sensor phandles and sensor specifier
> +  Type: list of        used while monitoring the thermal zone.
> +  sensor phandles

The type is wrong here. A list of phandle + sensor specifiers.

> +
> +- trips:               A sub-node which is a container of only trip point nodes
> +  Type: sub-node       required to describe the thermal zone.
> +
> +- cooling-maps:                A sub-node which is a container of only cooling device
> +  Type: sub-node       map nodes, used to describe the relation between trips
> +                       and cooling devices.
> +
> +Optional property:
> +- coefficients:                An array of integers (one signed cell) containing
> +  Type: array          coefficients to compose a linear relation between
> +  Elem size: one cell  the sensors listed in the thermal-sensors property.
> +  Elem type: signed    Coefficients defaults to 1, in case this property
> +                       is not specified. A simple linear polynomial is used:
> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
> +
> +                       The coefficients are ordered and they match with sensors
> +                       by means of sensor ID. Additional coefficients are
> +                       interpreted as constant offset.
> +
> +Note: The delay properties are bound to the maximum dT/dt (temperature
> +derivative over time) in two situations for a thermal zone:
> +(i)  - when passive cooling is activated (polling-delay-passive); and
> +(ii) - when the zone just needs to be monitored (polling-delay) or
> +when active cooling is activated.
> +
> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
> +capability. The delays should be chosen to account for said max dT/dt,
> +such that a device does not cross several trip boundaries unexpectedly
> +between polls. Choosing the right polling delays shall avoid having the
> +device in temperature ranges that may damage the silicon structures and
> +reduce silicon lifetime.
> +
> +* The thermal-zones node
> +
> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
> +contain only sub-nodes describing thermal zones as in the section
> +"Thermal zone nodes". The "thermal-zones" node appears under "/".
> +
> +* Examples
> +
> +Below are several examples on how to use thermal data descriptors
> +using device tree bindings:
> +
> +(a) - CPU thermal zone
> +
> +The CPU thermal zone example below describes how to setup one thermal zone
> +using one single sensor as temperature source and many cooling devices and
> +power dissipation control sources.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +cpus {
> +       /*
> +        * Here is an example of describing a cooling device for a DVFS
> +        * capable CPU. The CPU node describes its four OPPs.
> +        * The cooling states possible are 0..3, and they are
> +        * used as OPP indexes. The minimum cooling state is 0, which means
> +        * all four OPPs can be available to the system. The maximum
> +        * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
> +        * can be available in the system.
> +        */
> +       cpu0: cpu@0 {
> +               ...
> +               operating-points = <
> +                       /* kHz    uV */
> +                       970000  1200000
> +                       792000  1100000
> +                       396000  950000
> +                       198000  850000
> +               >;
> +               cooling-min-state = <0>;
> +               cooling-max-state = <3>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +       ...
> +};
> +
> +&i2c1 {
> +       ...
> +       /*
> +        * A simple fan controller which supports 10 speeds of operation
> +        * (represented as 0-9).
> +        */
> +       fan0: fan@0x48 {
> +               ...
> +               cooling-min-state = <0>;
> +               cooling-max-state = <9>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };
> +};
> +
> +ocp {
> +       ...
> +       /*
> +        * A simple IC with a single bandgap temperature sensor.
> +        */
> +       bandgap0: bandgap@0x0000ED00 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +thermal-zones {
> +       cpu-thermal: cpu-thermal {
> +               polling-delay-passive = <250>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +               thermal-sensors = <&bandgap0>;
> +
> +               trips {
> +                       cpu-alert0: cpu-alert {
> +                               temperature = <90000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "active";
> +                       };
> +                       cpu-alert1: cpu-alert {
> +                               temperature = <100000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       cpu-crit: cpu-crit {
> +                               temperature = <125000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       map0 {
> +                               trip = <&cpu-alert0>;
> +                               cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +                       };
> +                       map1 {
> +                               trip = <&cpu-alert1>;
> +                               cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +                       };
> +                       map2 {
> +                               trip = <&cpu-alert1>;
> +                               cooling-device > +                                   <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
> +                       };
> +               };
> +       };
> +};
> +
> +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
> +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
> +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
> +different cooling states 0-9. It is used to remove the heat out of
> +the thermal zone 'cpu-thermal' using its cooling states
> +from its minimum to 4, when it reaches trip point 'cpu-alert0'
> +at 90C, as an example of active cooling. The same cooling device is used at
> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
> +using all its cooling states at trip point 'cpu-alert1',
> +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
> +temperature of 125C, represented by the trip point 'cpu-crit', the silicon
> +is not reliable anymore.
> +
> +(b) - IC with several internal sensors
> +
> +The example below describes how to deploy several thermal zones based off a
> +single sensor IC, assuming it has several internal sensors. This is a common
> +case on SoC designs with several internal IPs that may need different thermal
> +requirements, and thus may have their own sensor to monitor or detect internal
> +hotspots in their silicon.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +ocp {
> +       ...
> +       /*
> +        * A simple IC with several bandgap temperature sensors.
> +        */
> +       bandgap0: bandgap@0x0000ED00 {
> +               ...
> +               #thermal-sensor-cells = <1>;
> +       };
> +};
> +
> +thermal-zones {
> +       cpu-thermal: cpu-thermal {
> +               polling-delay-passive = <250>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&bandgap0     0>;
> +
> +               trips {
> +                       /* each zone within the SoC may have its own trips */
> +                       cpu-alert: cpu-alert {
> +                               temperature = <100000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       cpu-crit: cpu-crit {
> +                               temperature = <125000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       /* each zone within the SoC may have its own cooling */
> +                       ...
> +               };
> +       };
> +
> +       gpu-thermal: gpu-thermal {
> +               polling-delay-passive = <120>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&bandgap0     1>;
> +
> +               trips {
> +                       /* each zone within the SoC may have its own trips */
> +                       gpu-alert: gpu-alert {
> +                               temperature = <90000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       gpu-crit: gpu-crit {
> +                               temperature = <105000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       /* each zone within the SoC may have its own cooling */
> +                       ...
> +               };
> +       };
> +
> +       dsp-thermal: dsp-thermal {
> +               polling-delay-passive = <50>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&bandgap0     2>;
> +
> +               trips {
> +                       /* each zone within the SoC may have its own trips */
> +                       dsp-alert: gpu-alert {
> +                               temperature = <90000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       dsp-crit: gpu-crit {
> +                               temperature = <135000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       /* each zone within the SoC may have its own cooling */
> +                       ...
> +               };
> +       };
> +};
> +
> +In the example above, there is one bandgap IC which has the capability to
> +monitor three sensors. The hardware has been designed so that sensors are
> +placed on different places in the DIE to monitor different temperature
> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
> +other to monitor a DSP thermal zone.
> +
> +Thus, there is a need to assign each sensor provided by the bandgap IC
> +to different thermal zones. This is achieved by means of using the
> +#thermal-sensor-cells property and using the first cell of the sensor
> +specifier as sensor ID. In the example, then, <bandgap 0> is used to
> +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
> +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
> +may be uncorrelated, having its own dT/dt requirements, trips
> +and cooling maps.
> +
> +
> +(c) - Several sensors within one single thermal zone
> +
> +The example below illustrates how to use more than one sensor within
> +one thermal zone.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&i2c1 {
> +       ...
> +       /*
> +        * A simple IC with a single temperature sensor.
> +        */
> +       adc: sensor@0x49 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +ocp {
> +       ...
> +       /*
> +        * A simple IC with a single bandgap temperature sensor.
> +        */
> +       bandgap0: bandgap@0x0000ED00 {
> +               ...
> +               #thermal-sensor-cells = <0>;
> +       };
> +};
> +
> +thermal-zones {
> +       cpu-thermal: cpu-thermal {
> +               polling-delay-passive = <250>; /* milliseconds */
> +               polling-delay = <1000>; /* milliseconds */
> +
> +               thermal-sensors = <&bandgap0>,  /* cpu */
> +                                 <&adc>;       /* pcb north */
> +
> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
> +               coefficients =          <100    -120    484>;
> +
> +               trips {
> +                       ...
> +               };
> +
> +               cooling-maps {
> +                       ...
> +               };
> +       };
> +};
> +
> +In some cases, there is a need to use more than one sensor to extrapolate
> +a thermal hotspot in the silicon. The above example illustrates this situation.
> +For instance, it may be the case that a sensor external to CPU IP may be placed
> +close to CPU hotspot and together with internal CPU sensor, it is used
> +to determine the hotspot. Assuming this is the case for the above example,
> +the hypothetical extrapolation rule would be:
> +               hotspot = 100 * bandgap - 120 * adc + 484
> +
> +In other context, the same idea can be used to add fixed offset. For instance,
> +consider the hotspot extrapolation rule below:
> +               hotspot = 1 * adc + 6000
> +
> +In the above equation, the hotspot is always 6C higher than what is read
> +from the ADC sensor. The binding would be then:
> +        thermal-sensors =  <&adc>;
> +
> +               /* hotspot = 1 * adc + 6000 */
> +       coefficients =          <1      6000>;
> +
> +(d) - Board thermal
> +
> +The board thermal example below illustrates how to setup one thermal zone
> +with many sensors and many cooling devices.
> +
> +#include <dt-bindings/thermal/thermal.h>
> +
> +&i2c1 {
> +       ...
> +       /*
> +        * An IC with several temperature sensor.
> +        */
> +       adc-dummy: sensor@0x50 {
> +               ...
> +               #thermal-sensor-cells = <1>; /* sensor internal ID */
> +       };
> +};
> +
> +thermal-zones {
> +       batt-thermal {
> +               polling-delay-passive = <500>; /* milliseconds */
> +               polling-delay = <2500>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&adc-dummy     4>;
> +
> +               trips {
> +                       ...
> +               };
> +
> +               cooling-maps {
> +                       ...
> +               };
> +       };
> +
> +       board-thermal: board-thermal {
> +               polling-delay-passive = <1000>; /* milliseconds */
> +               polling-delay = <2500>; /* milliseconds */
> +
> +                               /* sensor       ID */
> +               thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
> +                                 <&adc-dummy     1>, /* lcd */
> +                                 <&adc-dymmy     2>; /* back cover */
> +               /*
> +                * An array of coefficients describing the sensor
> +                * linear relation. E.g.:
> +                * z = c1*x1 + c2*x2 + c3*x3
> +                */
> +               coefficients =          <1200   -345    890>;
> +
> +               trips {
> +                       /* Trips are based on resulting linear equation */
> +                       cpu-trip: cpu-trip {
> +                               temperature = <60000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       gpu-trip: gpu-trip {
> +                               temperature = <55000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       }
> +                       lcd-trip: lcp-trip {
> +                               temperature = <53000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "passive";
> +                       };
> +                       crit-trip: crit-trip {
> +                               temperature = <68000>; /* millicelsius */
> +                               hysteresis = <2000>; /* millicelsius */
> +                               type = "critical";
> +                       };
> +               };
> +
> +               cooling-maps {
> +                       map0 {
> +                               trip = <&cpu-trip>;
> +                               cooling-device = <&cpu0 0 2>;
> +                               contribution = <55>;
> +                       };
> +                       map1 {
> +                               trip = <&gpu-trip>;
> +                               cooling-device = <&gpu0 0 2>;
> +                               contribution = <20>;
> +                       };
> +                       map2 {
> +                               trip = <&lcd-trip>;
> +                               cooling-device = <&lcd0 5 10>;
> +                               contribution = <15>;
> +                       };
> +               };
> +       };
> +};
> +
> +The above example is a mix of previous examples, a sensor IP with several internal
> +sensors used to monitor different zones, one of them is composed by several sensors and
> +with different cooling devices.
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index dbfc390..dd81eb8 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -29,6 +29,19 @@ config THERMAL_HWMON
>           Say 'Y' here if you want all thermal sensors to
>           have hwmon sysfs interface too.
>
> +config THERMAL_OF
> +       bool
> +       prompt "APIs to parse thermal data out of device tree"
> +       depends on OF
> +       default y
> +       help
> +         This options provides helpers to add the support to
> +         read and parse thermal data definitions out of the
> +         device tree blob.
> +
> +         Say 'Y' here if you need to build thermal infrastructure
> +         based on device tree.
> +
>  choice
>         prompt "Default Thermal governor"
>         default THERMAL_DEFAULT_GOV_STEP_WISE
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 584b363..4b03956 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -7,6 +7,7 @@ thermal_sys-y                   += thermal_core.o
>
>  # interface to/from other layers providing sensors
>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
> +thermal_sys-$(CONFIG_THERMAL_OF)               += of-thermal.o
>
>  # governors
>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> new file mode 100644
> index 0000000..66f9eb2
> --- /dev/null
> +++ b/drivers/thermal/of-thermal.c
> @@ -0,0 +1,849 @@
> +/*
> + *  of-thermal.c - Generic Thermal Management device tree support.
> + *
> + *  Copyright (C) 2013 Texas Instruments
> + *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
> + *
> + *
> + *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; version 2 of the License.
> + *
> + *  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.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +#include <linux/thermal.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/string.h>
> +
> +#include "thermal_core.h"
> +
> +/***   Private data structures to represent thermal device tree data ***/
> +
> +/**
> + * struct __thermal_trip - representation of a point in temperature domain
> + * @np: pointer to struct device_node that this trip point was created from
> + * @temperature: temperature value in miliCelsius
> + * @hysteresis: relative hysteresis in miliCelsius
> + * @type: trip point type
> + */
> +
> +struct __thermal_trip {
> +       struct device_node *np;
> +       unsigned long int temperature;
> +       unsigned long int hysteresis;
> +       enum thermal_trip_type type;
> +};
> +
> +/**
> + * struct __thermal_bind_param - a match between trip and cooling device
> + * @cooling_device: a pointer to identify the referred cooling device
> + * @trip_id: the trip point index
> + * @usage: the percentage (from 0 to 100) of cooling contribution
> + * @min: minimum cooling state used at this trip point
> + * @max: maximum cooling state used at this trip point
> + */
> +
> +struct __thermal_bind_params {
> +       struct device_node *cooling_device;
> +       unsigned int trip_id;
> +       unsigned int usage;
> +       unsigned long min;
> +       unsigned long max;
> +};
> +
> +/**
> + * struct __thermal_zone - internal representation of a thermal zone
> + * @mode: current thermal zone device mode (enabled/disabled)
> + * @passive_delay: polling interval while passive cooling is activated
> + * @polling_delay: zone polling interval
> + * @ntrips: number of trip points
> + * @trips: an array of trip points (0..ntrips - 1)
> + * @num_tbps: number of thermal bind params
> + * @tbps: an array of thermal bind params (0..num_tbps - 1)
> + * @sensor_data: sensor private data used while reading temperature and trend
> + * @get_temp: sensor callback to read temperature
> + * @get_trend: sensor callback to read temperature trend
> + */
> +
> +struct __thermal_zone {
> +       enum thermal_device_mode mode;
> +       int passive_delay;
> +       int polling_delay;
> +
> +       /* trip data */
> +       int ntrips;
> +       struct __thermal_trip *trips;
> +
> +       /* cooling binding data */
> +       int num_tbps;
> +       struct __thermal_bind_params *tbps;
> +
> +       /* sensor interface */
> +       void *sensor_data;
> +       int (*get_temp)(void *, long *);
> +       int (*get_trend)(void *, long *);
> +};
> +
> +/***   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;
> +
> +       if (!data->get_temp)
> +               return -EINVAL;
> +
> +       return data->get_temp(data->sensor_data, temp);
> +}
> +
> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
> +                               enum thermal_trend *trend)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +       long dev_trend;
> +       int r;
> +
> +       if (!data->get_trend)
> +               return -EINVAL;
> +
> +       r = data->get_trend(data->sensor_data, &dev_trend);
> +       if (r)
> +               return r;
> +
> +       /* TODO: These intervals might have some thresholds, but in core code */
> +       if (dev_trend > 0)
> +               *trend = THERMAL_TREND_RAISING;
> +       else if (dev_trend < 0)
> +               *trend = THERMAL_TREND_DROPPING;
> +       else
> +               *trend = THERMAL_TREND_STABLE;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_bind(struct thermal_zone_device *thermal,
> +                          struct thermal_cooling_device *cdev)
> +{
> +       struct __thermal_zone *data = thermal->devdata;
> +       int i;
> +
> +       if (!data || IS_ERR(data))
> +               return -ENODEV;
> +
> +       /* find where to bind */
> +       for (i = 0; i < data->num_tbps; i++) {
> +               struct __thermal_bind_params *tbp = data->tbps + i;
> +
> +               if (tbp->cooling_device = cdev->np) {
> +                       int ret;
> +
> +                       ret = thermal_zone_bind_cooling_device(thermal,
> +                                               tbp->trip_id, cdev,
> +                                               tbp->min,
> +                                               tbp->max);
> +                       if (ret)
> +                               return ret;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
> +static int of_thermal_unbind(struct thermal_zone_device *thermal,
> +                            struct thermal_cooling_device *cdev)
> +{
> +       struct __thermal_zone *data = thermal->devdata;
> +       int i;
> +
> +       if (!data || IS_ERR(data))
> +               return -ENODEV;
> +
> +       /* find where to unbind */
> +       for (i = 0; i < data->num_tbps; i++) {
> +               struct __thermal_bind_params *tbp = data->tbps + i;
> +
> +               if (tbp->cooling_device = cdev->np) {
> +                       int ret;
> +
> +                       ret = thermal_zone_unbind_cooling_device(thermal,
> +                                               tbp->trip_id, cdev);
> +                       if (ret)
> +                               return ret;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_mode(struct thermal_zone_device *tz,
> +                              enum thermal_device_mode *mode)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       *mode = data->mode;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_set_mode(struct thermal_zone_device *tz,
> +                              enum thermal_device_mode mode)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       mutex_lock(&tz->lock);
> +
> +       if (mode = THERMAL_DEVICE_ENABLED)
> +               tz->polling_delay = data->polling_delay;
> +       else
> +               tz->polling_delay = 0;
> +
> +       mutex_unlock(&tz->lock);
> +
> +       data->mode = mode;
> +       thermal_zone_device_update(tz);
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
> +                                   enum thermal_trip_type *type)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       *type = data->trips[trip].type;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long *temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       *temp = data->trips[trip].temperature;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       /* thermal framework should take care of data->mask & (1 << trip) */
> +       data->trips[trip].temperature = temp;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long *hyst)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       *hyst = data->trips[trip].hysteresis;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
> +                                   unsigned long hyst)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +
> +       if (trip >= data->ntrips || trip < 0)
> +               return -EDOM;
> +
> +       /* thermal framework should take care of data->mask & (1 << trip) */
> +       data->trips[trip].hysteresis = hyst;
> +
> +       return 0;
> +}
> +
> +static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
> +                                   unsigned long *temp)
> +{
> +       struct __thermal_zone *data = tz->devdata;
> +       int i;
> +
> +       for (i = 0; i < data->ntrips; i++)
> +               if (data->trips[i].type = THERMAL_TRIP_CRITICAL) {
> +                       *temp = data->trips[i].temperature;
> +                       return 0;
> +               }
> +
> +       return -EINVAL;
> +}
> +
> +static struct thermal_zone_device_ops of_thermal_ops = {
> +       .get_mode = of_thermal_get_mode,
> +       .set_mode = of_thermal_set_mode,
> +
> +       .get_trip_type = of_thermal_get_trip_type,
> +       .get_trip_temp = of_thermal_get_trip_temp,
> +       .set_trip_temp = of_thermal_set_trip_temp,
> +       .get_trip_hyst = of_thermal_get_trip_hyst,
> +       .set_trip_hyst = of_thermal_set_trip_hyst,
> +       .get_crit_temp = of_thermal_get_crit_temp,
> +
> +       .bind = of_thermal_bind,
> +       .unbind = of_thermal_unbind,
> +};
> +
> +/***   sensor API   ***/
> +
> +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 *))
> +{
> +       struct thermal_zone_device *tzd;
> +       struct __thermal_zone *tz;
> +
> +       tzd = thermal_zone_get_zone_by_name(zone->name);
> +       if (IS_ERR(tzd))
> +               return ERR_PTR(-EPROBE_DEFER);
> +
> +       tz = tzd->devdata;
> +
> +       mutex_lock(&tzd->lock);
> +       tz->get_temp = get_temp;
> +       tz->get_trend = get_trend;
> +       tz->sensor_data = data;
> +
> +       tzd->ops->get_temp = of_thermal_get_temp;
> +       tzd->ops->get_trend = of_thermal_get_trend;
> +       mutex_unlock(&tzd->lock);
> +
> +       return tzd;
> +}
> +
> +/**
> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
> + * @dev: a valid struct device pointer of a sensor device. Must contain
> + *       a valid .of_node, for the sensor node.
> + * @sensor_id: a sensor identifier, in case the sensor IP has more
> + *             than one sensors
> + * @data: a private pointer (owned by the caller) that will be passed
> + *        back, when a temperature reading is needed.
> + * @get_temp: a pointer to a function that reads the sensor temperature.
> + * @get_trend: a pointer to a function that reads the sensor temperature trend.
> + *
> + * This function will search the list of thermal zones described in device
> + * tree and look for the zone that refer to the sensor device pointed by
> + * @dev->of_node as temperature providers. For the zone pointing to the
> + * sensor node, the sensor will be added to the DT thermal zone device.
> + *
> + * The thermal zone temperature is provided by the @get_temp function
> + * pointer. When called, it will have the private pointer @data back.
> + *
> + * The thermal zone temperature trend is provided by the @get_trend function
> + * pointer. When called, it will have the private pointer @data back.
> + *
> + * TODO:
> + * 01 - This function must enqueue the new sensor instead of using
> + * it as the only source of temperature values.
> + *
> + * 02 - There must be a way to match the sensor with all thermal zones
> + * that refer to it.
> + *
> + * Return: On success returns a valid struct thermal_zone_device,
> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
> + * check the return value with help of IS_ERR() helper.
> + */
> +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 *))
> +{
> +       struct device_node *np, *child, *sensor_np;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np)
> +               return ERR_PTR(-ENODEV);
> +
> +       if (!dev || !dev->of_node)
> +               return ERR_PTR(-EINVAL);
> +
> +       sensor_np = dev->of_node;
> +
> +       for_each_child_of_node(np, child) {
> +               struct of_phandle_args sensor_specs;
> +               int ret, id;
> +
> +               /* For now, thermal framework supports only 1 sensor per zone */
> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
> +                                                "#thermal-sensor-cells",
> +                                                0, &sensor_specs);
> +               if (ret)
> +                       continue;
> +
> +               if (sensor_specs.args_count >= 1) {
> +                       id = sensor_specs.args[0];
> +                       WARN(sensor_specs.args_count > 1,
> +                            "%s: too many cells in sensor specifier %d\n",
> +                            sensor_specs.np->name, sensor_specs.args_count);
> +               } else {
> +                       id = 0;
> +               }
> +
> +               if (sensor_specs.np = sensor_np && id = sensor_id) {
> +                       of_node_put(np);
> +                       return thermal_zone_of_add_sensor(child, sensor_np,
> +                                                         data,
> +                                                         get_temp,
> +                                                         get_trend);
> +               }
> +       }
> +       of_node_put(np);
> +
> +       return ERR_PTR(-ENODEV);
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
> +
> +/**
> + * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
> + * @dev: a valid struct device pointer of a sensor device. Must contain
> + *       a valid .of_node, for the sensor node.
> + * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
> + *
> + * This function removes the sensor callbacks and private data from the
> + * thermal zone device registered with thermal_zone_of_sensor_register()
> + * API. It will also silent the zone by remove the .get_temp() and .get_trend()
> + * thermal zone device callbacks.
> + *
> + * TODO: When the support to several sensors per zone is added, this
> + * function must search the sensor list based on @dev parameter.
> + *
> + */
> +void thermal_zone_of_sensor_unregister(struct device *dev,
> +                                      struct thermal_zone_device *tzd)
> +{
> +       struct __thermal_zone *tz;
> +
> +       if (!dev || !tzd || !tzd->devdata)
> +               return;
> +
> +       tz = tzd->devdata;
> +
> +       /* no __thermal_zone, nothing to be done */
> +       if (!tz)
> +               return;
> +
> +       mutex_lock(&tzd->lock);
> +       tzd->ops->get_temp = NULL;
> +       tzd->ops->get_trend = NULL;
> +
> +       tz->get_temp = NULL;
> +       tz->get_trend = NULL;
> +       tz->sensor_data = NULL;
> +       mutex_unlock(&tzd->lock);
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
> +
> +/***   functions parsing device tree nodes   ***/
> +
> +/**
> + * thermal_of_populate_bind_params - parse and fill cooling map data
> + * @np: DT node containing a cooling-map node
> + * @__tbp: data structure to be filled with cooling map info
> + * @trips: array of thermal zone trip points
> + * @ntrips: number of trip points inside trips.
> + *
> + * This function parses a cooling-map type of node represented by
> + * @np parameter and fills the read data into @__tbp data structure.
> + * It needs the already parsed array of trip points of the thermal zone
> + * in consideration.
> + *
> + * Return: 0 on success, proper error code otherwise
> + */
> +static int thermal_of_populate_bind_params(struct device_node *np,
> +                                          struct __thermal_bind_params *__tbp,
> +                                          struct __thermal_trip *trips,
> +                                          int ntrips)
> +{
> +       struct of_phandle_args cooling_spec;
> +       struct device_node *trip;
> +       int ret, i;
> +       u32 prop;
> +
> +       /* Default weight. Usage is optional */
> +       __tbp->usage = 0;
> +       ret = of_property_read_u32(np, "contribution", &prop);
> +       if (ret = 0)
> +               __tbp->usage = prop;
> +
> +       trip = of_parse_phandle(np, "trip", 0);
> +       if (!trip) {
> +               pr_err("missing trip property\n");
> +               return -ENODEV;
> +       }
> +
> +       /* match using device_node */
> +       for (i = 0; i < ntrips; i++)
> +               if (trip = trips[i].np) {
> +                       __tbp->trip_id = i;
> +                       break;
> +               }
> +
> +       if (i = ntrips) {
> +               ret = -ENODEV;
> +               goto end;
> +       }
> +
> +       ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
> +                                        0, &cooling_spec);
> +       if (ret < 0) {
> +               pr_err("missing cooling_device property\n");
> +               goto end;
> +       }
> +       __tbp->cooling_device = cooling_spec.np;
> +       if (cooling_spec.args_count >= 2) { /* at least min and max */
> +               __tbp->min = cooling_spec.args[0];
> +               __tbp->max = cooling_spec.args[1];
> +       } else {
> +               pr_err("wrong reference to cooling device, missing limits\n");
> +       }
> +
> +end:
> +       of_node_put(trip);
> +
> +       return ret;
> +}
> +
> +/**
> + * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
> + * into the device tree binding of 'trip', property type.
> + */
> +static const char * const trip_types[] = {
> +       [THERMAL_TRIP_ACTIVE]   = "active",
> +       [THERMAL_TRIP_PASSIVE]  = "passive",
> +       [THERMAL_TRIP_HOT]      = "hot",
> +       [THERMAL_TRIP_CRITICAL] = "critical",
> +};
> +
> +/**
> + * thermal_of_get_trip_type - Get phy mode for given device_node
> + * @np:        Pointer to the given device_node
> + * @type: Pointer to resulting trip type
> + *
> + * The function gets trip type string from property 'type',
> + * and store its index in trip_types table in @type,
> + *
> + * Return: 0 on success, or errno in error case.
> + */
> +static int thermal_of_get_trip_type(struct device_node *np,
> +                                   enum thermal_trip_type *type)
> +{
> +       const char *t;
> +       int err, i;
> +
> +       err = of_property_read_string(np, "type", &t);
> +       if (err < 0)
> +               return err;
> +
> +       for (i = 0; i < ARRAY_SIZE(trip_types); i++)
> +               if (!strcasecmp(t, trip_types[i])) {
> +                       *type = i;
> +                       return 0;
> +               }
> +
> +       return -ENODEV;
> +}
> +
> +/**
> + * thermal_of_populate_trip - parse and fill one trip point data
> + * @np: DT node containing a trip point node
> + * @trip: trip point data structure to be filled up
> + *
> + * This function parses a trip point type of node represented by
> + * @np parameter and fills the read data into @trip data structure.
> + *
> + * Return: 0 on success, proper error code otherwise
> + */
> +static int thermal_of_populate_trip(struct device_node *np,
> +                                   struct __thermal_trip *trip)
> +{
> +       int prop;
> +       int ret;
> +
> +       ret = of_property_read_u32(np, "temperature", &prop);
> +       if (ret < 0) {
> +               pr_err("missing temperature property\n");
> +               return ret;
> +       }
> +       trip->temperature = prop;
> +
> +       ret = of_property_read_u32(np, "hysteresis", &prop);
> +       if (ret < 0) {
> +               pr_err("missing hysteresis property\n");
> +               return ret;
> +       }
> +       trip->hysteresis = prop;
> +
> +       ret = thermal_of_get_trip_type(np, &trip->type);
> +       if (ret < 0) {
> +               pr_err("wrong trip type property\n");
> +               return ret;
> +       }
> +
> +       /* Required for cooling map matching */
> +       trip->np = np;
> +
> +       return 0;
> +}
> +
> +/**
> + * thermal_of_build_thermal_zone - parse and fill one thermal zone data
> + * @np: DT node containing a thermal zone node
> + *
> + * This function parses a thermal zone type of node represented by
> + * @np parameter and fills the read data into a __thermal_zone data structure
> + * and return this pointer.
> + *
> + * TODO: Missing properties to parse: thermal-sensor-names and coefficients
> + *
> + * Return: On success returns a valid struct __thermal_zone,
> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
> + * check the return value with help of IS_ERR() helper.
> + */
> +static struct __thermal_zone *
> +thermal_of_build_thermal_zone(struct device_node *np)
> +{
> +       struct device_node *child = NULL, *gchild;
> +       struct __thermal_zone *tz;
> +       int ret, i;
> +       u32 prop;
> +
> +       if (!np) {
> +               pr_err("no thermal zone np\n");
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       tz = kzalloc(sizeof(*tz), GFP_KERNEL);
> +       if (!tz)
> +               return ERR_PTR(-ENOMEM);
> +
> +       ret = of_property_read_u32(np, "polling-delay-passive", &prop);
> +       if (ret < 0) {
> +               pr_err("missing polling-delay-passive property\n");
> +               goto free_tz;
> +       }
> +       tz->passive_delay = prop;
> +
> +       ret = of_property_read_u32(np, "polling-delay", &prop);
> +       if (ret < 0) {
> +               pr_err("missing polling-delay property\n");
> +               goto free_tz;
> +       }
> +       tz->polling_delay = prop;
> +
> +       /* trips */
> +       child = of_get_child_by_name(np, "trips");
> +
> +       /* No trips provided */
> +       if (!child)
> +               goto finish;
> +
> +       tz->ntrips = of_get_child_count(child);
> +       if (tz->ntrips = 0) /* must have at least one child */
> +               goto finish;
> +
> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
> +       if (!tz->trips) {
> +               ret = -ENOMEM;
> +               goto free_tz;
> +       }
> +
> +       i = 0;
> +       for_each_child_of_node(child, gchild) {
> +               ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
> +               if (ret)
> +                       goto free_trips;
> +       }
> +
> +       of_node_put(child);
> +
> +       /* cooling-maps */
> +       child = of_get_child_by_name(np, "cooling-maps");
> +
> +       /* cooling-maps not provided */
> +       if (!child)
> +               goto finish;
> +
> +       tz->num_tbps = of_get_child_count(child);
> +       if (tz->num_tbps = 0)
> +               goto finish;
> +
> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
> +       if (!tz->tbps) {
> +               ret = -ENOMEM;
> +               goto free_trips;
> +       }
> +
> +       i = 0;
> +       for_each_child_of_node(child, gchild)
> +               ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
> +                                                     tz->trips, tz->ntrips);
> +               if (ret)
> +                       goto free_tbps;
> +
> +finish:
> +       of_node_put(child);
> +       tz->mode = THERMAL_DEVICE_DISABLED;
> +
> +       return tz;
> +
> +free_tbps:
> +       kfree(tz->tbps);
> +free_trips:
> +       kfree(tz->trips);
> +free_tz:
> +       kfree(tz);
> +       of_node_put(child);
> +
> +       return ERR_PTR(ret);
> +}
> +
> +static inline void of_thermal_free_zone(struct __thermal_zone *tz)
> +{
> +       kfree(tz->tbps);
> +       kfree(tz->trips);
> +       kfree(tz);
> +}
> +
> +/**
> + * of_parse_thermal_zones - parse device tree thermal data
> + *
> + * Initialization function that can be called by machine initialization
> + * code to parse thermal data and populate the thermal framework
> + * with hardware thermal zones info. This function only parses thermal zones.
> + * Cooling devices and sensor devices nodes are supposed to be parsed
> + * by their respective drivers.
> + *
> + * Return: 0 on success, proper error code otherwise
> + *
> + */
> +int __init of_parse_thermal_zones(void)
> +{
> +       struct device_node *np, *child;
> +       struct __thermal_zone *tz;
> +       struct thermal_zone_device_ops *ops;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np) {
> +               pr_debug("unable to find thermal zones\n");
> +               return 0; /* Run successfully on systems without thermal DT */
> +       }
> +
> +       for_each_child_of_node(np, child) {
> +               struct thermal_zone_device *zone;
> +               struct thermal_zone_params *tzp;
> +
> +               tz = thermal_of_build_thermal_zone(child);
> +               if (IS_ERR(tz)) {
> +                       pr_err("failed to build thermal zone %s: %ld\n",
> +                              child->name,
> +                              PTR_ERR(tz));
> +                       continue;
> +               }
> +
> +               ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
> +               if (!ops)
> +                       goto exit_free;
> +
> +               tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +               if (!tzp) {
> +                       kfree(ops);
> +                       goto exit_free;
> +               }
> +
> +               /* No hwmon because there might be hwmon drivers registering */
> +               tzp->no_hwmon = true;
> +
> +               zone = thermal_zone_device_register(child->name, tz->ntrips,
> +                                                   0, tz,
> +                                                   ops, tzp,
> +                                                   tz->passive_delay,
> +                                                   tz->polling_delay);
> +               if (IS_ERR(zone)) {
> +                       pr_err("Failed to build %s zone %ld\n", child->name,
> +                              PTR_ERR(zone));
> +                       kfree(tzp);
> +                       kfree(ops);
> +                       of_thermal_free_zone(tz);
> +                       /* attempting to build remaining zones still */
> +               }
> +       }
> +
> +       return 0;
> +
> +exit_free:
> +       of_thermal_free_zone(tz);
> +
> +       /* no memory available, so free what we have built */
> +       of_thermal_destroy_zones();
> +
> +       return -ENOMEM;
> +}
> +
> +/**
> + * of_thermal_destroy_zones - remove all zones parsed and allocated resources
> + *
> + * Finds all zones parsed and added to the thermal framework and remove them
> + * from the system, together with their resources.
> + *
> + */
> +void __exit of_thermal_destroy_zones(void)
> +{
> +       struct device_node *np, *child;
> +
> +       np = of_find_node_by_name(NULL, "thermal-zones");
> +       if (!np) {
> +               pr_err("unable to find thermal zones\n");
> +               return;
> +       }
> +
> +       for_each_child_of_node(np, child) {
> +               struct thermal_zone_device *zone;
> +
> +               zone = thermal_zone_get_zone_by_name(child->name);
> +               if (IS_ERR(zone))
> +                       continue;
> +
> +               thermal_zone_device_unregister(zone);
> +               kfree(zone->tzp);
> +               kfree(zone->ops);
> +               of_thermal_free_zone(zone->devdata);
> +       }
> +}
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index f7a9f4f..fec3351 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
>   */
>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
>         int trips, int mask, void *devdata,
> -       const struct thermal_zone_device_ops *ops,
> +       struct thermal_zone_device_ops *ops,
>         const struct thermal_zone_params *tzp,
>         int passive_delay, int polling_delay)
>  {
> @@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
>         if (result)
>                 goto unregister_class;
>
> +       result = of_parse_thermal_zones();
> +       if (result)
> +               goto exit_netlink;
> +
>         return 0;
>
> +exit_netlink:
> +       genetlink_exit();
>  unregister_governors:
>         thermal_unregister_governors();
>  unregister_class:
> @@ -1768,6 +1774,7 @@ error:
>
>  static void __exit thermal_exit(void)
>  {
> +       of_thermal_destroy_zones();
>         genetlink_exit();
>         class_unregister(&thermal_class);
>         thermal_unregister_governors();
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index 7cf2f66..3db339f 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
>  static inline void thermal_gov_user_space_unregister(void) {}
>  #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
>
> +/* device tree support */
> +#ifdef CONFIG_THERMAL_OF
> +int of_parse_thermal_zones(void);
> +void of_thermal_destroy_zones(void);
> +#else
> +static inline int of_parse_thermal_zones(void) { return 0; }
> +static inline void of_thermal_destroy_zones(void) { }
> +#endif
> +
>  #endif /* __THERMAL_CORE_H__ */
> diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
> new file mode 100644
> index 0000000..59c4581
> --- /dev/null
> +++ b/include/dt-bindings/thermal/thermal.h
> @@ -0,0 +1,27 @@
> +/*
> + * This header provides constants for most thermal bindings.
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *     Eduardo Valentin <eduardo.valentin@ti.com>
> + *
> + * GPLv2 only
> + */
> +
> +#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
> +#define _DT_BINDINGS_THERMAL_THERMAL_H
> +
> +/*
> + * Here are the thermal trip types. This must
> + * match with enum thermal_trip_type at
> + * include/linux/thermal.h
> + */
> +#define THERMAL_TRIP_ACTIVE            "active"
> +#define THERMAL_TRIP_PASSIVE           "passive"
> +#define THERMAL_TRIP_HOT               "hot"
> +#define THERMAL_TRIP_CRITICAL          "critical"

I don't like this. If someone wants to include this in a C file they can't do so
at the same time as include/linux/thermal.h. The defined names are longer than
the actual string values, and the comment makes it sound like these could be
modified rather than being a fixed ABI.

I do not see the point of these constants.

Thanks,
Mark.

> +
> +/* On cooling devices upper and lower limits */
> +#define THERMAL_NO_LIMIT               (-1UL)
> +
> +#endif
> +
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index b268d3c..b780c5b 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -143,6 +143,7 @@ struct thermal_cooling_device {
>         int id;
>         char type[THERMAL_NAME_LENGTH];
>         struct device device;
> +       struct device_node *np;
>         void *devdata;
>         const struct thermal_cooling_device_ops *ops;
>         bool updated; /* true if the cooling device does not need update */
> @@ -172,7 +173,7 @@ struct thermal_zone_device {
>         int emul_temperature;
>         int passive;
>         unsigned int forced_passive;
> -       const struct thermal_zone_device_ops *ops;
> +       struct thermal_zone_device_ops *ops;
>         const struct thermal_zone_params *tzp;
>         struct thermal_governor *governor;
>         struct list_head thermal_instances;
> @@ -242,8 +243,31 @@ struct thermal_genl_event {
>  };
>
>  /* Function declarations */
> +#ifdef CONFIG_THERMAL_OF
> +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 *));
> +void thermal_zone_of_sensor_unregister(struct device *dev,
> +                                      struct thermal_zone_device *tz);
> +#else
> +static inline 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 *))
> +{
> +       return NULL;
> +}
> +
> +static inline
> +void thermal_zone_of_sensor_unregister(struct device *dev,
> +                                      struct thermal_zone_device *tz)
> +{
> +}
> +
> +#endif
>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
> -               void *, const struct thermal_zone_device_ops *,
> +               void *, struct thermal_zone_device_ops *,
>                 const struct thermal_zone_params *, int, int);
>  void thermal_zone_device_unregister(struct thermal_zone_device *);
>
> --
> 1.8.2.1.342.gfa7285d
>
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv8 03/18] thermal: introduce device tree parser
  2013-10-07 20:51       ` [lm-sensors] " Mark Rutland
  (?)
@ 2013-10-08 14:59         ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-10-08 14:59 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	grant.likely, linux, rui.zhang, wni, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 71685 bytes --]

On 07-10-2013 16:51, Mark Rutland wrote:
> Hi all,
> 
> Given that this is a complex new class of binding, I'd appreciate if at least
> one other device tree maintainer could also take a look over this and voice any
> concerns or suggestions. I've left the entire patch context for this.
> 

I agree with you. Did I miss someone in my To/Cc list? I got a couple of
review iterations by Stephen and Pawel (so, they are Copied) in the very
early stages of this work.

> Apologies for the munged whitespace -- my mail server appears to have helpfully
> and irreparably replaced all tabs with spaces.

I

> 
> On Tue, Oct 01, 2013 at 03:39:26AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: linux-pm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>> Hello Mark, folks,
>>
>> So, here is v8. Pretty small changes. Most are better
>> English phrasing in the binding document. It follows changelog:
>> - Several rephrasing in the binding document, including
>> spelling, grammar and better phrasing.
>> - Removed WiP warning from binding document.
>> - Several spacing and formatting changes in the binding document
>> - Used the '-specifier' nomenclature properly in the binding doc
>> - Removed the optional property 'thermal-sensors-names', because
>> it does not provide useful runtime information
>> - Fixed description of 'polling-delay-passive'
>> - Improved examples by adding comments and better explanation
>> - s/fw/framework/g
>> - Added a WARN when sensors specifiers are greater and 1.
>>
>> All best,
>>
>> Eduardo
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1520 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..ad06a8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,587 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +This file describes a generic binding to provide a way of
>> +defining hardware thermal structure using device tree.
> 
> s/defining/describing/

Well, I just want to avoid being prolix, and I dont really think we
loose context or meaning by using defining here.

> 
>> +A thermal structure includes thermal zones and their components,
>> +such as trip points, polling intervals, sensors and cooling devices
>> +binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects. The thermal device tree bindings are
>> +not about how the system must control or which algorithm or policy
>> +must be taken in place.
> 
> I'm not quite sure what this is saying -- it seems to contradict the
> design of the binding where trip points get linked to cooling device
> configuration, and thus we're defining a policy along the lines of "when
> sensor $W hits temperature $X, configure cooling device $Y with value
> $Z". I don't see how that can't be considered policy.

It is saying that describing these entities does not necessarily means
we are imposing policies, but that we are only describing the hardware
proprieties and knobs so that policies may be built on top of them.
There are plenty of algorithm to implement a control system, with
thermal is not different. We are not describing algorithms / policies,
but only focusing on hardware information and limits that we can extract
and use them to control the system.

For instance, there is no obligation to implement a closed loop
proportional-integral-derivative controller. Nor there is a strong
implication to implement a simple stepping control algorithm. But with
the hardware description flexibility we are providing with this binding,
for sure it is possible to choose one of the referred policies. We are
describing data points, so that the logic to use them can be picked out
of OS design decision.

I don't thing that matching cooling devices with trip points of sensors
on a thermal zone is defining thermal policy. This matching, to me at
least, it is a direct outcome of describing your hardware and its
limits. There are a couple of steps ahead of it to have a finalized
thermal policy.

> 
> At best, we can say that policy is being defined because describing the
> physical properties of a device and dealing with this at runtime is not
> feasible.

OK. I see it slightly different, as I mentioned above. We are describing
physical properties and letting OSes to deal with them the way they choose.

> 
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
> 
> - thermal sensors: devices which may be used to take temperature
>   measurements.
> 
>> +- cooling devices: used to describe devices source of power dissipation control;
> 
> - cooling devices: devices which may be used to dissipate heat.
> 
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
> 
> - trip points: describe key temperatures at which cooling is recommended. The
>   set of points should be chosen based on hardware limits.
> 
>> +- cooling maps: used to describe links between trip points and cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
> 
> How about:
> 
> The following is a description of each of these node types.


OK, for the above suggestions.

> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0 on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling (DVFS), and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
> 
> I'd probably say "heat dissipation" rather than "power dissipation", unless
> this is a technical term I am not aware of?
> 
> Why is the determination of the state of the cooling device important?
> 
>> +
>> +Required properties:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
> 
> Is it assumed that all the values between min and max are valid, or might this
> be a sparse set of cooling values?

I am assuming they are valid states.

> 
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
> 
> What is it relative to?
> 
> Why is 'temperature' in quotes?

They relative to the temperature property, describe above. I am
rephrasing this to avoid misunderstanding.

a (low) hysteresis value on temperature property (above).

> 
>> +
>> +- type:                        a string containing the trip type. Supported values are:
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
> 
> Why?

That was originally suggested by swarren, but I was using integer
constants. I kept the his suggestion though, despite the type.

> 
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle of     referring to which cooling device is used in this
>> +    cooling device     binding. In the cooling specifier, the first cell
>> +                       is the minimum cooling state and the second cell
>> +                       is the maximum cooling state used in this map.
> 
> The type is wrong here -- it's a phandle + cooling-cells, not just a phandle.

I suppose you meant phandle + cooling specifier.

And yes, I am fixing that.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle of     zone.
>> +   trip point node
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling state used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling state used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one sub-node
>> +containing trip nodes and one sub-node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell
>> +
>> +- polling-delay-passive: The maximum number of milliseconds to wait
>> +  Type: unsigned       between polls when performing passive cooling.
>> +  Size: one cell
>> +
>> +- thermal-sensors:     A list of thermal sensor phandles and sensor specifier
>> +  Type: list of        used while monitoring the thermal zone.
>> +  sensor phandles
> 
> The type is wrong here. A list of phandle + sensor specifiers.

OK.

> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors listed in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offset.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when passive cooling is activated (polling-delay-passive); and
>> +(ii) - when the zone just needs to be monitored (polling-delay) or
>> +when active cooling is activated.
>> +
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability. The delays should be chosen to account for said max dT/dt,
>> +such that a device does not cross several trip boundaries unexpectedly
>> +between polls. Choosing the right polling delays shall avoid having the
>> +device in temperature ranges that may damage the silicon structures and
>> +reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes". The "thermal-zones" node appears under "/".
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       /*
>> +        * Here is an example of describing a cooling device for a DVFS
>> +        * capable CPU. The CPU node describes its four OPPs.
>> +        * The cooling states possible are 0..3, and they are
>> +        * used as OPP indexes. The minimum cooling state is 0, which means
>> +        * all four OPPs can be available to the system. The maximum
>> +        * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
>> +        * can be available in the system.
>> +        */
>> +       cpu0: cpu@0 {
>> +               ...
>> +               operating-points = <
>> +                       /* kHz    uV */
>> +                       970000  1200000
>> +                       792000  1100000
>> +                       396000  950000
>> +                       198000  850000
>> +               >;
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple fan controller which supports 10 speeds of operation
>> +        * (represented as 0-9).
>> +        */
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>;
>> +
>> +               trips {
>> +                       cpu-alert0: cpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "active";
>> +                       };
>> +                       cpu-alert1: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-alert0>;
>> +                               cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device =
>> +                                   <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
>> +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
>> +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
>> +different cooling states 0-9. It is used to remove the heat out of
>> +the thermal zone 'cpu-thermal' using its cooling states
>> +from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
>> +temperature of 125C, represented by the trip point 'cpu-crit', the silicon
>> +is not reliable anymore.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with several bandgap temperature sensors.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <1>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     0>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       cpu-alert: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       gpu-thermal: gpu-thermal {
>> +               polling-delay-passive = <120>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     1>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       gpu-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-crit: gpu-crit {
>> +                               temperature = <105000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       dsp-thermal: dsp-thermal {
>> +               polling-delay-passive = <50>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     2>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       dsp-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       dsp-crit: gpu-crit {
>> +                               temperature = <135000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first cell of the sensor
>> +specifier as sensor ID. In the example, then, <bandgap 0> is used to
>> +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
>> +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
>> +may be uncorrelated, having its own dT/dt requirements, trips
>> +and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple IC with a single temperature sensor.
>> +        */
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>,  /* cpu */
>> +                                 <&adc>;       /* pcb north */
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +               coefficients =          <100    -120    484>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrates this situation.
>> +For instance, it may be the case that a sensor external to CPU IP may be placed
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. Assuming this is the case for the above example,
>> +the hypothetical extrapolation rule would be:
>> +               hotspot = 100 * bandgap - 120 * adc + 484
>> +
>> +In other context, the same idea can be used to add fixed offset. For instance,
>> +consider the hotspot extrapolation rule below:
>> +               hotspot = 1 * adc + 6000
>> +
>> +In the above equation, the hotspot is always 6C higher than what is read
>> +from the ADC sensor. The binding would be then:
>> +        thermal-sensors =  <&adc>;
>> +
>> +               /* hotspot = 1 * adc + 6000 */
>> +       coefficients =          <1      6000>;
>> +
>> +(d) - Board thermal
>> +
>> +The board thermal example below illustrates how to setup one thermal zone
>> +with many sensors and many cooling devices.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * An IC with several temperature sensor.
>> +        */
>> +       adc-dummy: sensor@0x50 {
>> +               ...
>> +               #thermal-sensor-cells = <1>; /* sensor internal ID */
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       batt-thermal {
>> +               polling-delay-passive = <500>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     4>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +
>> +       board-thermal: board-thermal {
>> +               polling-delay-passive = <1000>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
>> +                                 <&adc-dummy     1>, /* lcd */
>> +                                 <&adc-dymmy     2>; /* back cover */
>> +               /*
>> +                * An array of coefficients describing the sensor
>> +                * linear relation. E.g.:
>> +                * z = c1*x1 + c2*x2 + c3*x3
>> +                */
>> +               coefficients =          <1200   -345    890>;
>> +
>> +               trips {
>> +                       /* Trips are based on resulting linear equation */
>> +                       cpu-trip: cpu-trip {
>> +                               temperature = <60000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-trip: gpu-trip {
>> +                               temperature = <55000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       }
>> +                       lcd-trip: lcp-trip {
>> +                               temperature = <53000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       crit-trip: crit-trip {
>> +                               temperature = <68000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-trip>;
>> +                               cooling-device = <&cpu0 0 2>;
>> +                               contribution = <55>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&gpu-trip>;
>> +                               cooling-device = <&gpu0 0 2>;
>> +                               contribution = <20>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&lcd-trip>;
>> +                               cooling-device = <&lcd0 5 10>;
>> +                               contribution = <15>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +The above example is a mix of previous examples, a sensor IP with several internal
>> +sensors used to monitor different zones, one of them is composed by several sensors and
>> +with different cooling devices.
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index dbfc390..dd81eb8 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,6 +29,19 @@ config THERMAL_HWMON
>>           Say 'Y' here if you want all thermal sensors to
>>           have hwmon sysfs interface too.
>>
>> +config THERMAL_OF
>> +       bool
>> +       prompt "APIs to parse thermal data out of device tree"
>> +       depends on OF
>> +       default y
>> +       help
>> +         This options provides helpers to add the support to
>> +         read and parse thermal data definitions out of the
>> +         device tree blob.
>> +
>> +         Say 'Y' here if you need to build thermal infrastructure
>> +         based on device tree.
>> +
>>  choice
>>         prompt "Default Thermal governor"
>>         default THERMAL_DEFAULT_GOV_STEP_WISE
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 584b363..4b03956 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -7,6 +7,7 @@ thermal_sys-y                   += thermal_core.o
>>
>>  # interface to/from other layers providing sensors
>>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
>> +thermal_sys-$(CONFIG_THERMAL_OF)               += of-thermal.o
>>
>>  # governors
>>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> new file mode 100644
>> index 0000000..66f9eb2
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,849 @@
>> +/*
>> + *  of-thermal.c - Generic Thermal Management device tree support.
>> + *
>> + *  Copyright (C) 2013 Texas Instruments
>> + *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + *
>> + *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation; version 2 of the License.
>> + *
>> + *  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.
>> + *
>> + *  You should have received a copy of the GNU General Public License along
>> + *  with this program; if not, write to the Free Software Foundation, Inc.,
>> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +#include <linux/thermal.h>
>> +#include <linux/slab.h>
>> +#include <linux/types.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/string.h>
>> +
>> +#include "thermal_core.h"
>> +
>> +/***   Private data structures to represent thermal device tree data ***/
>> +
>> +/**
>> + * struct __thermal_trip - representation of a point in temperature domain
>> + * @np: pointer to struct device_node that this trip point was created from
>> + * @temperature: temperature value in miliCelsius
>> + * @hysteresis: relative hysteresis in miliCelsius
>> + * @type: trip point type
>> + */
>> +
>> +struct __thermal_trip {
>> +       struct device_node *np;
>> +       unsigned long int temperature;
>> +       unsigned long int hysteresis;
>> +       enum thermal_trip_type type;
>> +};
>> +
>> +/**
>> + * struct __thermal_bind_param - a match between trip and cooling device
>> + * @cooling_device: a pointer to identify the referred cooling device
>> + * @trip_id: the trip point index
>> + * @usage: the percentage (from 0 to 100) of cooling contribution
>> + * @min: minimum cooling state used at this trip point
>> + * @max: maximum cooling state used at this trip point
>> + */
>> +
>> +struct __thermal_bind_params {
>> +       struct device_node *cooling_device;
>> +       unsigned int trip_id;
>> +       unsigned int usage;
>> +       unsigned long min;
>> +       unsigned long max;
>> +};
>> +
>> +/**
>> + * struct __thermal_zone - internal representation of a thermal zone
>> + * @mode: current thermal zone device mode (enabled/disabled)
>> + * @passive_delay: polling interval while passive cooling is activated
>> + * @polling_delay: zone polling interval
>> + * @ntrips: number of trip points
>> + * @trips: an array of trip points (0..ntrips - 1)
>> + * @num_tbps: number of thermal bind params
>> + * @tbps: an array of thermal bind params (0..num_tbps - 1)
>> + * @sensor_data: sensor private data used while reading temperature and trend
>> + * @get_temp: sensor callback to read temperature
>> + * @get_trend: sensor callback to read temperature trend
>> + */
>> +
>> +struct __thermal_zone {
>> +       enum thermal_device_mode mode;
>> +       int passive_delay;
>> +       int polling_delay;
>> +
>> +       /* trip data */
>> +       int ntrips;
>> +       struct __thermal_trip *trips;
>> +
>> +       /* cooling binding data */
>> +       int num_tbps;
>> +       struct __thermal_bind_params *tbps;
>> +
>> +       /* sensor interface */
>> +       void *sensor_data;
>> +       int (*get_temp)(void *, long *);
>> +       int (*get_trend)(void *, long *);
>> +};
>> +
>> +/***   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;
>> +
>> +       if (!data->get_temp)
>> +               return -EINVAL;
>> +
>> +       return data->get_temp(data->sensor_data, temp);
>> +}
>> +
>> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
>> +                               enum thermal_trend *trend)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       long dev_trend;
>> +       int r;
>> +
>> +       if (!data->get_trend)
>> +               return -EINVAL;
>> +
>> +       r = data->get_trend(data->sensor_data, &dev_trend);
>> +       if (r)
>> +               return r;
>> +
>> +       /* TODO: These intervals might have some thresholds, but in core code */
>> +       if (dev_trend > 0)
>> +               *trend = THERMAL_TREND_RAISING;
>> +       else if (dev_trend < 0)
>> +               *trend = THERMAL_TREND_DROPPING;
>> +       else
>> +               *trend = THERMAL_TREND_STABLE;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_bind(struct thermal_zone_device *thermal,
>> +                          struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to bind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_bind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev,
>> +                                               tbp->min,
>> +                                               tbp->max);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_unbind(struct thermal_zone_device *thermal,
>> +                            struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to unbind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_unbind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode *mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       *mode = data->mode;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       mutex_lock(&tz->lock);
>> +
>> +       if (mode == THERMAL_DEVICE_ENABLED)
>> +               tz->polling_delay = data->polling_delay;
>> +       else
>> +               tz->polling_delay = 0;
>> +
>> +       mutex_unlock(&tz->lock);
>> +
>> +       data->mode = mode;
>> +       thermal_zone_device_update(tz);
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *type = data->trips[trip].type;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *temp = data->trips[trip].temperature;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *hyst = data->trips[trip].hysteresis;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].hysteresis = hyst;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       int i;
>> +
>> +       for (i = 0; i < data->ntrips; i++)
>> +               if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
>> +                       *temp = data->trips[i].temperature;
>> +                       return 0;
>> +               }
>> +
>> +       return -EINVAL;
>> +}
>> +
>> +static struct thermal_zone_device_ops of_thermal_ops = {
>> +       .get_mode = of_thermal_get_mode,
>> +       .set_mode = of_thermal_set_mode,
>> +
>> +       .get_trip_type = of_thermal_get_trip_type,
>> +       .get_trip_temp = of_thermal_get_trip_temp,
>> +       .set_trip_temp = of_thermal_set_trip_temp,
>> +       .get_trip_hyst = of_thermal_get_trip_hyst,
>> +       .set_trip_hyst = of_thermal_set_trip_hyst,
>> +       .get_crit_temp = of_thermal_get_crit_temp,
>> +
>> +       .bind = of_thermal_bind,
>> +       .unbind = of_thermal_unbind,
>> +};
>> +
>> +/***   sensor API   ***/
>> +
>> +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 *))
>> +{
>> +       struct thermal_zone_device *tzd;
>> +       struct __thermal_zone *tz;
>> +
>> +       tzd = thermal_zone_get_zone_by_name(zone->name);
>> +       if (IS_ERR(tzd))
>> +               return ERR_PTR(-EPROBE_DEFER);
>> +
>> +       tz = tzd->devdata;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tz->get_temp = get_temp;
>> +       tz->get_trend = get_trend;
>> +       tz->sensor_data = data;
>> +
>> +       tzd->ops->get_temp = of_thermal_get_temp;
>> +       tzd->ops->get_trend = of_thermal_get_trend;
>> +       mutex_unlock(&tzd->lock);
>> +
>> +       return tzd;
>> +}
>> +
>> +/**
>> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @sensor_id: a sensor identifier, in case the sensor IP has more
>> + *             than one sensors
>> + * @data: a private pointer (owned by the caller) that will be passed
>> + *        back, when a temperature reading is needed.
>> + * @get_temp: a pointer to a function that reads the sensor temperature.
>> + * @get_trend: a pointer to a function that reads the sensor temperature trend.
>> + *
>> + * This function will search the list of thermal zones described in device
>> + * tree and look for the zone that refer to the sensor device pointed by
>> + * @dev->of_node as temperature providers. For the zone pointing to the
>> + * sensor node, the sensor will be added to the DT thermal zone device.
>> + *
>> + * The thermal zone temperature is provided by the @get_temp function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * The thermal zone temperature trend is provided by the @get_trend function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * TODO:
>> + * 01 - This function must enqueue the new sensor instead of using
>> + * it as the only source of temperature values.
>> + *
>> + * 02 - There must be a way to match the sensor with all thermal zones
>> + * that refer to it.
>> + *
>> + * Return: On success returns a valid struct thermal_zone_device,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count >= 1) {
>> +                       id = sensor_specs.args[0];
>> +                       WARN(sensor_specs.args_count > 1,
>> +                            "%s: too many cells in sensor specifier %d\n",
>> +                            sensor_specs.np->name, sensor_specs.args_count);
>> +               } else {
>> +                       id = 0;
>> +               }
>> +
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
>> +
>> +/**
>> + * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
>> + *
>> + * This function removes the sensor callbacks and private data from the
>> + * thermal zone device registered with thermal_zone_of_sensor_register()
>> + * API. It will also silent the zone by remove the .get_temp() and .get_trend()
>> + * thermal zone device callbacks.
>> + *
>> + * TODO: When the support to several sensors per zone is added, this
>> + * function must search the sensor list based on @dev parameter.
>> + *
>> + */
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tzd)
>> +{
>> +       struct __thermal_zone *tz;
>> +
>> +       if (!dev || !tzd || !tzd->devdata)
>> +               return;
>> +
>> +       tz = tzd->devdata;
>> +
>> +       /* no __thermal_zone, nothing to be done */
>> +       if (!tz)
>> +               return;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tzd->ops->get_temp = NULL;
>> +       tzd->ops->get_trend = NULL;
>> +
>> +       tz->get_temp = NULL;
>> +       tz->get_trend = NULL;
>> +       tz->sensor_data = NULL;
>> +       mutex_unlock(&tzd->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
>> +
>> +/***   functions parsing device tree nodes   ***/
>> +
>> +/**
>> + * thermal_of_populate_bind_params - parse and fill cooling map data
>> + * @np: DT node containing a cooling-map node
>> + * @__tbp: data structure to be filled with cooling map info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-map type of node represented by
>> + * @np parameter and fills the read data into @__tbp data structure.
>> + * It needs the already parsed array of trip points of the thermal zone
>> + * in consideration.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_bind_params(struct device_node *np,
>> +                                          struct __thermal_bind_params *__tbp,
>> +                                          struct __thermal_trip *trips,
>> +                                          int ntrips)
>> +{
>> +       struct of_phandle_args cooling_spec;
>> +       struct device_node *trip;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       /* Default weight. Usage is optional */
>> +       __tbp->usage = 0;
>> +       ret = of_property_read_u32(np, "contribution", &prop);
>> +       if (ret == 0)
>> +               __tbp->usage = prop;
>> +
>> +       trip = of_parse_phandle(np, "trip", 0);
>> +       if (!trip) {
>> +               pr_err("missing trip property\n");
>> +               return -ENODEV;
>> +       }
>> +
>> +       /* match using device_node */
>> +       for (i = 0; i < ntrips; i++)
>> +               if (trip == trips[i].np) {
>> +                       __tbp->trip_id = i;
>> +                       break;
>> +               }
>> +
>> +       if (i == ntrips) {
>> +               ret = -ENODEV;
>> +               goto end;
>> +       }
>> +
>> +       ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
>> +                                        0, &cooling_spec);
>> +       if (ret < 0) {
>> +               pr_err("missing cooling_device property\n");
>> +               goto end;
>> +       }
>> +       __tbp->cooling_device = cooling_spec.np;
>> +       if (cooling_spec.args_count >= 2) { /* at least min and max */
>> +               __tbp->min = cooling_spec.args[0];
>> +               __tbp->max = cooling_spec.args[1];
>> +       } else {
>> +               pr_err("wrong reference to cooling device, missing limits\n");
>> +       }
>> +
>> +end:
>> +       of_node_put(trip);
>> +
>> +       return ret;
>> +}
>> +
>> +/**
>> + * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
>> + * into the device tree binding of 'trip', property type.
>> + */
>> +static const char * const trip_types[] = {
>> +       [THERMAL_TRIP_ACTIVE]   = "active",
>> +       [THERMAL_TRIP_PASSIVE]  = "passive",
>> +       [THERMAL_TRIP_HOT]      = "hot",
>> +       [THERMAL_TRIP_CRITICAL] = "critical",
>> +};
>> +
>> +/**
>> + * thermal_of_get_trip_type - Get phy mode for given device_node
>> + * @np:        Pointer to the given device_node
>> + * @type: Pointer to resulting trip type
>> + *
>> + * The function gets trip type string from property 'type',
>> + * and store its index in trip_types table in @type,
>> + *
>> + * Return: 0 on success, or errno in error case.
>> + */
>> +static int thermal_of_get_trip_type(struct device_node *np,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       const char *t;
>> +       int err, i;
>> +
>> +       err = of_property_read_string(np, "type", &t);
>> +       if (err < 0)
>> +               return err;
>> +
>> +       for (i = 0; i < ARRAY_SIZE(trip_types); i++)
>> +               if (!strcasecmp(t, trip_types[i])) {
>> +                       *type = i;
>> +                       return 0;
>> +               }
>> +
>> +       return -ENODEV;
>> +}
>> +
>> +/**
>> + * thermal_of_populate_trip - parse and fill one trip point data
>> + * @np: DT node containing a trip point node
>> + * @trip: trip point data structure to be filled up
>> + *
>> + * This function parses a trip point type of node represented by
>> + * @np parameter and fills the read data into @trip data structure.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_trip(struct device_node *np,
>> +                                   struct __thermal_trip *trip)
>> +{
>> +       int prop;
>> +       int ret;
>> +
>> +       ret = of_property_read_u32(np, "temperature", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing temperature property\n");
>> +               return ret;
>> +       }
>> +       trip->temperature = prop;
>> +
>> +       ret = of_property_read_u32(np, "hysteresis", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing hysteresis property\n");
>> +               return ret;
>> +       }
>> +       trip->hysteresis = prop;
>> +
>> +       ret = thermal_of_get_trip_type(np, &trip->type);
>> +       if (ret < 0) {
>> +               pr_err("wrong trip type property\n");
>> +               return ret;
>> +       }
>> +
>> +       /* Required for cooling map matching */
>> +       trip->np = np;
>> +
>> +       return 0;
>> +}
>> +
>> +/**
>> + * thermal_of_build_thermal_zone - parse and fill one thermal zone data
>> + * @np: DT node containing a thermal zone node
>> + *
>> + * This function parses a thermal zone type of node represented by
>> + * @np parameter and fills the read data into a __thermal_zone data structure
>> + * and return this pointer.
>> + *
>> + * TODO: Missing properties to parse: thermal-sensor-names and coefficients
>> + *
>> + * Return: On success returns a valid struct __thermal_zone,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +       struct device_node *child = NULL, *gchild;
>> +       struct __thermal_zone *tz;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       if (!np) {
>> +               pr_err("no thermal zone np\n");
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>> +       if (!tz)
>> +               return ERR_PTR(-ENOMEM);
>> +
>> +       ret = of_property_read_u32(np, "polling-delay-passive", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay-passive property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->passive_delay = prop;
>> +
>> +       ret = of_property_read_u32(np, "polling-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->polling_delay = prop;
>> +
>> +       /* trips */
>> +       child = of_get_child_by_name(np, "trips");
>> +
>> +       /* No trips provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->ntrips = of_get_child_count(child);
>> +       if (tz->ntrips == 0) /* must have at least one child */
>> +               goto finish;
>> +
>> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +       if (!tz->trips) {
>> +               ret = -ENOMEM;
>> +               goto free_tz;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild) {
>> +               ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +               if (ret)
>> +                       goto free_trips;
>> +       }
>> +
>> +       of_node_put(child);
>> +
>> +       /* cooling-maps */
>> +       child = of_get_child_by_name(np, "cooling-maps");
>> +
>> +       /* cooling-maps not provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->num_tbps = of_get_child_count(child);
>> +       if (tz->num_tbps == 0)
>> +               goto finish;
>> +
>> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +       if (!tz->tbps) {
>> +               ret = -ENOMEM;
>> +               goto free_trips;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +                                                     tz->trips, tz->ntrips);
>> +               if (ret)
>> +                       goto free_tbps;
>> +
>> +finish:
>> +       of_node_put(child);
>> +       tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +       return tz;
>> +
>> +free_tbps:
>> +       kfree(tz->tbps);
>> +free_trips:
>> +       kfree(tz->trips);
>> +free_tz:
>> +       kfree(tz);
>> +       of_node_put(child);
>> +
>> +       return ERR_PTR(ret);
>> +}
>> +
>> +static inline void of_thermal_free_zone(struct __thermal_zone *tz)
>> +{
>> +       kfree(tz->tbps);
>> +       kfree(tz->trips);
>> +       kfree(tz);
>> +}
>> +
>> +/**
>> + * of_parse_thermal_zones - parse device tree thermal data
>> + *
>> + * Initialization function that can be called by machine initialization
>> + * code to parse thermal data and populate the thermal framework
>> + * with hardware thermal zones info. This function only parses thermal zones.
>> + * Cooling devices and sensor devices nodes are supposed to be parsed
>> + * by their respective drivers.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + *
>> + */
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +       struct __thermal_zone *tz;
>> +       struct thermal_zone_device_ops *ops;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_debug("unable to find thermal zones\n");
>> +               return 0; /* Run successfully on systems without thermal DT */
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +               struct thermal_zone_params *tzp;
>> +
>> +               tz = thermal_of_build_thermal_zone(child);
>> +               if (IS_ERR(tz)) {
>> +                       pr_err("failed to build thermal zone %s: %ld\n",
>> +                              child->name,
>> +                              PTR_ERR(tz));
>> +                       continue;
>> +               }
>> +
>> +               ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
>> +               if (!ops)
>> +                       goto exit_free;
>> +
>> +               tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +               if (!tzp) {
>> +                       kfree(ops);
>> +                       goto exit_free;
>> +               }
>> +
>> +               /* No hwmon because there might be hwmon drivers registering */
>> +               tzp->no_hwmon = true;
>> +
>> +               zone = thermal_zone_device_register(child->name, tz->ntrips,
>> +                                                   0, tz,
>> +                                                   ops, tzp,
>> +                                                   tz->passive_delay,
>> +                                                   tz->polling_delay);
>> +               if (IS_ERR(zone)) {
>> +                       pr_err("Failed to build %s zone %ld\n", child->name,
>> +                              PTR_ERR(zone));
>> +                       kfree(tzp);
>> +                       kfree(ops);
>> +                       of_thermal_free_zone(tz);
>> +                       /* attempting to build remaining zones still */
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +exit_free:
>> +       of_thermal_free_zone(tz);
>> +
>> +       /* no memory available, so free what we have built */
>> +       of_thermal_destroy_zones();
>> +
>> +       return -ENOMEM;
>> +}
>> +
>> +/**
>> + * of_thermal_destroy_zones - remove all zones parsed and allocated resources
>> + *
>> + * Finds all zones parsed and added to the thermal framework and remove them
>> + * from the system, together with their resources.
>> + *
>> + */
>> +void __exit of_thermal_destroy_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_err("unable to find thermal zones\n");
>> +               return;
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +
>> +               zone = thermal_zone_get_zone_by_name(child->name);
>> +               if (IS_ERR(zone))
>> +                       continue;
>> +
>> +               thermal_zone_device_unregister(zone);
>> +               kfree(zone->tzp);
>> +               kfree(zone->ops);
>> +               of_thermal_free_zone(zone->devdata);
>> +       }
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index f7a9f4f..fec3351 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
>>   */
>>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
>>         int trips, int mask, void *devdata,
>> -       const struct thermal_zone_device_ops *ops,
>> +       struct thermal_zone_device_ops *ops,
>>         const struct thermal_zone_params *tzp,
>>         int passive_delay, int polling_delay)
>>  {
>> @@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
>>         if (result)
>>                 goto unregister_class;
>>
>> +       result = of_parse_thermal_zones();
>> +       if (result)
>> +               goto exit_netlink;
>> +
>>         return 0;
>>
>> +exit_netlink:
>> +       genetlink_exit();
>>  unregister_governors:
>>         thermal_unregister_governors();
>>  unregister_class:
>> @@ -1768,6 +1774,7 @@ error:
>>
>>  static void __exit thermal_exit(void)
>>  {
>> +       of_thermal_destroy_zones();
>>         genetlink_exit();
>>         class_unregister(&thermal_class);
>>         thermal_unregister_governors();
>> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
>> index 7cf2f66..3db339f 100644
>> --- a/drivers/thermal/thermal_core.h
>> +++ b/drivers/thermal/thermal_core.h
>> @@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
>>  static inline void thermal_gov_user_space_unregister(void) {}
>>  #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
>>
>> +/* device tree support */
>> +#ifdef CONFIG_THERMAL_OF
>> +int of_parse_thermal_zones(void);
>> +void of_thermal_destroy_zones(void);
>> +#else
>> +static inline int of_parse_thermal_zones(void) { return 0; }
>> +static inline void of_thermal_destroy_zones(void) { }
>> +#endif
>> +
>>  #endif /* __THERMAL_CORE_H__ */
>> diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
>> new file mode 100644
>> index 0000000..59c4581
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/thermal.h
>> @@ -0,0 +1,27 @@
>> +/*
>> + * This header provides constants for most thermal bindings.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *     Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + * GPLv2 only
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
>> +#define _DT_BINDINGS_THERMAL_THERMAL_H
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE            "active"
>> +#define THERMAL_TRIP_PASSIVE           "passive"
>> +#define THERMAL_TRIP_HOT               "hot"
>> +#define THERMAL_TRIP_CRITICAL          "critical"
> 
> I don't like this. If someone wants to include this in a C file they can't do so
> at the same time as include/linux/thermal.h. The defined names are longer than
> the actual string values, and the comment makes it sound like these could be
> modified rather than being a fixed ABI.
> 
> I do not see the point of these constants.
> 
> Thanks,
> Mark.
> 
>> +
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT               (-1UL)
>> +
>> +#endif
>> +
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index b268d3c..b780c5b 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -143,6 +143,7 @@ struct thermal_cooling_device {
>>         int id;
>>         char type[THERMAL_NAME_LENGTH];
>>         struct device device;
>> +       struct device_node *np;
>>         void *devdata;
>>         const struct thermal_cooling_device_ops *ops;
>>         bool updated; /* true if the cooling device does not need update */
>> @@ -172,7 +173,7 @@ struct thermal_zone_device {
>>         int emul_temperature;
>>         int passive;
>>         unsigned int forced_passive;
>> -       const struct thermal_zone_device_ops *ops;
>> +       struct thermal_zone_device_ops *ops;
>>         const struct thermal_zone_params *tzp;
>>         struct thermal_governor *governor;
>>         struct list_head thermal_instances;
>> @@ -242,8 +243,31 @@ struct thermal_genl_event {
>>  };
>>
>>  /* Function declarations */
>> +#ifdef CONFIG_THERMAL_OF
>> +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 *));
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz);
>> +#else
>> +static inline 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 *))
>> +{
>> +       return NULL;
>> +}
>> +
>> +static inline
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz)
>> +{
>> +}
>> +
>> +#endif
>>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
>> -               void *, const struct thermal_zone_device_ops *,
>> +               void *, struct thermal_zone_device_ops *,
>>                 const struct thermal_zone_params *, int, int);
>>  void thermal_zone_device_unregister(struct thermal_zone_device *);
>>
>> --
>> 1.8.2.1.342.gfa7285d
>>
>>
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv8 03/18] thermal: introduce device tree parser
@ 2013-10-08 14:59         ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-10-08 14:59 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren-3lzwWm7+Weoh9ZMKESR00Q, Pawel Moll,
	ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	linux-0h96xk9xTtrk1uMJSBkQmQ, rui.zhang-ral2JQCrhuEAvxtiuMwx3w,
	wni-DDmLM1+adcrQT0dZR+AlfA, durgadoss.r-ral2JQCrhuEAvxtiuMwx3w,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 71829 bytes --]

On 07-10-2013 16:51, Mark Rutland wrote:
> Hi all,
> 
> Given that this is a complex new class of binding, I'd appreciate if at least
> one other device tree maintainer could also take a look over this and voice any
> concerns or suggestions. I've left the entire patch context for this.
> 

I agree with you. Did I miss someone in my To/Cc list? I got a couple of
review iterations by Stephen and Pawel (so, they are Copied) in the very
early stages of this work.

> Apologies for the munged whitespace -- my mail server appears to have helpfully
> and irreparably replaced all tabs with spaces.

I

> 
> On Tue, Oct 01, 2013 at 03:39:26AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>> ---
>> Hello Mark, folks,
>>
>> So, here is v8. Pretty small changes. Most are better
>> English phrasing in the binding document. It follows changelog:
>> - Several rephrasing in the binding document, including
>> spelling, grammar and better phrasing.
>> - Removed WiP warning from binding document.
>> - Several spacing and formatting changes in the binding document
>> - Used the '-specifier' nomenclature properly in the binding doc
>> - Removed the optional property 'thermal-sensors-names', because
>> it does not provide useful runtime information
>> - Fixed description of 'polling-delay-passive'
>> - Improved examples by adding comments and better explanation
>> - s/fw/framework/g
>> - Added a WARN when sensors specifiers are greater and 1.
>>
>> All best,
>>
>> Eduardo
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1520 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..ad06a8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,587 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +This file describes a generic binding to provide a way of
>> +defining hardware thermal structure using device tree.
> 
> s/defining/describing/

Well, I just want to avoid being prolix, and I dont really think we
loose context or meaning by using defining here.

> 
>> +A thermal structure includes thermal zones and their components,
>> +such as trip points, polling intervals, sensors and cooling devices
>> +binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects. The thermal device tree bindings are
>> +not about how the system must control or which algorithm or policy
>> +must be taken in place.
> 
> I'm not quite sure what this is saying -- it seems to contradict the
> design of the binding where trip points get linked to cooling device
> configuration, and thus we're defining a policy along the lines of "when
> sensor $W hits temperature $X, configure cooling device $Y with value
> $Z". I don't see how that can't be considered policy.

It is saying that describing these entities does not necessarily means
we are imposing policies, but that we are only describing the hardware
proprieties and knobs so that policies may be built on top of them.
There are plenty of algorithm to implement a control system, with
thermal is not different. We are not describing algorithms / policies,
but only focusing on hardware information and limits that we can extract
and use them to control the system.

For instance, there is no obligation to implement a closed loop
proportional-integral-derivative controller. Nor there is a strong
implication to implement a simple stepping control algorithm. But with
the hardware description flexibility we are providing with this binding,
for sure it is possible to choose one of the referred policies. We are
describing data points, so that the logic to use them can be picked out
of OS design decision.

I don't thing that matching cooling devices with trip points of sensors
on a thermal zone is defining thermal policy. This matching, to me at
least, it is a direct outcome of describing your hardware and its
limits. There are a couple of steps ahead of it to have a finalized
thermal policy.

> 
> At best, we can say that policy is being defined because describing the
> physical properties of a device and dealing with this at runtime is not
> feasible.

OK. I see it slightly different, as I mentioned above. We are describing
physical properties and letting OSes to deal with them the way they choose.

> 
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
> 
> - thermal sensors: devices which may be used to take temperature
>   measurements.
> 
>> +- cooling devices: used to describe devices source of power dissipation control;
> 
> - cooling devices: devices which may be used to dissipate heat.
> 
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
> 
> - trip points: describe key temperatures at which cooling is recommended. The
>   set of points should be chosen based on hardware limits.
> 
>> +- cooling maps: used to describe links between trip points and cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
> 
> How about:
> 
> The following is a description of each of these node types.


OK, for the above suggestions.

> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0 on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling (DVFS), and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
> 
> I'd probably say "heat dissipation" rather than "power dissipation", unless
> this is a technical term I am not aware of?
> 
> Why is the determination of the state of the cooling device important?
> 
>> +
>> +Required properties:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
> 
> Is it assumed that all the values between min and max are valid, or might this
> be a sparse set of cooling values?

I am assuming they are valid states.

> 
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
> 
> What is it relative to?
> 
> Why is 'temperature' in quotes?

They relative to the temperature property, describe above. I am
rephrasing this to avoid misunderstanding.

a (low) hysteresis value on temperature property (above).

> 
>> +
>> +- type:                        a string containing the trip type. Supported values are:
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
> 
> Why?

That was originally suggested by swarren, but I was using integer
constants. I kept the his suggestion though, despite the type.

> 
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle of     referring to which cooling device is used in this
>> +    cooling device     binding. In the cooling specifier, the first cell
>> +                       is the minimum cooling state and the second cell
>> +                       is the maximum cooling state used in this map.
> 
> The type is wrong here -- it's a phandle + cooling-cells, not just a phandle.

I suppose you meant phandle + cooling specifier.

And yes, I am fixing that.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle of     zone.
>> +   trip point node
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling state used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling state used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one sub-node
>> +containing trip nodes and one sub-node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell
>> +
>> +- polling-delay-passive: The maximum number of milliseconds to wait
>> +  Type: unsigned       between polls when performing passive cooling.
>> +  Size: one cell
>> +
>> +- thermal-sensors:     A list of thermal sensor phandles and sensor specifier
>> +  Type: list of        used while monitoring the thermal zone.
>> +  sensor phandles
> 
> The type is wrong here. A list of phandle + sensor specifiers.

OK.

> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors listed in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offset.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when passive cooling is activated (polling-delay-passive); and
>> +(ii) - when the zone just needs to be monitored (polling-delay) or
>> +when active cooling is activated.
>> +
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability. The delays should be chosen to account for said max dT/dt,
>> +such that a device does not cross several trip boundaries unexpectedly
>> +between polls. Choosing the right polling delays shall avoid having the
>> +device in temperature ranges that may damage the silicon structures and
>> +reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes". The "thermal-zones" node appears under "/".
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       /*
>> +        * Here is an example of describing a cooling device for a DVFS
>> +        * capable CPU. The CPU node describes its four OPPs.
>> +        * The cooling states possible are 0..3, and they are
>> +        * used as OPP indexes. The minimum cooling state is 0, which means
>> +        * all four OPPs can be available to the system. The maximum
>> +        * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
>> +        * can be available in the system.
>> +        */
>> +       cpu0: cpu@0 {
>> +               ...
>> +               operating-points = <
>> +                       /* kHz    uV */
>> +                       970000  1200000
>> +                       792000  1100000
>> +                       396000  950000
>> +                       198000  850000
>> +               >;
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple fan controller which supports 10 speeds of operation
>> +        * (represented as 0-9).
>> +        */
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>;
>> +
>> +               trips {
>> +                       cpu-alert0: cpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "active";
>> +                       };
>> +                       cpu-alert1: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-alert0>;
>> +                               cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device =
>> +                                   <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
>> +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
>> +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
>> +different cooling states 0-9. It is used to remove the heat out of
>> +the thermal zone 'cpu-thermal' using its cooling states
>> +from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
>> +temperature of 125C, represented by the trip point 'cpu-crit', the silicon
>> +is not reliable anymore.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with several bandgap temperature sensors.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <1>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     0>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       cpu-alert: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       gpu-thermal: gpu-thermal {
>> +               polling-delay-passive = <120>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     1>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       gpu-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-crit: gpu-crit {
>> +                               temperature = <105000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       dsp-thermal: dsp-thermal {
>> +               polling-delay-passive = <50>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     2>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       dsp-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       dsp-crit: gpu-crit {
>> +                               temperature = <135000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first cell of the sensor
>> +specifier as sensor ID. In the example, then, <bandgap 0> is used to
>> +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
>> +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
>> +may be uncorrelated, having its own dT/dt requirements, trips
>> +and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple IC with a single temperature sensor.
>> +        */
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>,  /* cpu */
>> +                                 <&adc>;       /* pcb north */
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +               coefficients =          <100    -120    484>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrates this situation.
>> +For instance, it may be the case that a sensor external to CPU IP may be placed
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. Assuming this is the case for the above example,
>> +the hypothetical extrapolation rule would be:
>> +               hotspot = 100 * bandgap - 120 * adc + 484
>> +
>> +In other context, the same idea can be used to add fixed offset. For instance,
>> +consider the hotspot extrapolation rule below:
>> +               hotspot = 1 * adc + 6000
>> +
>> +In the above equation, the hotspot is always 6C higher than what is read
>> +from the ADC sensor. The binding would be then:
>> +        thermal-sensors =  <&adc>;
>> +
>> +               /* hotspot = 1 * adc + 6000 */
>> +       coefficients =          <1      6000>;
>> +
>> +(d) - Board thermal
>> +
>> +The board thermal example below illustrates how to setup one thermal zone
>> +with many sensors and many cooling devices.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * An IC with several temperature sensor.
>> +        */
>> +       adc-dummy: sensor@0x50 {
>> +               ...
>> +               #thermal-sensor-cells = <1>; /* sensor internal ID */
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       batt-thermal {
>> +               polling-delay-passive = <500>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     4>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +
>> +       board-thermal: board-thermal {
>> +               polling-delay-passive = <1000>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
>> +                                 <&adc-dummy     1>, /* lcd */
>> +                                 <&adc-dymmy     2>; /* back cover */
>> +               /*
>> +                * An array of coefficients describing the sensor
>> +                * linear relation. E.g.:
>> +                * z = c1*x1 + c2*x2 + c3*x3
>> +                */
>> +               coefficients =          <1200   -345    890>;
>> +
>> +               trips {
>> +                       /* Trips are based on resulting linear equation */
>> +                       cpu-trip: cpu-trip {
>> +                               temperature = <60000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-trip: gpu-trip {
>> +                               temperature = <55000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       }
>> +                       lcd-trip: lcp-trip {
>> +                               temperature = <53000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       crit-trip: crit-trip {
>> +                               temperature = <68000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-trip>;
>> +                               cooling-device = <&cpu0 0 2>;
>> +                               contribution = <55>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&gpu-trip>;
>> +                               cooling-device = <&gpu0 0 2>;
>> +                               contribution = <20>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&lcd-trip>;
>> +                               cooling-device = <&lcd0 5 10>;
>> +                               contribution = <15>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +The above example is a mix of previous examples, a sensor IP with several internal
>> +sensors used to monitor different zones, one of them is composed by several sensors and
>> +with different cooling devices.
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index dbfc390..dd81eb8 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,6 +29,19 @@ config THERMAL_HWMON
>>           Say 'Y' here if you want all thermal sensors to
>>           have hwmon sysfs interface too.
>>
>> +config THERMAL_OF
>> +       bool
>> +       prompt "APIs to parse thermal data out of device tree"
>> +       depends on OF
>> +       default y
>> +       help
>> +         This options provides helpers to add the support to
>> +         read and parse thermal data definitions out of the
>> +         device tree blob.
>> +
>> +         Say 'Y' here if you need to build thermal infrastructure
>> +         based on device tree.
>> +
>>  choice
>>         prompt "Default Thermal governor"
>>         default THERMAL_DEFAULT_GOV_STEP_WISE
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 584b363..4b03956 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -7,6 +7,7 @@ thermal_sys-y                   += thermal_core.o
>>
>>  # interface to/from other layers providing sensors
>>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
>> +thermal_sys-$(CONFIG_THERMAL_OF)               += of-thermal.o
>>
>>  # governors
>>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> new file mode 100644
>> index 0000000..66f9eb2
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,849 @@
>> +/*
>> + *  of-thermal.c - Generic Thermal Management device tree support.
>> + *
>> + *  Copyright (C) 2013 Texas Instruments
>> + *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>> + *
>> + *
>> + *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation; version 2 of the License.
>> + *
>> + *  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.
>> + *
>> + *  You should have received a copy of the GNU General Public License along
>> + *  with this program; if not, write to the Free Software Foundation, Inc.,
>> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +#include <linux/thermal.h>
>> +#include <linux/slab.h>
>> +#include <linux/types.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/string.h>
>> +
>> +#include "thermal_core.h"
>> +
>> +/***   Private data structures to represent thermal device tree data ***/
>> +
>> +/**
>> + * struct __thermal_trip - representation of a point in temperature domain
>> + * @np: pointer to struct device_node that this trip point was created from
>> + * @temperature: temperature value in miliCelsius
>> + * @hysteresis: relative hysteresis in miliCelsius
>> + * @type: trip point type
>> + */
>> +
>> +struct __thermal_trip {
>> +       struct device_node *np;
>> +       unsigned long int temperature;
>> +       unsigned long int hysteresis;
>> +       enum thermal_trip_type type;
>> +};
>> +
>> +/**
>> + * struct __thermal_bind_param - a match between trip and cooling device
>> + * @cooling_device: a pointer to identify the referred cooling device
>> + * @trip_id: the trip point index
>> + * @usage: the percentage (from 0 to 100) of cooling contribution
>> + * @min: minimum cooling state used at this trip point
>> + * @max: maximum cooling state used at this trip point
>> + */
>> +
>> +struct __thermal_bind_params {
>> +       struct device_node *cooling_device;
>> +       unsigned int trip_id;
>> +       unsigned int usage;
>> +       unsigned long min;
>> +       unsigned long max;
>> +};
>> +
>> +/**
>> + * struct __thermal_zone - internal representation of a thermal zone
>> + * @mode: current thermal zone device mode (enabled/disabled)
>> + * @passive_delay: polling interval while passive cooling is activated
>> + * @polling_delay: zone polling interval
>> + * @ntrips: number of trip points
>> + * @trips: an array of trip points (0..ntrips - 1)
>> + * @num_tbps: number of thermal bind params
>> + * @tbps: an array of thermal bind params (0..num_tbps - 1)
>> + * @sensor_data: sensor private data used while reading temperature and trend
>> + * @get_temp: sensor callback to read temperature
>> + * @get_trend: sensor callback to read temperature trend
>> + */
>> +
>> +struct __thermal_zone {
>> +       enum thermal_device_mode mode;
>> +       int passive_delay;
>> +       int polling_delay;
>> +
>> +       /* trip data */
>> +       int ntrips;
>> +       struct __thermal_trip *trips;
>> +
>> +       /* cooling binding data */
>> +       int num_tbps;
>> +       struct __thermal_bind_params *tbps;
>> +
>> +       /* sensor interface */
>> +       void *sensor_data;
>> +       int (*get_temp)(void *, long *);
>> +       int (*get_trend)(void *, long *);
>> +};
>> +
>> +/***   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;
>> +
>> +       if (!data->get_temp)
>> +               return -EINVAL;
>> +
>> +       return data->get_temp(data->sensor_data, temp);
>> +}
>> +
>> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
>> +                               enum thermal_trend *trend)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       long dev_trend;
>> +       int r;
>> +
>> +       if (!data->get_trend)
>> +               return -EINVAL;
>> +
>> +       r = data->get_trend(data->sensor_data, &dev_trend);
>> +       if (r)
>> +               return r;
>> +
>> +       /* TODO: These intervals might have some thresholds, but in core code */
>> +       if (dev_trend > 0)
>> +               *trend = THERMAL_TREND_RAISING;
>> +       else if (dev_trend < 0)
>> +               *trend = THERMAL_TREND_DROPPING;
>> +       else
>> +               *trend = THERMAL_TREND_STABLE;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_bind(struct thermal_zone_device *thermal,
>> +                          struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to bind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_bind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev,
>> +                                               tbp->min,
>> +                                               tbp->max);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_unbind(struct thermal_zone_device *thermal,
>> +                            struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to unbind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_unbind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode *mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       *mode = data->mode;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       mutex_lock(&tz->lock);
>> +
>> +       if (mode == THERMAL_DEVICE_ENABLED)
>> +               tz->polling_delay = data->polling_delay;
>> +       else
>> +               tz->polling_delay = 0;
>> +
>> +       mutex_unlock(&tz->lock);
>> +
>> +       data->mode = mode;
>> +       thermal_zone_device_update(tz);
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *type = data->trips[trip].type;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *temp = data->trips[trip].temperature;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *hyst = data->trips[trip].hysteresis;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].hysteresis = hyst;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       int i;
>> +
>> +       for (i = 0; i < data->ntrips; i++)
>> +               if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
>> +                       *temp = data->trips[i].temperature;
>> +                       return 0;
>> +               }
>> +
>> +       return -EINVAL;
>> +}
>> +
>> +static struct thermal_zone_device_ops of_thermal_ops = {
>> +       .get_mode = of_thermal_get_mode,
>> +       .set_mode = of_thermal_set_mode,
>> +
>> +       .get_trip_type = of_thermal_get_trip_type,
>> +       .get_trip_temp = of_thermal_get_trip_temp,
>> +       .set_trip_temp = of_thermal_set_trip_temp,
>> +       .get_trip_hyst = of_thermal_get_trip_hyst,
>> +       .set_trip_hyst = of_thermal_set_trip_hyst,
>> +       .get_crit_temp = of_thermal_get_crit_temp,
>> +
>> +       .bind = of_thermal_bind,
>> +       .unbind = of_thermal_unbind,
>> +};
>> +
>> +/***   sensor API   ***/
>> +
>> +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 *))
>> +{
>> +       struct thermal_zone_device *tzd;
>> +       struct __thermal_zone *tz;
>> +
>> +       tzd = thermal_zone_get_zone_by_name(zone->name);
>> +       if (IS_ERR(tzd))
>> +               return ERR_PTR(-EPROBE_DEFER);
>> +
>> +       tz = tzd->devdata;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tz->get_temp = get_temp;
>> +       tz->get_trend = get_trend;
>> +       tz->sensor_data = data;
>> +
>> +       tzd->ops->get_temp = of_thermal_get_temp;
>> +       tzd->ops->get_trend = of_thermal_get_trend;
>> +       mutex_unlock(&tzd->lock);
>> +
>> +       return tzd;
>> +}
>> +
>> +/**
>> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @sensor_id: a sensor identifier, in case the sensor IP has more
>> + *             than one sensors
>> + * @data: a private pointer (owned by the caller) that will be passed
>> + *        back, when a temperature reading is needed.
>> + * @get_temp: a pointer to a function that reads the sensor temperature.
>> + * @get_trend: a pointer to a function that reads the sensor temperature trend.
>> + *
>> + * This function will search the list of thermal zones described in device
>> + * tree and look for the zone that refer to the sensor device pointed by
>> + * @dev->of_node as temperature providers. For the zone pointing to the
>> + * sensor node, the sensor will be added to the DT thermal zone device.
>> + *
>> + * The thermal zone temperature is provided by the @get_temp function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * The thermal zone temperature trend is provided by the @get_trend function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * TODO:
>> + * 01 - This function must enqueue the new sensor instead of using
>> + * it as the only source of temperature values.
>> + *
>> + * 02 - There must be a way to match the sensor with all thermal zones
>> + * that refer to it.
>> + *
>> + * Return: On success returns a valid struct thermal_zone_device,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count >= 1) {
>> +                       id = sensor_specs.args[0];
>> +                       WARN(sensor_specs.args_count > 1,
>> +                            "%s: too many cells in sensor specifier %d\n",
>> +                            sensor_specs.np->name, sensor_specs.args_count);
>> +               } else {
>> +                       id = 0;
>> +               }
>> +
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
>> +
>> +/**
>> + * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
>> + *
>> + * This function removes the sensor callbacks and private data from the
>> + * thermal zone device registered with thermal_zone_of_sensor_register()
>> + * API. It will also silent the zone by remove the .get_temp() and .get_trend()
>> + * thermal zone device callbacks.
>> + *
>> + * TODO: When the support to several sensors per zone is added, this
>> + * function must search the sensor list based on @dev parameter.
>> + *
>> + */
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tzd)
>> +{
>> +       struct __thermal_zone *tz;
>> +
>> +       if (!dev || !tzd || !tzd->devdata)
>> +               return;
>> +
>> +       tz = tzd->devdata;
>> +
>> +       /* no __thermal_zone, nothing to be done */
>> +       if (!tz)
>> +               return;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tzd->ops->get_temp = NULL;
>> +       tzd->ops->get_trend = NULL;
>> +
>> +       tz->get_temp = NULL;
>> +       tz->get_trend = NULL;
>> +       tz->sensor_data = NULL;
>> +       mutex_unlock(&tzd->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
>> +
>> +/***   functions parsing device tree nodes   ***/
>> +
>> +/**
>> + * thermal_of_populate_bind_params - parse and fill cooling map data
>> + * @np: DT node containing a cooling-map node
>> + * @__tbp: data structure to be filled with cooling map info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-map type of node represented by
>> + * @np parameter and fills the read data into @__tbp data structure.
>> + * It needs the already parsed array of trip points of the thermal zone
>> + * in consideration.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_bind_params(struct device_node *np,
>> +                                          struct __thermal_bind_params *__tbp,
>> +                                          struct __thermal_trip *trips,
>> +                                          int ntrips)
>> +{
>> +       struct of_phandle_args cooling_spec;
>> +       struct device_node *trip;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       /* Default weight. Usage is optional */
>> +       __tbp->usage = 0;
>> +       ret = of_property_read_u32(np, "contribution", &prop);
>> +       if (ret == 0)
>> +               __tbp->usage = prop;
>> +
>> +       trip = of_parse_phandle(np, "trip", 0);
>> +       if (!trip) {
>> +               pr_err("missing trip property\n");
>> +               return -ENODEV;
>> +       }
>> +
>> +       /* match using device_node */
>> +       for (i = 0; i < ntrips; i++)
>> +               if (trip == trips[i].np) {
>> +                       __tbp->trip_id = i;
>> +                       break;
>> +               }
>> +
>> +       if (i == ntrips) {
>> +               ret = -ENODEV;
>> +               goto end;
>> +       }
>> +
>> +       ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
>> +                                        0, &cooling_spec);
>> +       if (ret < 0) {
>> +               pr_err("missing cooling_device property\n");
>> +               goto end;
>> +       }
>> +       __tbp->cooling_device = cooling_spec.np;
>> +       if (cooling_spec.args_count >= 2) { /* at least min and max */
>> +               __tbp->min = cooling_spec.args[0];
>> +               __tbp->max = cooling_spec.args[1];
>> +       } else {
>> +               pr_err("wrong reference to cooling device, missing limits\n");
>> +       }
>> +
>> +end:
>> +       of_node_put(trip);
>> +
>> +       return ret;
>> +}
>> +
>> +/**
>> + * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
>> + * into the device tree binding of 'trip', property type.
>> + */
>> +static const char * const trip_types[] = {
>> +       [THERMAL_TRIP_ACTIVE]   = "active",
>> +       [THERMAL_TRIP_PASSIVE]  = "passive",
>> +       [THERMAL_TRIP_HOT]      = "hot",
>> +       [THERMAL_TRIP_CRITICAL] = "critical",
>> +};
>> +
>> +/**
>> + * thermal_of_get_trip_type - Get phy mode for given device_node
>> + * @np:        Pointer to the given device_node
>> + * @type: Pointer to resulting trip type
>> + *
>> + * The function gets trip type string from property 'type',
>> + * and store its index in trip_types table in @type,
>> + *
>> + * Return: 0 on success, or errno in error case.
>> + */
>> +static int thermal_of_get_trip_type(struct device_node *np,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       const char *t;
>> +       int err, i;
>> +
>> +       err = of_property_read_string(np, "type", &t);
>> +       if (err < 0)
>> +               return err;
>> +
>> +       for (i = 0; i < ARRAY_SIZE(trip_types); i++)
>> +               if (!strcasecmp(t, trip_types[i])) {
>> +                       *type = i;
>> +                       return 0;
>> +               }
>> +
>> +       return -ENODEV;
>> +}
>> +
>> +/**
>> + * thermal_of_populate_trip - parse and fill one trip point data
>> + * @np: DT node containing a trip point node
>> + * @trip: trip point data structure to be filled up
>> + *
>> + * This function parses a trip point type of node represented by
>> + * @np parameter and fills the read data into @trip data structure.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_trip(struct device_node *np,
>> +                                   struct __thermal_trip *trip)
>> +{
>> +       int prop;
>> +       int ret;
>> +
>> +       ret = of_property_read_u32(np, "temperature", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing temperature property\n");
>> +               return ret;
>> +       }
>> +       trip->temperature = prop;
>> +
>> +       ret = of_property_read_u32(np, "hysteresis", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing hysteresis property\n");
>> +               return ret;
>> +       }
>> +       trip->hysteresis = prop;
>> +
>> +       ret = thermal_of_get_trip_type(np, &trip->type);
>> +       if (ret < 0) {
>> +               pr_err("wrong trip type property\n");
>> +               return ret;
>> +       }
>> +
>> +       /* Required for cooling map matching */
>> +       trip->np = np;
>> +
>> +       return 0;
>> +}
>> +
>> +/**
>> + * thermal_of_build_thermal_zone - parse and fill one thermal zone data
>> + * @np: DT node containing a thermal zone node
>> + *
>> + * This function parses a thermal zone type of node represented by
>> + * @np parameter and fills the read data into a __thermal_zone data structure
>> + * and return this pointer.
>> + *
>> + * TODO: Missing properties to parse: thermal-sensor-names and coefficients
>> + *
>> + * Return: On success returns a valid struct __thermal_zone,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +       struct device_node *child = NULL, *gchild;
>> +       struct __thermal_zone *tz;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       if (!np) {
>> +               pr_err("no thermal zone np\n");
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>> +       if (!tz)
>> +               return ERR_PTR(-ENOMEM);
>> +
>> +       ret = of_property_read_u32(np, "polling-delay-passive", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay-passive property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->passive_delay = prop;
>> +
>> +       ret = of_property_read_u32(np, "polling-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->polling_delay = prop;
>> +
>> +       /* trips */
>> +       child = of_get_child_by_name(np, "trips");
>> +
>> +       /* No trips provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->ntrips = of_get_child_count(child);
>> +       if (tz->ntrips == 0) /* must have at least one child */
>> +               goto finish;
>> +
>> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +       if (!tz->trips) {
>> +               ret = -ENOMEM;
>> +               goto free_tz;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild) {
>> +               ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +               if (ret)
>> +                       goto free_trips;
>> +       }
>> +
>> +       of_node_put(child);
>> +
>> +       /* cooling-maps */
>> +       child = of_get_child_by_name(np, "cooling-maps");
>> +
>> +       /* cooling-maps not provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->num_tbps = of_get_child_count(child);
>> +       if (tz->num_tbps == 0)
>> +               goto finish;
>> +
>> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +       if (!tz->tbps) {
>> +               ret = -ENOMEM;
>> +               goto free_trips;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +                                                     tz->trips, tz->ntrips);
>> +               if (ret)
>> +                       goto free_tbps;
>> +
>> +finish:
>> +       of_node_put(child);
>> +       tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +       return tz;
>> +
>> +free_tbps:
>> +       kfree(tz->tbps);
>> +free_trips:
>> +       kfree(tz->trips);
>> +free_tz:
>> +       kfree(tz);
>> +       of_node_put(child);
>> +
>> +       return ERR_PTR(ret);
>> +}
>> +
>> +static inline void of_thermal_free_zone(struct __thermal_zone *tz)
>> +{
>> +       kfree(tz->tbps);
>> +       kfree(tz->trips);
>> +       kfree(tz);
>> +}
>> +
>> +/**
>> + * of_parse_thermal_zones - parse device tree thermal data
>> + *
>> + * Initialization function that can be called by machine initialization
>> + * code to parse thermal data and populate the thermal framework
>> + * with hardware thermal zones info. This function only parses thermal zones.
>> + * Cooling devices and sensor devices nodes are supposed to be parsed
>> + * by their respective drivers.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + *
>> + */
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +       struct __thermal_zone *tz;
>> +       struct thermal_zone_device_ops *ops;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_debug("unable to find thermal zones\n");
>> +               return 0; /* Run successfully on systems without thermal DT */
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +               struct thermal_zone_params *tzp;
>> +
>> +               tz = thermal_of_build_thermal_zone(child);
>> +               if (IS_ERR(tz)) {
>> +                       pr_err("failed to build thermal zone %s: %ld\n",
>> +                              child->name,
>> +                              PTR_ERR(tz));
>> +                       continue;
>> +               }
>> +
>> +               ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
>> +               if (!ops)
>> +                       goto exit_free;
>> +
>> +               tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +               if (!tzp) {
>> +                       kfree(ops);
>> +                       goto exit_free;
>> +               }
>> +
>> +               /* No hwmon because there might be hwmon drivers registering */
>> +               tzp->no_hwmon = true;
>> +
>> +               zone = thermal_zone_device_register(child->name, tz->ntrips,
>> +                                                   0, tz,
>> +                                                   ops, tzp,
>> +                                                   tz->passive_delay,
>> +                                                   tz->polling_delay);
>> +               if (IS_ERR(zone)) {
>> +                       pr_err("Failed to build %s zone %ld\n", child->name,
>> +                              PTR_ERR(zone));
>> +                       kfree(tzp);
>> +                       kfree(ops);
>> +                       of_thermal_free_zone(tz);
>> +                       /* attempting to build remaining zones still */
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +exit_free:
>> +       of_thermal_free_zone(tz);
>> +
>> +       /* no memory available, so free what we have built */
>> +       of_thermal_destroy_zones();
>> +
>> +       return -ENOMEM;
>> +}
>> +
>> +/**
>> + * of_thermal_destroy_zones - remove all zones parsed and allocated resources
>> + *
>> + * Finds all zones parsed and added to the thermal framework and remove them
>> + * from the system, together with their resources.
>> + *
>> + */
>> +void __exit of_thermal_destroy_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_err("unable to find thermal zones\n");
>> +               return;
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +
>> +               zone = thermal_zone_get_zone_by_name(child->name);
>> +               if (IS_ERR(zone))
>> +                       continue;
>> +
>> +               thermal_zone_device_unregister(zone);
>> +               kfree(zone->tzp);
>> +               kfree(zone->ops);
>> +               of_thermal_free_zone(zone->devdata);
>> +       }
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index f7a9f4f..fec3351 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
>>   */
>>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
>>         int trips, int mask, void *devdata,
>> -       const struct thermal_zone_device_ops *ops,
>> +       struct thermal_zone_device_ops *ops,
>>         const struct thermal_zone_params *tzp,
>>         int passive_delay, int polling_delay)
>>  {
>> @@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
>>         if (result)
>>                 goto unregister_class;
>>
>> +       result = of_parse_thermal_zones();
>> +       if (result)
>> +               goto exit_netlink;
>> +
>>         return 0;
>>
>> +exit_netlink:
>> +       genetlink_exit();
>>  unregister_governors:
>>         thermal_unregister_governors();
>>  unregister_class:
>> @@ -1768,6 +1774,7 @@ error:
>>
>>  static void __exit thermal_exit(void)
>>  {
>> +       of_thermal_destroy_zones();
>>         genetlink_exit();
>>         class_unregister(&thermal_class);
>>         thermal_unregister_governors();
>> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
>> index 7cf2f66..3db339f 100644
>> --- a/drivers/thermal/thermal_core.h
>> +++ b/drivers/thermal/thermal_core.h
>> @@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
>>  static inline void thermal_gov_user_space_unregister(void) {}
>>  #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
>>
>> +/* device tree support */
>> +#ifdef CONFIG_THERMAL_OF
>> +int of_parse_thermal_zones(void);
>> +void of_thermal_destroy_zones(void);
>> +#else
>> +static inline int of_parse_thermal_zones(void) { return 0; }
>> +static inline void of_thermal_destroy_zones(void) { }
>> +#endif
>> +
>>  #endif /* __THERMAL_CORE_H__ */
>> diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
>> new file mode 100644
>> index 0000000..59c4581
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/thermal.h
>> @@ -0,0 +1,27 @@
>> +/*
>> + * This header provides constants for most thermal bindings.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *     Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>> + *
>> + * GPLv2 only
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
>> +#define _DT_BINDINGS_THERMAL_THERMAL_H
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE            "active"
>> +#define THERMAL_TRIP_PASSIVE           "passive"
>> +#define THERMAL_TRIP_HOT               "hot"
>> +#define THERMAL_TRIP_CRITICAL          "critical"
> 
> I don't like this. If someone wants to include this in a C file they can't do so
> at the same time as include/linux/thermal.h. The defined names are longer than
> the actual string values, and the comment makes it sound like these could be
> modified rather than being a fixed ABI.
> 
> I do not see the point of these constants.
> 
> Thanks,
> Mark.
> 
>> +
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT               (-1UL)
>> +
>> +#endif
>> +
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index b268d3c..b780c5b 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -143,6 +143,7 @@ struct thermal_cooling_device {
>>         int id;
>>         char type[THERMAL_NAME_LENGTH];
>>         struct device device;
>> +       struct device_node *np;
>>         void *devdata;
>>         const struct thermal_cooling_device_ops *ops;
>>         bool updated; /* true if the cooling device does not need update */
>> @@ -172,7 +173,7 @@ struct thermal_zone_device {
>>         int emul_temperature;
>>         int passive;
>>         unsigned int forced_passive;
>> -       const struct thermal_zone_device_ops *ops;
>> +       struct thermal_zone_device_ops *ops;
>>         const struct thermal_zone_params *tzp;
>>         struct thermal_governor *governor;
>>         struct list_head thermal_instances;
>> @@ -242,8 +243,31 @@ struct thermal_genl_event {
>>  };
>>
>>  /* Function declarations */
>> +#ifdef CONFIG_THERMAL_OF
>> +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 *));
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz);
>> +#else
>> +static inline 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 *))
>> +{
>> +       return NULL;
>> +}
>> +
>> +static inline
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz)
>> +{
>> +}
>> +
>> +#endif
>>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
>> -               void *, const struct thermal_zone_device_ops *,
>> +               void *, struct thermal_zone_device_ops *,
>>                 const struct thermal_zone_params *, int, int);
>>  void thermal_zone_device_unregister(struct thermal_zone_device *);
>>
>> --
>> 1.8.2.1.342.gfa7285d
>>
>>
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv8 03/18] thermal: introduce device tree parser
@ 2013-10-08 14:59         ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-10-08 14:59 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	grant.likely, linux, rui.zhang, wni, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 71685 bytes --]

On 07-10-2013 16:51, Mark Rutland wrote:
> Hi all,
> 
> Given that this is a complex new class of binding, I'd appreciate if at least
> one other device tree maintainer could also take a look over this and voice any
> concerns or suggestions. I've left the entire patch context for this.
> 

I agree with you. Did I miss someone in my To/Cc list? I got a couple of
review iterations by Stephen and Pawel (so, they are Copied) in the very
early stages of this work.

> Apologies for the munged whitespace -- my mail server appears to have helpfully
> and irreparably replaced all tabs with spaces.

I

> 
> On Tue, Oct 01, 2013 at 03:39:26AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: linux-pm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>> Hello Mark, folks,
>>
>> So, here is v8. Pretty small changes. Most are better
>> English phrasing in the binding document. It follows changelog:
>> - Several rephrasing in the binding document, including
>> spelling, grammar and better phrasing.
>> - Removed WiP warning from binding document.
>> - Several spacing and formatting changes in the binding document
>> - Used the '-specifier' nomenclature properly in the binding doc
>> - Removed the optional property 'thermal-sensors-names', because
>> it does not provide useful runtime information
>> - Fixed description of 'polling-delay-passive'
>> - Improved examples by adding comments and better explanation
>> - s/fw/framework/g
>> - Added a WARN when sensors specifiers are greater and 1.
>>
>> All best,
>>
>> Eduardo
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1520 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..ad06a8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,587 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +This file describes a generic binding to provide a way of
>> +defining hardware thermal structure using device tree.
> 
> s/defining/describing/

Well, I just want to avoid being prolix, and I dont really think we
loose context or meaning by using defining here.

> 
>> +A thermal structure includes thermal zones and their components,
>> +such as trip points, polling intervals, sensors and cooling devices
>> +binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects. The thermal device tree bindings are
>> +not about how the system must control or which algorithm or policy
>> +must be taken in place.
> 
> I'm not quite sure what this is saying -- it seems to contradict the
> design of the binding where trip points get linked to cooling device
> configuration, and thus we're defining a policy along the lines of "when
> sensor $W hits temperature $X, configure cooling device $Y with value
> $Z". I don't see how that can't be considered policy.

It is saying that describing these entities does not necessarily means
we are imposing policies, but that we are only describing the hardware
proprieties and knobs so that policies may be built on top of them.
There are plenty of algorithm to implement a control system, with
thermal is not different. We are not describing algorithms / policies,
but only focusing on hardware information and limits that we can extract
and use them to control the system.

For instance, there is no obligation to implement a closed loop
proportional-integral-derivative controller. Nor there is a strong
implication to implement a simple stepping control algorithm. But with
the hardware description flexibility we are providing with this binding,
for sure it is possible to choose one of the referred policies. We are
describing data points, so that the logic to use them can be picked out
of OS design decision.

I don't thing that matching cooling devices with trip points of sensors
on a thermal zone is defining thermal policy. This matching, to me at
least, it is a direct outcome of describing your hardware and its
limits. There are a couple of steps ahead of it to have a finalized
thermal policy.

> 
> At best, we can say that policy is being defined because describing the
> physical properties of a device and dealing with this at runtime is not
> feasible.

OK. I see it slightly different, as I mentioned above. We are describing
physical properties and letting OSes to deal with them the way they choose.

> 
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
> 
> - thermal sensors: devices which may be used to take temperature
>   measurements.
> 
>> +- cooling devices: used to describe devices source of power dissipation control;
> 
> - cooling devices: devices which may be used to dissipate heat.
> 
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
> 
> - trip points: describe key temperatures at which cooling is recommended. The
>   set of points should be chosen based on hardware limits.
> 
>> +- cooling maps: used to describe links between trip points and cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
> 
> How about:
> 
> The following is a description of each of these node types.


OK, for the above suggestions.

> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0 on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling (DVFS), and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
> 
> I'd probably say "heat dissipation" rather than "power dissipation", unless
> this is a technical term I am not aware of?
> 
> Why is the determination of the state of the cooling device important?
> 
>> +
>> +Required properties:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
> 
> Is it assumed that all the values between min and max are valid, or might this
> be a sparse set of cooling values?

I am assuming they are valid states.

> 
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
> 
> What is it relative to?
> 
> Why is 'temperature' in quotes?

They relative to the temperature property, describe above. I am
rephrasing this to avoid misunderstanding.

a (low) hysteresis value on temperature property (above).

> 
>> +
>> +- type:                        a string containing the trip type. Supported values are:
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
> 
> Why?

That was originally suggested by swarren, but I was using integer
constants. I kept the his suggestion though, despite the type.

> 
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle of     referring to which cooling device is used in this
>> +    cooling device     binding. In the cooling specifier, the first cell
>> +                       is the minimum cooling state and the second cell
>> +                       is the maximum cooling state used in this map.
> 
> The type is wrong here -- it's a phandle + cooling-cells, not just a phandle.

I suppose you meant phandle + cooling specifier.

And yes, I am fixing that.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle of     zone.
>> +   trip point node
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling state used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling state used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one sub-node
>> +containing trip nodes and one sub-node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell
>> +
>> +- polling-delay-passive: The maximum number of milliseconds to wait
>> +  Type: unsigned       between polls when performing passive cooling.
>> +  Size: one cell
>> +
>> +- thermal-sensors:     A list of thermal sensor phandles and sensor specifier
>> +  Type: list of        used while monitoring the thermal zone.
>> +  sensor phandles
> 
> The type is wrong here. A list of phandle + sensor specifiers.

OK.

> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors listed in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offset.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when passive cooling is activated (polling-delay-passive); and
>> +(ii) - when the zone just needs to be monitored (polling-delay) or
>> +when active cooling is activated.
>> +
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability. The delays should be chosen to account for said max dT/dt,
>> +such that a device does not cross several trip boundaries unexpectedly
>> +between polls. Choosing the right polling delays shall avoid having the
>> +device in temperature ranges that may damage the silicon structures and
>> +reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes". The "thermal-zones" node appears under "/".
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       /*
>> +        * Here is an example of describing a cooling device for a DVFS
>> +        * capable CPU. The CPU node describes its four OPPs.
>> +        * The cooling states possible are 0..3, and they are
>> +        * used as OPP indexes. The minimum cooling state is 0, which means
>> +        * all four OPPs can be available to the system. The maximum
>> +        * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
>> +        * can be available in the system.
>> +        */
>> +       cpu0: cpu@0 {
>> +               ...
>> +               operating-points = <
>> +                       /* kHz    uV */
>> +                       970000  1200000
>> +                       792000  1100000
>> +                       396000  950000
>> +                       198000  850000
>> +               >;
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple fan controller which supports 10 speeds of operation
>> +        * (represented as 0-9).
>> +        */
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>;
>> +
>> +               trips {
>> +                       cpu-alert0: cpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "active";
>> +                       };
>> +                       cpu-alert1: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-alert0>;
>> +                               cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device =
>> +                                   <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
>> +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
>> +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
>> +different cooling states 0-9. It is used to remove the heat out of
>> +the thermal zone 'cpu-thermal' using its cooling states
>> +from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
>> +temperature of 125C, represented by the trip point 'cpu-crit', the silicon
>> +is not reliable anymore.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with several bandgap temperature sensors.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <1>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     0>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       cpu-alert: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       gpu-thermal: gpu-thermal {
>> +               polling-delay-passive = <120>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     1>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       gpu-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-crit: gpu-crit {
>> +                               temperature = <105000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       dsp-thermal: dsp-thermal {
>> +               polling-delay-passive = <50>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     2>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       dsp-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       dsp-crit: gpu-crit {
>> +                               temperature = <135000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first cell of the sensor
>> +specifier as sensor ID. In the example, then, <bandgap 0> is used to
>> +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
>> +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
>> +may be uncorrelated, having its own dT/dt requirements, trips
>> +and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple IC with a single temperature sensor.
>> +        */
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>,  /* cpu */
>> +                                 <&adc>;       /* pcb north */
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +               coefficients =          <100    -120    484>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrates this situation.
>> +For instance, it may be the case that a sensor external to CPU IP may be placed
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. Assuming this is the case for the above example,
>> +the hypothetical extrapolation rule would be:
>> +               hotspot = 100 * bandgap - 120 * adc + 484
>> +
>> +In other context, the same idea can be used to add fixed offset. For instance,
>> +consider the hotspot extrapolation rule below:
>> +               hotspot = 1 * adc + 6000
>> +
>> +In the above equation, the hotspot is always 6C higher than what is read
>> +from the ADC sensor. The binding would be then:
>> +        thermal-sensors =  <&adc>;
>> +
>> +               /* hotspot = 1 * adc + 6000 */
>> +       coefficients =          <1      6000>;
>> +
>> +(d) - Board thermal
>> +
>> +The board thermal example below illustrates how to setup one thermal zone
>> +with many sensors and many cooling devices.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * An IC with several temperature sensor.
>> +        */
>> +       adc-dummy: sensor@0x50 {
>> +               ...
>> +               #thermal-sensor-cells = <1>; /* sensor internal ID */
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       batt-thermal {
>> +               polling-delay-passive = <500>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     4>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +
>> +       board-thermal: board-thermal {
>> +               polling-delay-passive = <1000>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
>> +                                 <&adc-dummy     1>, /* lcd */
>> +                                 <&adc-dymmy     2>; /* back cover */
>> +               /*
>> +                * An array of coefficients describing the sensor
>> +                * linear relation. E.g.:
>> +                * z = c1*x1 + c2*x2 + c3*x3
>> +                */
>> +               coefficients =          <1200   -345    890>;
>> +
>> +               trips {
>> +                       /* Trips are based on resulting linear equation */
>> +                       cpu-trip: cpu-trip {
>> +                               temperature = <60000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-trip: gpu-trip {
>> +                               temperature = <55000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       }
>> +                       lcd-trip: lcp-trip {
>> +                               temperature = <53000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       crit-trip: crit-trip {
>> +                               temperature = <68000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-trip>;
>> +                               cooling-device = <&cpu0 0 2>;
>> +                               contribution = <55>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&gpu-trip>;
>> +                               cooling-device = <&gpu0 0 2>;
>> +                               contribution = <20>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&lcd-trip>;
>> +                               cooling-device = <&lcd0 5 10>;
>> +                               contribution = <15>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +The above example is a mix of previous examples, a sensor IP with several internal
>> +sensors used to monitor different zones, one of them is composed by several sensors and
>> +with different cooling devices.
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index dbfc390..dd81eb8 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,6 +29,19 @@ config THERMAL_HWMON
>>           Say 'Y' here if you want all thermal sensors to
>>           have hwmon sysfs interface too.
>>
>> +config THERMAL_OF
>> +       bool
>> +       prompt "APIs to parse thermal data out of device tree"
>> +       depends on OF
>> +       default y
>> +       help
>> +         This options provides helpers to add the support to
>> +         read and parse thermal data definitions out of the
>> +         device tree blob.
>> +
>> +         Say 'Y' here if you need to build thermal infrastructure
>> +         based on device tree.
>> +
>>  choice
>>         prompt "Default Thermal governor"
>>         default THERMAL_DEFAULT_GOV_STEP_WISE
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 584b363..4b03956 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -7,6 +7,7 @@ thermal_sys-y                   += thermal_core.o
>>
>>  # interface to/from other layers providing sensors
>>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
>> +thermal_sys-$(CONFIG_THERMAL_OF)               += of-thermal.o
>>
>>  # governors
>>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> new file mode 100644
>> index 0000000..66f9eb2
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,849 @@
>> +/*
>> + *  of-thermal.c - Generic Thermal Management device tree support.
>> + *
>> + *  Copyright (C) 2013 Texas Instruments
>> + *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + *
>> + *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation; version 2 of the License.
>> + *
>> + *  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.
>> + *
>> + *  You should have received a copy of the GNU General Public License along
>> + *  with this program; if not, write to the Free Software Foundation, Inc.,
>> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +#include <linux/thermal.h>
>> +#include <linux/slab.h>
>> +#include <linux/types.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/string.h>
>> +
>> +#include "thermal_core.h"
>> +
>> +/***   Private data structures to represent thermal device tree data ***/
>> +
>> +/**
>> + * struct __thermal_trip - representation of a point in temperature domain
>> + * @np: pointer to struct device_node that this trip point was created from
>> + * @temperature: temperature value in miliCelsius
>> + * @hysteresis: relative hysteresis in miliCelsius
>> + * @type: trip point type
>> + */
>> +
>> +struct __thermal_trip {
>> +       struct device_node *np;
>> +       unsigned long int temperature;
>> +       unsigned long int hysteresis;
>> +       enum thermal_trip_type type;
>> +};
>> +
>> +/**
>> + * struct __thermal_bind_param - a match between trip and cooling device
>> + * @cooling_device: a pointer to identify the referred cooling device
>> + * @trip_id: the trip point index
>> + * @usage: the percentage (from 0 to 100) of cooling contribution
>> + * @min: minimum cooling state used at this trip point
>> + * @max: maximum cooling state used at this trip point
>> + */
>> +
>> +struct __thermal_bind_params {
>> +       struct device_node *cooling_device;
>> +       unsigned int trip_id;
>> +       unsigned int usage;
>> +       unsigned long min;
>> +       unsigned long max;
>> +};
>> +
>> +/**
>> + * struct __thermal_zone - internal representation of a thermal zone
>> + * @mode: current thermal zone device mode (enabled/disabled)
>> + * @passive_delay: polling interval while passive cooling is activated
>> + * @polling_delay: zone polling interval
>> + * @ntrips: number of trip points
>> + * @trips: an array of trip points (0..ntrips - 1)
>> + * @num_tbps: number of thermal bind params
>> + * @tbps: an array of thermal bind params (0..num_tbps - 1)
>> + * @sensor_data: sensor private data used while reading temperature and trend
>> + * @get_temp: sensor callback to read temperature
>> + * @get_trend: sensor callback to read temperature trend
>> + */
>> +
>> +struct __thermal_zone {
>> +       enum thermal_device_mode mode;
>> +       int passive_delay;
>> +       int polling_delay;
>> +
>> +       /* trip data */
>> +       int ntrips;
>> +       struct __thermal_trip *trips;
>> +
>> +       /* cooling binding data */
>> +       int num_tbps;
>> +       struct __thermal_bind_params *tbps;
>> +
>> +       /* sensor interface */
>> +       void *sensor_data;
>> +       int (*get_temp)(void *, long *);
>> +       int (*get_trend)(void *, long *);
>> +};
>> +
>> +/***   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;
>> +
>> +       if (!data->get_temp)
>> +               return -EINVAL;
>> +
>> +       return data->get_temp(data->sensor_data, temp);
>> +}
>> +
>> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
>> +                               enum thermal_trend *trend)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       long dev_trend;
>> +       int r;
>> +
>> +       if (!data->get_trend)
>> +               return -EINVAL;
>> +
>> +       r = data->get_trend(data->sensor_data, &dev_trend);
>> +       if (r)
>> +               return r;
>> +
>> +       /* TODO: These intervals might have some thresholds, but in core code */
>> +       if (dev_trend > 0)
>> +               *trend = THERMAL_TREND_RAISING;
>> +       else if (dev_trend < 0)
>> +               *trend = THERMAL_TREND_DROPPING;
>> +       else
>> +               *trend = THERMAL_TREND_STABLE;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_bind(struct thermal_zone_device *thermal,
>> +                          struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to bind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_bind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev,
>> +                                               tbp->min,
>> +                                               tbp->max);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_unbind(struct thermal_zone_device *thermal,
>> +                            struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to unbind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_unbind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode *mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       *mode = data->mode;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       mutex_lock(&tz->lock);
>> +
>> +       if (mode == THERMAL_DEVICE_ENABLED)
>> +               tz->polling_delay = data->polling_delay;
>> +       else
>> +               tz->polling_delay = 0;
>> +
>> +       mutex_unlock(&tz->lock);
>> +
>> +       data->mode = mode;
>> +       thermal_zone_device_update(tz);
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *type = data->trips[trip].type;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *temp = data->trips[trip].temperature;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *hyst = data->trips[trip].hysteresis;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].hysteresis = hyst;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       int i;
>> +
>> +       for (i = 0; i < data->ntrips; i++)
>> +               if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
>> +                       *temp = data->trips[i].temperature;
>> +                       return 0;
>> +               }
>> +
>> +       return -EINVAL;
>> +}
>> +
>> +static struct thermal_zone_device_ops of_thermal_ops = {
>> +       .get_mode = of_thermal_get_mode,
>> +       .set_mode = of_thermal_set_mode,
>> +
>> +       .get_trip_type = of_thermal_get_trip_type,
>> +       .get_trip_temp = of_thermal_get_trip_temp,
>> +       .set_trip_temp = of_thermal_set_trip_temp,
>> +       .get_trip_hyst = of_thermal_get_trip_hyst,
>> +       .set_trip_hyst = of_thermal_set_trip_hyst,
>> +       .get_crit_temp = of_thermal_get_crit_temp,
>> +
>> +       .bind = of_thermal_bind,
>> +       .unbind = of_thermal_unbind,
>> +};
>> +
>> +/***   sensor API   ***/
>> +
>> +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 *))
>> +{
>> +       struct thermal_zone_device *tzd;
>> +       struct __thermal_zone *tz;
>> +
>> +       tzd = thermal_zone_get_zone_by_name(zone->name);
>> +       if (IS_ERR(tzd))
>> +               return ERR_PTR(-EPROBE_DEFER);
>> +
>> +       tz = tzd->devdata;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tz->get_temp = get_temp;
>> +       tz->get_trend = get_trend;
>> +       tz->sensor_data = data;
>> +
>> +       tzd->ops->get_temp = of_thermal_get_temp;
>> +       tzd->ops->get_trend = of_thermal_get_trend;
>> +       mutex_unlock(&tzd->lock);
>> +
>> +       return tzd;
>> +}
>> +
>> +/**
>> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @sensor_id: a sensor identifier, in case the sensor IP has more
>> + *             than one sensors
>> + * @data: a private pointer (owned by the caller) that will be passed
>> + *        back, when a temperature reading is needed.
>> + * @get_temp: a pointer to a function that reads the sensor temperature.
>> + * @get_trend: a pointer to a function that reads the sensor temperature trend.
>> + *
>> + * This function will search the list of thermal zones described in device
>> + * tree and look for the zone that refer to the sensor device pointed by
>> + * @dev->of_node as temperature providers. For the zone pointing to the
>> + * sensor node, the sensor will be added to the DT thermal zone device.
>> + *
>> + * The thermal zone temperature is provided by the @get_temp function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * The thermal zone temperature trend is provided by the @get_trend function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * TODO:
>> + * 01 - This function must enqueue the new sensor instead of using
>> + * it as the only source of temperature values.
>> + *
>> + * 02 - There must be a way to match the sensor with all thermal zones
>> + * that refer to it.
>> + *
>> + * Return: On success returns a valid struct thermal_zone_device,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count >= 1) {
>> +                       id = sensor_specs.args[0];
>> +                       WARN(sensor_specs.args_count > 1,
>> +                            "%s: too many cells in sensor specifier %d\n",
>> +                            sensor_specs.np->name, sensor_specs.args_count);
>> +               } else {
>> +                       id = 0;
>> +               }
>> +
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
>> +
>> +/**
>> + * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
>> + *
>> + * This function removes the sensor callbacks and private data from the
>> + * thermal zone device registered with thermal_zone_of_sensor_register()
>> + * API. It will also silent the zone by remove the .get_temp() and .get_trend()
>> + * thermal zone device callbacks.
>> + *
>> + * TODO: When the support to several sensors per zone is added, this
>> + * function must search the sensor list based on @dev parameter.
>> + *
>> + */
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tzd)
>> +{
>> +       struct __thermal_zone *tz;
>> +
>> +       if (!dev || !tzd || !tzd->devdata)
>> +               return;
>> +
>> +       tz = tzd->devdata;
>> +
>> +       /* no __thermal_zone, nothing to be done */
>> +       if (!tz)
>> +               return;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tzd->ops->get_temp = NULL;
>> +       tzd->ops->get_trend = NULL;
>> +
>> +       tz->get_temp = NULL;
>> +       tz->get_trend = NULL;
>> +       tz->sensor_data = NULL;
>> +       mutex_unlock(&tzd->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
>> +
>> +/***   functions parsing device tree nodes   ***/
>> +
>> +/**
>> + * thermal_of_populate_bind_params - parse and fill cooling map data
>> + * @np: DT node containing a cooling-map node
>> + * @__tbp: data structure to be filled with cooling map info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-map type of node represented by
>> + * @np parameter and fills the read data into @__tbp data structure.
>> + * It needs the already parsed array of trip points of the thermal zone
>> + * in consideration.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_bind_params(struct device_node *np,
>> +                                          struct __thermal_bind_params *__tbp,
>> +                                          struct __thermal_trip *trips,
>> +                                          int ntrips)
>> +{
>> +       struct of_phandle_args cooling_spec;
>> +       struct device_node *trip;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       /* Default weight. Usage is optional */
>> +       __tbp->usage = 0;
>> +       ret = of_property_read_u32(np, "contribution", &prop);
>> +       if (ret == 0)
>> +               __tbp->usage = prop;
>> +
>> +       trip = of_parse_phandle(np, "trip", 0);
>> +       if (!trip) {
>> +               pr_err("missing trip property\n");
>> +               return -ENODEV;
>> +       }
>> +
>> +       /* match using device_node */
>> +       for (i = 0; i < ntrips; i++)
>> +               if (trip == trips[i].np) {
>> +                       __tbp->trip_id = i;
>> +                       break;
>> +               }
>> +
>> +       if (i == ntrips) {
>> +               ret = -ENODEV;
>> +               goto end;
>> +       }
>> +
>> +       ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
>> +                                        0, &cooling_spec);
>> +       if (ret < 0) {
>> +               pr_err("missing cooling_device property\n");
>> +               goto end;
>> +       }
>> +       __tbp->cooling_device = cooling_spec.np;
>> +       if (cooling_spec.args_count >= 2) { /* at least min and max */
>> +               __tbp->min = cooling_spec.args[0];
>> +               __tbp->max = cooling_spec.args[1];
>> +       } else {
>> +               pr_err("wrong reference to cooling device, missing limits\n");
>> +       }
>> +
>> +end:
>> +       of_node_put(trip);
>> +
>> +       return ret;
>> +}
>> +
>> +/**
>> + * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
>> + * into the device tree binding of 'trip', property type.
>> + */
>> +static const char * const trip_types[] = {
>> +       [THERMAL_TRIP_ACTIVE]   = "active",
>> +       [THERMAL_TRIP_PASSIVE]  = "passive",
>> +       [THERMAL_TRIP_HOT]      = "hot",
>> +       [THERMAL_TRIP_CRITICAL] = "critical",
>> +};
>> +
>> +/**
>> + * thermal_of_get_trip_type - Get phy mode for given device_node
>> + * @np:        Pointer to the given device_node
>> + * @type: Pointer to resulting trip type
>> + *
>> + * The function gets trip type string from property 'type',
>> + * and store its index in trip_types table in @type,
>> + *
>> + * Return: 0 on success, or errno in error case.
>> + */
>> +static int thermal_of_get_trip_type(struct device_node *np,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       const char *t;
>> +       int err, i;
>> +
>> +       err = of_property_read_string(np, "type", &t);
>> +       if (err < 0)
>> +               return err;
>> +
>> +       for (i = 0; i < ARRAY_SIZE(trip_types); i++)
>> +               if (!strcasecmp(t, trip_types[i])) {
>> +                       *type = i;
>> +                       return 0;
>> +               }
>> +
>> +       return -ENODEV;
>> +}
>> +
>> +/**
>> + * thermal_of_populate_trip - parse and fill one trip point data
>> + * @np: DT node containing a trip point node
>> + * @trip: trip point data structure to be filled up
>> + *
>> + * This function parses a trip point type of node represented by
>> + * @np parameter and fills the read data into @trip data structure.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_trip(struct device_node *np,
>> +                                   struct __thermal_trip *trip)
>> +{
>> +       int prop;
>> +       int ret;
>> +
>> +       ret = of_property_read_u32(np, "temperature", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing temperature property\n");
>> +               return ret;
>> +       }
>> +       trip->temperature = prop;
>> +
>> +       ret = of_property_read_u32(np, "hysteresis", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing hysteresis property\n");
>> +               return ret;
>> +       }
>> +       trip->hysteresis = prop;
>> +
>> +       ret = thermal_of_get_trip_type(np, &trip->type);
>> +       if (ret < 0) {
>> +               pr_err("wrong trip type property\n");
>> +               return ret;
>> +       }
>> +
>> +       /* Required for cooling map matching */
>> +       trip->np = np;
>> +
>> +       return 0;
>> +}
>> +
>> +/**
>> + * thermal_of_build_thermal_zone - parse and fill one thermal zone data
>> + * @np: DT node containing a thermal zone node
>> + *
>> + * This function parses a thermal zone type of node represented by
>> + * @np parameter and fills the read data into a __thermal_zone data structure
>> + * and return this pointer.
>> + *
>> + * TODO: Missing properties to parse: thermal-sensor-names and coefficients
>> + *
>> + * Return: On success returns a valid struct __thermal_zone,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +       struct device_node *child = NULL, *gchild;
>> +       struct __thermal_zone *tz;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       if (!np) {
>> +               pr_err("no thermal zone np\n");
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>> +       if (!tz)
>> +               return ERR_PTR(-ENOMEM);
>> +
>> +       ret = of_property_read_u32(np, "polling-delay-passive", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay-passive property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->passive_delay = prop;
>> +
>> +       ret = of_property_read_u32(np, "polling-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->polling_delay = prop;
>> +
>> +       /* trips */
>> +       child = of_get_child_by_name(np, "trips");
>> +
>> +       /* No trips provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->ntrips = of_get_child_count(child);
>> +       if (tz->ntrips == 0) /* must have at least one child */
>> +               goto finish;
>> +
>> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +       if (!tz->trips) {
>> +               ret = -ENOMEM;
>> +               goto free_tz;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild) {
>> +               ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +               if (ret)
>> +                       goto free_trips;
>> +       }
>> +
>> +       of_node_put(child);
>> +
>> +       /* cooling-maps */
>> +       child = of_get_child_by_name(np, "cooling-maps");
>> +
>> +       /* cooling-maps not provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->num_tbps = of_get_child_count(child);
>> +       if (tz->num_tbps == 0)
>> +               goto finish;
>> +
>> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +       if (!tz->tbps) {
>> +               ret = -ENOMEM;
>> +               goto free_trips;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +                                                     tz->trips, tz->ntrips);
>> +               if (ret)
>> +                       goto free_tbps;
>> +
>> +finish:
>> +       of_node_put(child);
>> +       tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +       return tz;
>> +
>> +free_tbps:
>> +       kfree(tz->tbps);
>> +free_trips:
>> +       kfree(tz->trips);
>> +free_tz:
>> +       kfree(tz);
>> +       of_node_put(child);
>> +
>> +       return ERR_PTR(ret);
>> +}
>> +
>> +static inline void of_thermal_free_zone(struct __thermal_zone *tz)
>> +{
>> +       kfree(tz->tbps);
>> +       kfree(tz->trips);
>> +       kfree(tz);
>> +}
>> +
>> +/**
>> + * of_parse_thermal_zones - parse device tree thermal data
>> + *
>> + * Initialization function that can be called by machine initialization
>> + * code to parse thermal data and populate the thermal framework
>> + * with hardware thermal zones info. This function only parses thermal zones.
>> + * Cooling devices and sensor devices nodes are supposed to be parsed
>> + * by their respective drivers.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + *
>> + */
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +       struct __thermal_zone *tz;
>> +       struct thermal_zone_device_ops *ops;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_debug("unable to find thermal zones\n");
>> +               return 0; /* Run successfully on systems without thermal DT */
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +               struct thermal_zone_params *tzp;
>> +
>> +               tz = thermal_of_build_thermal_zone(child);
>> +               if (IS_ERR(tz)) {
>> +                       pr_err("failed to build thermal zone %s: %ld\n",
>> +                              child->name,
>> +                              PTR_ERR(tz));
>> +                       continue;
>> +               }
>> +
>> +               ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
>> +               if (!ops)
>> +                       goto exit_free;
>> +
>> +               tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +               if (!tzp) {
>> +                       kfree(ops);
>> +                       goto exit_free;
>> +               }
>> +
>> +               /* No hwmon because there might be hwmon drivers registering */
>> +               tzp->no_hwmon = true;
>> +
>> +               zone = thermal_zone_device_register(child->name, tz->ntrips,
>> +                                                   0, tz,
>> +                                                   ops, tzp,
>> +                                                   tz->passive_delay,
>> +                                                   tz->polling_delay);
>> +               if (IS_ERR(zone)) {
>> +                       pr_err("Failed to build %s zone %ld\n", child->name,
>> +                              PTR_ERR(zone));
>> +                       kfree(tzp);
>> +                       kfree(ops);
>> +                       of_thermal_free_zone(tz);
>> +                       /* attempting to build remaining zones still */
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +exit_free:
>> +       of_thermal_free_zone(tz);
>> +
>> +       /* no memory available, so free what we have built */
>> +       of_thermal_destroy_zones();
>> +
>> +       return -ENOMEM;
>> +}
>> +
>> +/**
>> + * of_thermal_destroy_zones - remove all zones parsed and allocated resources
>> + *
>> + * Finds all zones parsed and added to the thermal framework and remove them
>> + * from the system, together with their resources.
>> + *
>> + */
>> +void __exit of_thermal_destroy_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_err("unable to find thermal zones\n");
>> +               return;
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +
>> +               zone = thermal_zone_get_zone_by_name(child->name);
>> +               if (IS_ERR(zone))
>> +                       continue;
>> +
>> +               thermal_zone_device_unregister(zone);
>> +               kfree(zone->tzp);
>> +               kfree(zone->ops);
>> +               of_thermal_free_zone(zone->devdata);
>> +       }
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index f7a9f4f..fec3351 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
>>   */
>>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
>>         int trips, int mask, void *devdata,
>> -       const struct thermal_zone_device_ops *ops,
>> +       struct thermal_zone_device_ops *ops,
>>         const struct thermal_zone_params *tzp,
>>         int passive_delay, int polling_delay)
>>  {
>> @@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
>>         if (result)
>>                 goto unregister_class;
>>
>> +       result = of_parse_thermal_zones();
>> +       if (result)
>> +               goto exit_netlink;
>> +
>>         return 0;
>>
>> +exit_netlink:
>> +       genetlink_exit();
>>  unregister_governors:
>>         thermal_unregister_governors();
>>  unregister_class:
>> @@ -1768,6 +1774,7 @@ error:
>>
>>  static void __exit thermal_exit(void)
>>  {
>> +       of_thermal_destroy_zones();
>>         genetlink_exit();
>>         class_unregister(&thermal_class);
>>         thermal_unregister_governors();
>> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
>> index 7cf2f66..3db339f 100644
>> --- a/drivers/thermal/thermal_core.h
>> +++ b/drivers/thermal/thermal_core.h
>> @@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
>>  static inline void thermal_gov_user_space_unregister(void) {}
>>  #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
>>
>> +/* device tree support */
>> +#ifdef CONFIG_THERMAL_OF
>> +int of_parse_thermal_zones(void);
>> +void of_thermal_destroy_zones(void);
>> +#else
>> +static inline int of_parse_thermal_zones(void) { return 0; }
>> +static inline void of_thermal_destroy_zones(void) { }
>> +#endif
>> +
>>  #endif /* __THERMAL_CORE_H__ */
>> diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
>> new file mode 100644
>> index 0000000..59c4581
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/thermal.h
>> @@ -0,0 +1,27 @@
>> +/*
>> + * This header provides constants for most thermal bindings.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *     Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + * GPLv2 only
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
>> +#define _DT_BINDINGS_THERMAL_THERMAL_H
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE            "active"
>> +#define THERMAL_TRIP_PASSIVE           "passive"
>> +#define THERMAL_TRIP_HOT               "hot"
>> +#define THERMAL_TRIP_CRITICAL          "critical"
> 
> I don't like this. If someone wants to include this in a C file they can't do so
> at the same time as include/linux/thermal.h. The defined names are longer than
> the actual string values, and the comment makes it sound like these could be
> modified rather than being a fixed ABI.
> 
> I do not see the point of these constants.
> 
> Thanks,
> Mark.
> 
>> +
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT               (-1UL)
>> +
>> +#endif
>> +
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index b268d3c..b780c5b 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -143,6 +143,7 @@ struct thermal_cooling_device {
>>         int id;
>>         char type[THERMAL_NAME_LENGTH];
>>         struct device device;
>> +       struct device_node *np;
>>         void *devdata;
>>         const struct thermal_cooling_device_ops *ops;
>>         bool updated; /* true if the cooling device does not need update */
>> @@ -172,7 +173,7 @@ struct thermal_zone_device {
>>         int emul_temperature;
>>         int passive;
>>         unsigned int forced_passive;
>> -       const struct thermal_zone_device_ops *ops;
>> +       struct thermal_zone_device_ops *ops;
>>         const struct thermal_zone_params *tzp;
>>         struct thermal_governor *governor;
>>         struct list_head thermal_instances;
>> @@ -242,8 +243,31 @@ struct thermal_genl_event {
>>  };
>>
>>  /* Function declarations */
>> +#ifdef CONFIG_THERMAL_OF
>> +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 *));
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz);
>> +#else
>> +static inline 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 *))
>> +{
>> +       return NULL;
>> +}
>> +
>> +static inline
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz)
>> +{
>> +}
>> +
>> +#endif
>>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
>> -               void *, const struct thermal_zone_device_ops *,
>> +               void *, struct thermal_zone_device_ops *,
>>                 const struct thermal_zone_params *, int, int);
>>  void thermal_zone_device_unregister(struct thermal_zone_device *);
>>
>> --
>> 1.8.2.1.342.gfa7285d
>>
>>
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv8 03/18] thermal: introduce device tree parser
  2013-10-07 20:51       ` [lm-sensors] " Mark Rutland
@ 2013-11-05 18:08         ` Eduardo Valentin
  -1 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-11-05 18:08 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	grant.likely, linux, rui.zhang, wni, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 69857 bytes --]

Hello device tree maintainers,

On 07-10-2013 16:51, Mark Rutland wrote:
> Hi all,
> 
> Given that this is a complex new class of binding, I'd appreciate if at least
> one other device tree maintainer could also take a look over this and voice any
> concerns or suggestions. I've left the entire patch context for this.

Here is just a gentle reminder. Looks like no one else has had the time
to provide us a third opinion on this work. Shall we continue
progressing here? Its been about four weeks the series is waiting on
extra feedback.

I was on paternity leave :-) So, getting back to get this one rolling.

> 
> Apologies for the munged whitespace -- my mail server appears to have helpfully
> and irreparably replaced all tabs with spaces.
> 
> On Tue, Oct 01, 2013 at 03:39:26AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: linux-pm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>> Hello Mark, folks,
>>
>> So, here is v8. Pretty small changes. Most are better
>> English phrasing in the binding document. It follows changelog:
>> - Several rephrasing in the binding document, including
>> spelling, grammar and better phrasing.
>> - Removed WiP warning from binding document.
>> - Several spacing and formatting changes in the binding document
>> - Used the '-specifier' nomenclature properly in the binding doc
>> - Removed the optional property 'thermal-sensors-names', because
>> it does not provide useful runtime information
>> - Fixed description of 'polling-delay-passive'
>> - Improved examples by adding comments and better explanation
>> - s/fw/framework/g
>> - Added a WARN when sensors specifiers are greater and 1.
>>
>> All best,
>>
>> Eduardo
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1520 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..ad06a8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,587 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +This file describes a generic binding to provide a way of
>> +defining hardware thermal structure using device tree.
> 
> s/defining/describing/
> 
>> +A thermal structure includes thermal zones and their components,
>> +such as trip points, polling intervals, sensors and cooling devices
>> +binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects. The thermal device tree bindings are
>> +not about how the system must control or which algorithm or policy
>> +must be taken in place.
> 
> I'm not quite sure what this is saying -- it seems to contradict the
> design of the binding where trip points get linked to cooling device
> configuration, and thus we're defining a policy along the lines of "when
> sensor $W hits temperature $X, configure cooling device $Y with value
> $Z". I don't see how that can't be considered policy.
> 
> At best, we can say that policy is being defined because describing the
> physical properties of a device and dealing with this at runtime is not
> feasible.
> 
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
> 
> - thermal sensors: devices which may be used to take temperature
>   measurements.
> 
>> +- cooling devices: used to describe devices source of power dissipation control;
> 
> - cooling devices: devices which may be used to dissipate heat.
> 
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
> 
> - trip points: describe key temperatures at which cooling is recommended. The
>   set of points should be chosen based on hardware limits.
> 
>> +- cooling maps: used to describe links between trip points and cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
> 
> How about:
> 
> The following is a description of each of these node types.
> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0 on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling (DVFS), and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
> 
> I'd probably say "heat dissipation" rather than "power dissipation", unless
> this is a technical term I am not aware of?
> 
> Why is the determination of the state of the cooling device important?
> 
>> +
>> +Required properties:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
> 
> Is it assumed that all the values between min and max are valid, or might this
> be a sparse set of cooling values?
> 
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
> 
> What is it relative to?
> 
> Why is 'temperature' in quotes?
> 
>> +
>> +- type:                        a string containing the trip type. Supported values are:
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
> 
> Why?
> 
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle of     referring to which cooling device is used in this
>> +    cooling device     binding. In the cooling specifier, the first cell
>> +                       is the minimum cooling state and the second cell
>> +                       is the maximum cooling state used in this map.
> 
> The type is wrong here -- it's a phandle + cooling-cells, not just a phandle.
> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle of     zone.
>> +   trip point node
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling state used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling state used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one sub-node
>> +containing trip nodes and one sub-node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell
>> +
>> +- polling-delay-passive: The maximum number of milliseconds to wait
>> +  Type: unsigned       between polls when performing passive cooling.
>> +  Size: one cell
>> +
>> +- thermal-sensors:     A list of thermal sensor phandles and sensor specifier
>> +  Type: list of        used while monitoring the thermal zone.
>> +  sensor phandles
> 
> The type is wrong here. A list of phandle + sensor specifiers.
> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors listed in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offset.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when passive cooling is activated (polling-delay-passive); and
>> +(ii) - when the zone just needs to be monitored (polling-delay) or
>> +when active cooling is activated.
>> +
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability. The delays should be chosen to account for said max dT/dt,
>> +such that a device does not cross several trip boundaries unexpectedly
>> +between polls. Choosing the right polling delays shall avoid having the
>> +device in temperature ranges that may damage the silicon structures and
>> +reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes". The "thermal-zones" node appears under "/".
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       /*
>> +        * Here is an example of describing a cooling device for a DVFS
>> +        * capable CPU. The CPU node describes its four OPPs.
>> +        * The cooling states possible are 0..3, and they are
>> +        * used as OPP indexes. The minimum cooling state is 0, which means
>> +        * all four OPPs can be available to the system. The maximum
>> +        * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
>> +        * can be available in the system.
>> +        */
>> +       cpu0: cpu@0 {
>> +               ...
>> +               operating-points = <
>> +                       /* kHz    uV */
>> +                       970000  1200000
>> +                       792000  1100000
>> +                       396000  950000
>> +                       198000  850000
>> +               >;
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple fan controller which supports 10 speeds of operation
>> +        * (represented as 0-9).
>> +        */
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>;
>> +
>> +               trips {
>> +                       cpu-alert0: cpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "active";
>> +                       };
>> +                       cpu-alert1: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-alert0>;
>> +                               cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device =
>> +                                   <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
>> +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
>> +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
>> +different cooling states 0-9. It is used to remove the heat out of
>> +the thermal zone 'cpu-thermal' using its cooling states
>> +from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
>> +temperature of 125C, represented by the trip point 'cpu-crit', the silicon
>> +is not reliable anymore.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with several bandgap temperature sensors.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <1>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     0>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       cpu-alert: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       gpu-thermal: gpu-thermal {
>> +               polling-delay-passive = <120>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     1>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       gpu-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-crit: gpu-crit {
>> +                               temperature = <105000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       dsp-thermal: dsp-thermal {
>> +               polling-delay-passive = <50>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     2>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       dsp-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       dsp-crit: gpu-crit {
>> +                               temperature = <135000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first cell of the sensor
>> +specifier as sensor ID. In the example, then, <bandgap 0> is used to
>> +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
>> +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
>> +may be uncorrelated, having its own dT/dt requirements, trips
>> +and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple IC with a single temperature sensor.
>> +        */
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>,  /* cpu */
>> +                                 <&adc>;       /* pcb north */
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +               coefficients =          <100    -120    484>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrates this situation.
>> +For instance, it may be the case that a sensor external to CPU IP may be placed
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. Assuming this is the case for the above example,
>> +the hypothetical extrapolation rule would be:
>> +               hotspot = 100 * bandgap - 120 * adc + 484
>> +
>> +In other context, the same idea can be used to add fixed offset. For instance,
>> +consider the hotspot extrapolation rule below:
>> +               hotspot = 1 * adc + 6000
>> +
>> +In the above equation, the hotspot is always 6C higher than what is read
>> +from the ADC sensor. The binding would be then:
>> +        thermal-sensors =  <&adc>;
>> +
>> +               /* hotspot = 1 * adc + 6000 */
>> +       coefficients =          <1      6000>;
>> +
>> +(d) - Board thermal
>> +
>> +The board thermal example below illustrates how to setup one thermal zone
>> +with many sensors and many cooling devices.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * An IC with several temperature sensor.
>> +        */
>> +       adc-dummy: sensor@0x50 {
>> +               ...
>> +               #thermal-sensor-cells = <1>; /* sensor internal ID */
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       batt-thermal {
>> +               polling-delay-passive = <500>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     4>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +
>> +       board-thermal: board-thermal {
>> +               polling-delay-passive = <1000>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
>> +                                 <&adc-dummy     1>, /* lcd */
>> +                                 <&adc-dymmy     2>; /* back cover */
>> +               /*
>> +                * An array of coefficients describing the sensor
>> +                * linear relation. E.g.:
>> +                * z = c1*x1 + c2*x2 + c3*x3
>> +                */
>> +               coefficients =          <1200   -345    890>;
>> +
>> +               trips {
>> +                       /* Trips are based on resulting linear equation */
>> +                       cpu-trip: cpu-trip {
>> +                               temperature = <60000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-trip: gpu-trip {
>> +                               temperature = <55000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       }
>> +                       lcd-trip: lcp-trip {
>> +                               temperature = <53000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       crit-trip: crit-trip {
>> +                               temperature = <68000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-trip>;
>> +                               cooling-device = <&cpu0 0 2>;
>> +                               contribution = <55>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&gpu-trip>;
>> +                               cooling-device = <&gpu0 0 2>;
>> +                               contribution = <20>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&lcd-trip>;
>> +                               cooling-device = <&lcd0 5 10>;
>> +                               contribution = <15>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +The above example is a mix of previous examples, a sensor IP with several internal
>> +sensors used to monitor different zones, one of them is composed by several sensors and
>> +with different cooling devices.
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index dbfc390..dd81eb8 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,6 +29,19 @@ config THERMAL_HWMON
>>           Say 'Y' here if you want all thermal sensors to
>>           have hwmon sysfs interface too.
>>
>> +config THERMAL_OF
>> +       bool
>> +       prompt "APIs to parse thermal data out of device tree"
>> +       depends on OF
>> +       default y
>> +       help
>> +         This options provides helpers to add the support to
>> +         read and parse thermal data definitions out of the
>> +         device tree blob.
>> +
>> +         Say 'Y' here if you need to build thermal infrastructure
>> +         based on device tree.
>> +
>>  choice
>>         prompt "Default Thermal governor"
>>         default THERMAL_DEFAULT_GOV_STEP_WISE
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 584b363..4b03956 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -7,6 +7,7 @@ thermal_sys-y                   += thermal_core.o
>>
>>  # interface to/from other layers providing sensors
>>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
>> +thermal_sys-$(CONFIG_THERMAL_OF)               += of-thermal.o
>>
>>  # governors
>>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> new file mode 100644
>> index 0000000..66f9eb2
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,849 @@
>> +/*
>> + *  of-thermal.c - Generic Thermal Management device tree support.
>> + *
>> + *  Copyright (C) 2013 Texas Instruments
>> + *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + *
>> + *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation; version 2 of the License.
>> + *
>> + *  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.
>> + *
>> + *  You should have received a copy of the GNU General Public License along
>> + *  with this program; if not, write to the Free Software Foundation, Inc.,
>> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +#include <linux/thermal.h>
>> +#include <linux/slab.h>
>> +#include <linux/types.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/string.h>
>> +
>> +#include "thermal_core.h"
>> +
>> +/***   Private data structures to represent thermal device tree data ***/
>> +
>> +/**
>> + * struct __thermal_trip - representation of a point in temperature domain
>> + * @np: pointer to struct device_node that this trip point was created from
>> + * @temperature: temperature value in miliCelsius
>> + * @hysteresis: relative hysteresis in miliCelsius
>> + * @type: trip point type
>> + */
>> +
>> +struct __thermal_trip {
>> +       struct device_node *np;
>> +       unsigned long int temperature;
>> +       unsigned long int hysteresis;
>> +       enum thermal_trip_type type;
>> +};
>> +
>> +/**
>> + * struct __thermal_bind_param - a match between trip and cooling device
>> + * @cooling_device: a pointer to identify the referred cooling device
>> + * @trip_id: the trip point index
>> + * @usage: the percentage (from 0 to 100) of cooling contribution
>> + * @min: minimum cooling state used at this trip point
>> + * @max: maximum cooling state used at this trip point
>> + */
>> +
>> +struct __thermal_bind_params {
>> +       struct device_node *cooling_device;
>> +       unsigned int trip_id;
>> +       unsigned int usage;
>> +       unsigned long min;
>> +       unsigned long max;
>> +};
>> +
>> +/**
>> + * struct __thermal_zone - internal representation of a thermal zone
>> + * @mode: current thermal zone device mode (enabled/disabled)
>> + * @passive_delay: polling interval while passive cooling is activated
>> + * @polling_delay: zone polling interval
>> + * @ntrips: number of trip points
>> + * @trips: an array of trip points (0..ntrips - 1)
>> + * @num_tbps: number of thermal bind params
>> + * @tbps: an array of thermal bind params (0..num_tbps - 1)
>> + * @sensor_data: sensor private data used while reading temperature and trend
>> + * @get_temp: sensor callback to read temperature
>> + * @get_trend: sensor callback to read temperature trend
>> + */
>> +
>> +struct __thermal_zone {
>> +       enum thermal_device_mode mode;
>> +       int passive_delay;
>> +       int polling_delay;
>> +
>> +       /* trip data */
>> +       int ntrips;
>> +       struct __thermal_trip *trips;
>> +
>> +       /* cooling binding data */
>> +       int num_tbps;
>> +       struct __thermal_bind_params *tbps;
>> +
>> +       /* sensor interface */
>> +       void *sensor_data;
>> +       int (*get_temp)(void *, long *);
>> +       int (*get_trend)(void *, long *);
>> +};
>> +
>> +/***   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;
>> +
>> +       if (!data->get_temp)
>> +               return -EINVAL;
>> +
>> +       return data->get_temp(data->sensor_data, temp);
>> +}
>> +
>> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
>> +                               enum thermal_trend *trend)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       long dev_trend;
>> +       int r;
>> +
>> +       if (!data->get_trend)
>> +               return -EINVAL;
>> +
>> +       r = data->get_trend(data->sensor_data, &dev_trend);
>> +       if (r)
>> +               return r;
>> +
>> +       /* TODO: These intervals might have some thresholds, but in core code */
>> +       if (dev_trend > 0)
>> +               *trend = THERMAL_TREND_RAISING;
>> +       else if (dev_trend < 0)
>> +               *trend = THERMAL_TREND_DROPPING;
>> +       else
>> +               *trend = THERMAL_TREND_STABLE;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_bind(struct thermal_zone_device *thermal,
>> +                          struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to bind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_bind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev,
>> +                                               tbp->min,
>> +                                               tbp->max);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_unbind(struct thermal_zone_device *thermal,
>> +                            struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to unbind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_unbind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode *mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       *mode = data->mode;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       mutex_lock(&tz->lock);
>> +
>> +       if (mode == THERMAL_DEVICE_ENABLED)
>> +               tz->polling_delay = data->polling_delay;
>> +       else
>> +               tz->polling_delay = 0;
>> +
>> +       mutex_unlock(&tz->lock);
>> +
>> +       data->mode = mode;
>> +       thermal_zone_device_update(tz);
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *type = data->trips[trip].type;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *temp = data->trips[trip].temperature;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *hyst = data->trips[trip].hysteresis;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].hysteresis = hyst;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       int i;
>> +
>> +       for (i = 0; i < data->ntrips; i++)
>> +               if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
>> +                       *temp = data->trips[i].temperature;
>> +                       return 0;
>> +               }
>> +
>> +       return -EINVAL;
>> +}
>> +
>> +static struct thermal_zone_device_ops of_thermal_ops = {
>> +       .get_mode = of_thermal_get_mode,
>> +       .set_mode = of_thermal_set_mode,
>> +
>> +       .get_trip_type = of_thermal_get_trip_type,
>> +       .get_trip_temp = of_thermal_get_trip_temp,
>> +       .set_trip_temp = of_thermal_set_trip_temp,
>> +       .get_trip_hyst = of_thermal_get_trip_hyst,
>> +       .set_trip_hyst = of_thermal_set_trip_hyst,
>> +       .get_crit_temp = of_thermal_get_crit_temp,
>> +
>> +       .bind = of_thermal_bind,
>> +       .unbind = of_thermal_unbind,
>> +};
>> +
>> +/***   sensor API   ***/
>> +
>> +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 *))
>> +{
>> +       struct thermal_zone_device *tzd;
>> +       struct __thermal_zone *tz;
>> +
>> +       tzd = thermal_zone_get_zone_by_name(zone->name);
>> +       if (IS_ERR(tzd))
>> +               return ERR_PTR(-EPROBE_DEFER);
>> +
>> +       tz = tzd->devdata;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tz->get_temp = get_temp;
>> +       tz->get_trend = get_trend;
>> +       tz->sensor_data = data;
>> +
>> +       tzd->ops->get_temp = of_thermal_get_temp;
>> +       tzd->ops->get_trend = of_thermal_get_trend;
>> +       mutex_unlock(&tzd->lock);
>> +
>> +       return tzd;
>> +}
>> +
>> +/**
>> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @sensor_id: a sensor identifier, in case the sensor IP has more
>> + *             than one sensors
>> + * @data: a private pointer (owned by the caller) that will be passed
>> + *        back, when a temperature reading is needed.
>> + * @get_temp: a pointer to a function that reads the sensor temperature.
>> + * @get_trend: a pointer to a function that reads the sensor temperature trend.
>> + *
>> + * This function will search the list of thermal zones described in device
>> + * tree and look for the zone that refer to the sensor device pointed by
>> + * @dev->of_node as temperature providers. For the zone pointing to the
>> + * sensor node, the sensor will be added to the DT thermal zone device.
>> + *
>> + * The thermal zone temperature is provided by the @get_temp function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * The thermal zone temperature trend is provided by the @get_trend function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * TODO:
>> + * 01 - This function must enqueue the new sensor instead of using
>> + * it as the only source of temperature values.
>> + *
>> + * 02 - There must be a way to match the sensor with all thermal zones
>> + * that refer to it.
>> + *
>> + * Return: On success returns a valid struct thermal_zone_device,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count >= 1) {
>> +                       id = sensor_specs.args[0];
>> +                       WARN(sensor_specs.args_count > 1,
>> +                            "%s: too many cells in sensor specifier %d\n",
>> +                            sensor_specs.np->name, sensor_specs.args_count);
>> +               } else {
>> +                       id = 0;
>> +               }
>> +
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
>> +
>> +/**
>> + * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
>> + *
>> + * This function removes the sensor callbacks and private data from the
>> + * thermal zone device registered with thermal_zone_of_sensor_register()
>> + * API. It will also silent the zone by remove the .get_temp() and .get_trend()
>> + * thermal zone device callbacks.
>> + *
>> + * TODO: When the support to several sensors per zone is added, this
>> + * function must search the sensor list based on @dev parameter.
>> + *
>> + */
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tzd)
>> +{
>> +       struct __thermal_zone *tz;
>> +
>> +       if (!dev || !tzd || !tzd->devdata)
>> +               return;
>> +
>> +       tz = tzd->devdata;
>> +
>> +       /* no __thermal_zone, nothing to be done */
>> +       if (!tz)
>> +               return;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tzd->ops->get_temp = NULL;
>> +       tzd->ops->get_trend = NULL;
>> +
>> +       tz->get_temp = NULL;
>> +       tz->get_trend = NULL;
>> +       tz->sensor_data = NULL;
>> +       mutex_unlock(&tzd->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
>> +
>> +/***   functions parsing device tree nodes   ***/
>> +
>> +/**
>> + * thermal_of_populate_bind_params - parse and fill cooling map data
>> + * @np: DT node containing a cooling-map node
>> + * @__tbp: data structure to be filled with cooling map info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-map type of node represented by
>> + * @np parameter and fills the read data into @__tbp data structure.
>> + * It needs the already parsed array of trip points of the thermal zone
>> + * in consideration.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_bind_params(struct device_node *np,
>> +                                          struct __thermal_bind_params *__tbp,
>> +                                          struct __thermal_trip *trips,
>> +                                          int ntrips)
>> +{
>> +       struct of_phandle_args cooling_spec;
>> +       struct device_node *trip;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       /* Default weight. Usage is optional */
>> +       __tbp->usage = 0;
>> +       ret = of_property_read_u32(np, "contribution", &prop);
>> +       if (ret == 0)
>> +               __tbp->usage = prop;
>> +
>> +       trip = of_parse_phandle(np, "trip", 0);
>> +       if (!trip) {
>> +               pr_err("missing trip property\n");
>> +               return -ENODEV;
>> +       }
>> +
>> +       /* match using device_node */
>> +       for (i = 0; i < ntrips; i++)
>> +               if (trip == trips[i].np) {
>> +                       __tbp->trip_id = i;
>> +                       break;
>> +               }
>> +
>> +       if (i == ntrips) {
>> +               ret = -ENODEV;
>> +               goto end;
>> +       }
>> +
>> +       ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
>> +                                        0, &cooling_spec);
>> +       if (ret < 0) {
>> +               pr_err("missing cooling_device property\n");
>> +               goto end;
>> +       }
>> +       __tbp->cooling_device = cooling_spec.np;
>> +       if (cooling_spec.args_count >= 2) { /* at least min and max */
>> +               __tbp->min = cooling_spec.args[0];
>> +               __tbp->max = cooling_spec.args[1];
>> +       } else {
>> +               pr_err("wrong reference to cooling device, missing limits\n");
>> +       }
>> +
>> +end:
>> +       of_node_put(trip);
>> +
>> +       return ret;
>> +}
>> +
>> +/**
>> + * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
>> + * into the device tree binding of 'trip', property type.
>> + */
>> +static const char * const trip_types[] = {
>> +       [THERMAL_TRIP_ACTIVE]   = "active",
>> +       [THERMAL_TRIP_PASSIVE]  = "passive",
>> +       [THERMAL_TRIP_HOT]      = "hot",
>> +       [THERMAL_TRIP_CRITICAL] = "critical",
>> +};
>> +
>> +/**
>> + * thermal_of_get_trip_type - Get phy mode for given device_node
>> + * @np:        Pointer to the given device_node
>> + * @type: Pointer to resulting trip type
>> + *
>> + * The function gets trip type string from property 'type',
>> + * and store its index in trip_types table in @type,
>> + *
>> + * Return: 0 on success, or errno in error case.
>> + */
>> +static int thermal_of_get_trip_type(struct device_node *np,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       const char *t;
>> +       int err, i;
>> +
>> +       err = of_property_read_string(np, "type", &t);
>> +       if (err < 0)
>> +               return err;
>> +
>> +       for (i = 0; i < ARRAY_SIZE(trip_types); i++)
>> +               if (!strcasecmp(t, trip_types[i])) {
>> +                       *type = i;
>> +                       return 0;
>> +               }
>> +
>> +       return -ENODEV;
>> +}
>> +
>> +/**
>> + * thermal_of_populate_trip - parse and fill one trip point data
>> + * @np: DT node containing a trip point node
>> + * @trip: trip point data structure to be filled up
>> + *
>> + * This function parses a trip point type of node represented by
>> + * @np parameter and fills the read data into @trip data structure.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_trip(struct device_node *np,
>> +                                   struct __thermal_trip *trip)
>> +{
>> +       int prop;
>> +       int ret;
>> +
>> +       ret = of_property_read_u32(np, "temperature", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing temperature property\n");
>> +               return ret;
>> +       }
>> +       trip->temperature = prop;
>> +
>> +       ret = of_property_read_u32(np, "hysteresis", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing hysteresis property\n");
>> +               return ret;
>> +       }
>> +       trip->hysteresis = prop;
>> +
>> +       ret = thermal_of_get_trip_type(np, &trip->type);
>> +       if (ret < 0) {
>> +               pr_err("wrong trip type property\n");
>> +               return ret;
>> +       }
>> +
>> +       /* Required for cooling map matching */
>> +       trip->np = np;
>> +
>> +       return 0;
>> +}
>> +
>> +/**
>> + * thermal_of_build_thermal_zone - parse and fill one thermal zone data
>> + * @np: DT node containing a thermal zone node
>> + *
>> + * This function parses a thermal zone type of node represented by
>> + * @np parameter and fills the read data into a __thermal_zone data structure
>> + * and return this pointer.
>> + *
>> + * TODO: Missing properties to parse: thermal-sensor-names and coefficients
>> + *
>> + * Return: On success returns a valid struct __thermal_zone,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +       struct device_node *child = NULL, *gchild;
>> +       struct __thermal_zone *tz;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       if (!np) {
>> +               pr_err("no thermal zone np\n");
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>> +       if (!tz)
>> +               return ERR_PTR(-ENOMEM);
>> +
>> +       ret = of_property_read_u32(np, "polling-delay-passive", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay-passive property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->passive_delay = prop;
>> +
>> +       ret = of_property_read_u32(np, "polling-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->polling_delay = prop;
>> +
>> +       /* trips */
>> +       child = of_get_child_by_name(np, "trips");
>> +
>> +       /* No trips provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->ntrips = of_get_child_count(child);
>> +       if (tz->ntrips == 0) /* must have at least one child */
>> +               goto finish;
>> +
>> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +       if (!tz->trips) {
>> +               ret = -ENOMEM;
>> +               goto free_tz;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild) {
>> +               ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +               if (ret)
>> +                       goto free_trips;
>> +       }
>> +
>> +       of_node_put(child);
>> +
>> +       /* cooling-maps */
>> +       child = of_get_child_by_name(np, "cooling-maps");
>> +
>> +       /* cooling-maps not provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->num_tbps = of_get_child_count(child);
>> +       if (tz->num_tbps == 0)
>> +               goto finish;
>> +
>> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +       if (!tz->tbps) {
>> +               ret = -ENOMEM;
>> +               goto free_trips;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +                                                     tz->trips, tz->ntrips);
>> +               if (ret)
>> +                       goto free_tbps;
>> +
>> +finish:
>> +       of_node_put(child);
>> +       tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +       return tz;
>> +
>> +free_tbps:
>> +       kfree(tz->tbps);
>> +free_trips:
>> +       kfree(tz->trips);
>> +free_tz:
>> +       kfree(tz);
>> +       of_node_put(child);
>> +
>> +       return ERR_PTR(ret);
>> +}
>> +
>> +static inline void of_thermal_free_zone(struct __thermal_zone *tz)
>> +{
>> +       kfree(tz->tbps);
>> +       kfree(tz->trips);
>> +       kfree(tz);
>> +}
>> +
>> +/**
>> + * of_parse_thermal_zones - parse device tree thermal data
>> + *
>> + * Initialization function that can be called by machine initialization
>> + * code to parse thermal data and populate the thermal framework
>> + * with hardware thermal zones info. This function only parses thermal zones.
>> + * Cooling devices and sensor devices nodes are supposed to be parsed
>> + * by their respective drivers.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + *
>> + */
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +       struct __thermal_zone *tz;
>> +       struct thermal_zone_device_ops *ops;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_debug("unable to find thermal zones\n");
>> +               return 0; /* Run successfully on systems without thermal DT */
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +               struct thermal_zone_params *tzp;
>> +
>> +               tz = thermal_of_build_thermal_zone(child);
>> +               if (IS_ERR(tz)) {
>> +                       pr_err("failed to build thermal zone %s: %ld\n",
>> +                              child->name,
>> +                              PTR_ERR(tz));
>> +                       continue;
>> +               }
>> +
>> +               ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
>> +               if (!ops)
>> +                       goto exit_free;
>> +
>> +               tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +               if (!tzp) {
>> +                       kfree(ops);
>> +                       goto exit_free;
>> +               }
>> +
>> +               /* No hwmon because there might be hwmon drivers registering */
>> +               tzp->no_hwmon = true;
>> +
>> +               zone = thermal_zone_device_register(child->name, tz->ntrips,
>> +                                                   0, tz,
>> +                                                   ops, tzp,
>> +                                                   tz->passive_delay,
>> +                                                   tz->polling_delay);
>> +               if (IS_ERR(zone)) {
>> +                       pr_err("Failed to build %s zone %ld\n", child->name,
>> +                              PTR_ERR(zone));
>> +                       kfree(tzp);
>> +                       kfree(ops);
>> +                       of_thermal_free_zone(tz);
>> +                       /* attempting to build remaining zones still */
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +exit_free:
>> +       of_thermal_free_zone(tz);
>> +
>> +       /* no memory available, so free what we have built */
>> +       of_thermal_destroy_zones();
>> +
>> +       return -ENOMEM;
>> +}
>> +
>> +/**
>> + * of_thermal_destroy_zones - remove all zones parsed and allocated resources
>> + *
>> + * Finds all zones parsed and added to the thermal framework and remove them
>> + * from the system, together with their resources.
>> + *
>> + */
>> +void __exit of_thermal_destroy_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_err("unable to find thermal zones\n");
>> +               return;
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +
>> +               zone = thermal_zone_get_zone_by_name(child->name);
>> +               if (IS_ERR(zone))
>> +                       continue;
>> +
>> +               thermal_zone_device_unregister(zone);
>> +               kfree(zone->tzp);
>> +               kfree(zone->ops);
>> +               of_thermal_free_zone(zone->devdata);
>> +       }
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index f7a9f4f..fec3351 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
>>   */
>>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
>>         int trips, int mask, void *devdata,
>> -       const struct thermal_zone_device_ops *ops,
>> +       struct thermal_zone_device_ops *ops,
>>         const struct thermal_zone_params *tzp,
>>         int passive_delay, int polling_delay)
>>  {
>> @@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
>>         if (result)
>>                 goto unregister_class;
>>
>> +       result = of_parse_thermal_zones();
>> +       if (result)
>> +               goto exit_netlink;
>> +
>>         return 0;
>>
>> +exit_netlink:
>> +       genetlink_exit();
>>  unregister_governors:
>>         thermal_unregister_governors();
>>  unregister_class:
>> @@ -1768,6 +1774,7 @@ error:
>>
>>  static void __exit thermal_exit(void)
>>  {
>> +       of_thermal_destroy_zones();
>>         genetlink_exit();
>>         class_unregister(&thermal_class);
>>         thermal_unregister_governors();
>> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
>> index 7cf2f66..3db339f 100644
>> --- a/drivers/thermal/thermal_core.h
>> +++ b/drivers/thermal/thermal_core.h
>> @@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
>>  static inline void thermal_gov_user_space_unregister(void) {}
>>  #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
>>
>> +/* device tree support */
>> +#ifdef CONFIG_THERMAL_OF
>> +int of_parse_thermal_zones(void);
>> +void of_thermal_destroy_zones(void);
>> +#else
>> +static inline int of_parse_thermal_zones(void) { return 0; }
>> +static inline void of_thermal_destroy_zones(void) { }
>> +#endif
>> +
>>  #endif /* __THERMAL_CORE_H__ */
>> diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
>> new file mode 100644
>> index 0000000..59c4581
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/thermal.h
>> @@ -0,0 +1,27 @@
>> +/*
>> + * This header provides constants for most thermal bindings.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *     Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + * GPLv2 only
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
>> +#define _DT_BINDINGS_THERMAL_THERMAL_H
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE            "active"
>> +#define THERMAL_TRIP_PASSIVE           "passive"
>> +#define THERMAL_TRIP_HOT               "hot"
>> +#define THERMAL_TRIP_CRITICAL          "critical"
> 
> I don't like this. If someone wants to include this in a C file they can't do so
> at the same time as include/linux/thermal.h. The defined names are longer than
> the actual string values, and the comment makes it sound like these could be
> modified rather than being a fixed ABI.
> 
> I do not see the point of these constants.
> 
> Thanks,
> Mark.
> 
>> +
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT               (-1UL)
>> +
>> +#endif
>> +
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index b268d3c..b780c5b 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -143,6 +143,7 @@ struct thermal_cooling_device {
>>         int id;
>>         char type[THERMAL_NAME_LENGTH];
>>         struct device device;
>> +       struct device_node *np;
>>         void *devdata;
>>         const struct thermal_cooling_device_ops *ops;
>>         bool updated; /* true if the cooling device does not need update */
>> @@ -172,7 +173,7 @@ struct thermal_zone_device {
>>         int emul_temperature;
>>         int passive;
>>         unsigned int forced_passive;
>> -       const struct thermal_zone_device_ops *ops;
>> +       struct thermal_zone_device_ops *ops;
>>         const struct thermal_zone_params *tzp;
>>         struct thermal_governor *governor;
>>         struct list_head thermal_instances;
>> @@ -242,8 +243,31 @@ struct thermal_genl_event {
>>  };
>>
>>  /* Function declarations */
>> +#ifdef CONFIG_THERMAL_OF
>> +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 *));
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz);
>> +#else
>> +static inline 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 *))
>> +{
>> +       return NULL;
>> +}
>> +
>> +static inline
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz)
>> +{
>> +}
>> +
>> +#endif
>>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
>> -               void *, const struct thermal_zone_device_ops *,
>> +               void *, struct thermal_zone_device_ops *,
>>                 const struct thermal_zone_params *, int, int);
>>  void thermal_zone_device_unregister(struct thermal_zone_device *);
>>
>> --
>> 1.8.2.1.342.gfa7285d
>>
>>
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv8 03/18] thermal: introduce device tree parser
@ 2013-11-05 18:08         ` Eduardo Valentin
  0 siblings, 0 replies; 101+ messages in thread
From: Eduardo Valentin @ 2013-11-05 18:08 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Eduardo Valentin, swarren, Pawel Moll, ian.campbell, rob.herring,
	grant.likely, linux, rui.zhang, wni, durgadoss.r, linux-pm,
	devicetree, lm-sensors, linux-kernel


[-- Attachment #1.1: Type: text/plain, Size: 69857 bytes --]

Hello device tree maintainers,

On 07-10-2013 16:51, Mark Rutland wrote:
> Hi all,
> 
> Given that this is a complex new class of binding, I'd appreciate if at least
> one other device tree maintainer could also take a look over this and voice any
> concerns or suggestions. I've left the entire patch context for this.

Here is just a gentle reminder. Looks like no one else has had the time
to provide us a third opinion on this work. Shall we continue
progressing here? Its been about four weeks the series is waiting on
extra feedback.

I was on paternity leave :-) So, getting back to get this one rolling.

> 
> Apologies for the munged whitespace -- my mail server appears to have helpfully
> and irreparably replaced all tabs with spaces.
> 
> On Tue, Oct 01, 2013 at 03:39:26AM +0100, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
>>
>> This patch introduces a thermal data parser for device
>> tree. The parsed data is used to build thermal zones
>> and thermal binding parameters. The output data
>> can then be used to deploy thermal policies.
>>
>> This patch adds also documentation regarding this
>> API and how to define tree nodes to use
>> this infrastructure.
>>
>> Note that, in order to be able to have control
>> on the sensor registration on the DT thermal zone,
>> it was required to allow changing the thermal zone
>> .get_temp callback. For this reason, this patch
>> also removes the 'const' modifier from the .ops
>> field of thermal zone devices.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: linux-pm@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>> Hello Mark, folks,
>>
>> So, here is v8. Pretty small changes. Most are better
>> English phrasing in the binding document. It follows changelog:
>> - Several rephrasing in the binding document, including
>> spelling, grammar and better phrasing.
>> - Removed WiP warning from binding document.
>> - Several spacing and formatting changes in the binding document
>> - Used the '-specifier' nomenclature properly in the binding doc
>> - Removed the optional property 'thermal-sensors-names', because
>> it does not provide useful runtime information
>> - Fixed description of 'polling-delay-passive'
>> - Improved examples by adding comments and better explanation
>> - s/fw/framework/g
>> - Added a WARN when sensors specifiers are greater and 1.
>>
>> All best,
>>
>> Eduardo
>>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 587 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 849 +++++++++++++++++++++
>>  drivers/thermal/thermal_core.c                     |   9 +-
>>  drivers/thermal/thermal_core.h                     |   9 +
>>  include/dt-bindings/thermal/thermal.h              |  27 +
>>  include/linux/thermal.h                            |  28 +-
>>  8 files changed, 1520 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
>>  create mode 100644 drivers/thermal/of-thermal.c
>>  create mode 100644 include/dt-bindings/thermal/thermal.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..ad06a8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,587 @@
>> +* Thermal Framework Device Tree descriptor
>> +
>> +This file describes a generic binding to provide a way of
>> +defining hardware thermal structure using device tree.
> 
> s/defining/describing/
> 
>> +A thermal structure includes thermal zones and their components,
>> +such as trip points, polling intervals, sensors and cooling devices
>> +binding descriptors.
>> +
>> +The target of device tree thermal descriptors is to describe only
>> +the hardware thermal aspects. The thermal device tree bindings are
>> +not about how the system must control or which algorithm or policy
>> +must be taken in place.
> 
> I'm not quite sure what this is saying -- it seems to contradict the
> design of the binding where trip points get linked to cooling device
> configuration, and thus we're defining a policy along the lines of "when
> sensor $W hits temperature $X, configure cooling device $Y with value
> $Z". I don't see how that can't be considered policy.
> 
> At best, we can say that policy is being defined because describing the
> physical properties of a device and dealing with this at runtime is not
> feasible.
> 
>> +
>> +There are five types of nodes involved to describe thermal bindings:
>> +- sensors: used to describe the device source of temperature sensing;
> 
> - thermal sensors: devices which may be used to take temperature
>   measurements.
> 
>> +- cooling devices: used to describe devices source of power dissipation control;
> 
> - cooling devices: devices which may be used to dissipate heat.
> 
>> +- trip points: used to describe points in temperature domain defined to
>> +make the system aware of hardware limits;
> 
> - trip points: describe key temperatures at which cooling is recommended. The
>   set of points should be chosen based on hardware limits.
> 
>> +- cooling maps: used to describe links between trip points and cooling devices;
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
> 
> How about:
> 
> The following is a description of each of these node types.
> 
>> +
>> +* Thermal sensor devices
>> +
>> +Thermal sensor devices are nodes providing temperature sensing capabilities on
>> +thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
>> +nodes providing temperature data to thermal zones. Thermal sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #thermal-sensor-cells: Used to provide sensor device specific information
>> +  Type: unsigned        while referring to it. Typically 0 on thermal sensor
>> +  Size: one cell        nodes with only one sensor, and at least 1 on nodes
>> +                        with several internal sensors, in order
>> +                        to identify uniquely the sensor instances within
>> +                        the IC. See thermal zone binding for more details
>> +                        on how consumers refer to sensor devices.
>> +
>> +* Cooling device nodes
>> +
>> +Cooling devices are nodes providing control on power dissipation. There
>> +are essentially two ways to provide control on power dissipation. First
>> +is by means of regulating device performance, which is known as passive
>> +cooling. A typical passive cooling is a CPU that has dynamic voltage and
>> +frequency scaling (DVFS), and uses lower frequencies as cooling states.
>> +Second is by means of activating devices in order to remove
>> +the dissipated heat, which is known as active cooling, e.g. regulating
>> +fan speeds. In both cases, cooling devices shall have a way to determine
>> +the state of cooling in which the device is.
> 
> I'd probably say "heat dissipation" rather than "power dissipation", unless
> this is a technical term I am not aware of?
> 
> Why is the determination of the state of the cooling device important?
> 
>> +
>> +Required properties:
>> +- cooling-min-state:   An integer indicating the smallest
>> +  Type: unsigned       cooling state accepted. Typically 0.
>> +  Size: one cell
>> +
>> +- cooling-max-state:   An integer indicating the largest
>> +  Type: unsigned       cooling state accepted.
>> +  Size: one cell
>> +
>> +- #cooling-cells:      Used to provide cooling device specific information
>> +  Type: unsigned       while referring to it. Must be at least 2, in order
>> +  Size: one cell       to specify minimum and maximum cooling state used
>> +                       in the reference. The first cell is the minimum
>> +                       cooling state requested and the second cell is
>> +                       the maximum cooling state requested in the reference.
>> +                       See Cooling device maps section below for more details
>> +                       on how consumers refer to cooling devices.
> 
> Is it assumed that all the values between min and max are valid, or might this
> be a sparse set of cooling values?
> 
>> +
>> +* Trip points
>> +
>> +The trip node is a node to describe a point in the temperature domain
>> +in which the system takes an action. This node describes just the point,
>> +not the action.
>> +
>> +Required properties:
>> +- temperature:         An integer indicating the trip temperature level,
>> +  Type: signed         in millicelsius.
>> +  Size: one cell
>> +
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +  Type: unsigned       relative value, in millicelsius.
>> +  Size: one cell
> 
> What is it relative to?
> 
> Why is 'temperature' in quotes?
> 
>> +
>> +- type:                        a string containing the trip type. Supported values are:
>> +       "active":       A trip point to enable active cooling
>> +       "passive":      A trip point to enable passive cooling
>> +       "hot":          A trip point to notify emergency
>> +       "critical":     Hardware not reliable.
>> +  Type: string
>> +
>> +There are also string constants defined at
>> +include/dt-bindings/thermal/thermal.h.
> 
> Why?
> 
>> +
>> +* Cooling device maps
>> +
>> +The cooling device maps node is a node to describe how cooling devices
>> +get assigned to trip points of the zone. The cooling devices are expected
>> +to be loaded in the target system.
>> +
>> +Required properties:
>> +- cooling-device:      A phandle of a cooling device with its specifier,
>> +  Type: phandle of     referring to which cooling device is used in this
>> +    cooling device     binding. In the cooling specifier, the first cell
>> +                       is the minimum cooling state and the second cell
>> +                       is the maximum cooling state used in this map.
> 
> The type is wrong here -- it's a phandle + cooling-cells, not just a phandle.
> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +  Type: phandle of     zone.
>> +   trip point node
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +  Type: unsigned       referred cooling device at the referred trip point.
>> +  Size: one cell       The contribution is a ratio of the sum
>> +                       of all cooling contributions within a thermal zone.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
>> +limit specifier means:
>> +(i)   - minimum state allowed for minimum cooling state used in the reference.
>> +(ii)  - maximum state allowed for maximum cooling state used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zone nodes
>> +
>> +The thermal zone node is the node containing all the required info
>> +for describing a thermal zone, including its cooling device bindings. The
>> +thermal zone node must contain, apart from its own properties, one sub-node
>> +containing trip nodes and one sub-node containing all the zone cooling maps.
>> +
>> +Required properties:
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +  Type: unsigned       when checking this thermal zone.
>> +  Size: one cell
>> +
>> +- polling-delay-passive: The maximum number of milliseconds to wait
>> +  Type: unsigned       between polls when performing passive cooling.
>> +  Size: one cell
>> +
>> +- thermal-sensors:     A list of thermal sensor phandles and sensor specifier
>> +  Type: list of        used while monitoring the thermal zone.
>> +  sensor phandles
> 
> The type is wrong here. A list of phandle + sensor specifiers.
> 
>> +
>> +- trips:               A sub-node which is a container of only trip point nodes
>> +  Type: sub-node       required to describe the thermal zone.
>> +
>> +- cooling-maps:                A sub-node which is a container of only cooling device
>> +  Type: sub-node       map nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +  Type: array          coefficients to compose a linear relation between
>> +  Elem size: one cell  the sensors listed in the thermal-sensors property.
>> +  Elem type: signed    Coefficients defaults to 1, in case this property
>> +                       is not specified. A simple linear polynomial is used:
>> +                       Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +
>> +                       The coefficients are ordered and they match with sensors
>> +                       by means of sensor ID. Additional coefficients are
>> +                       interpreted as constant offset.
>> +
>> +Note: The delay properties are bound to the maximum dT/dt (temperature
>> +derivative over time) in two situations for a thermal zone:
>> +(i)  - when passive cooling is activated (polling-delay-passive); and
>> +(ii) - when the zone just needs to be monitored (polling-delay) or
>> +when active cooling is activated.
>> +
>> +The maximum dT/dt is highly bound to hardware power consumption and dissipation
>> +capability. The delays should be chosen to account for said max dT/dt,
>> +such that a device does not cross several trip boundaries unexpectedly
>> +between polls. Choosing the right polling delays shall avoid having the
>> +device in temperature ranges that may damage the silicon structures and
>> +reduce silicon lifetime.
>> +
>> +* The thermal-zones node
>> +
>> +The "thermal-zones" node is a container for all thermal zone nodes. It shall
>> +contain only sub-nodes describing thermal zones as in the section
>> +"Thermal zone nodes". The "thermal-zones" node appears under "/".
>> +
>> +* Examples
>> +
>> +Below are several examples on how to use thermal data descriptors
>> +using device tree bindings:
>> +
>> +(a) - CPU thermal zone
>> +
>> +The CPU thermal zone example below describes how to setup one thermal zone
>> +using one single sensor as temperature source and many cooling devices and
>> +power dissipation control sources.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +cpus {
>> +       /*
>> +        * Here is an example of describing a cooling device for a DVFS
>> +        * capable CPU. The CPU node describes its four OPPs.
>> +        * The cooling states possible are 0..3, and they are
>> +        * used as OPP indexes. The minimum cooling state is 0, which means
>> +        * all four OPPs can be available to the system. The maximum
>> +        * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
>> +        * can be available in the system.
>> +        */
>> +       cpu0: cpu@0 {
>> +               ...
>> +               operating-points = <
>> +                       /* kHz    uV */
>> +                       970000  1200000
>> +                       792000  1100000
>> +                       396000  950000
>> +                       198000  850000
>> +               >;
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple fan controller which supports 10 speeds of operation
>> +        * (represented as 0-9).
>> +        */
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-state = <0>;
>> +               cooling-max-state = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>;
>> +
>> +               trips {
>> +                       cpu-alert0: cpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "active";
>> +                       };
>> +                       cpu-alert1: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-alert0>;
>> +                               cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&cpu-alert1>;
>> +                               cooling-device =
>> +                                   <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
>> +used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
>> +device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
>> +different cooling states 0-9. It is used to remove the heat out of
>> +the thermal zone 'cpu-thermal' using its cooling states
>> +from its minimum to 4, when it reaches trip point 'cpu-alert0'
>> +at 90C, as an example of active cooling. The same cooling device is used at
>> +'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
>> +linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
>> +using all its cooling states at trip point 'cpu-alert1',
>> +which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
>> +temperature of 125C, represented by the trip point 'cpu-crit', the silicon
>> +is not reliable anymore.
>> +
>> +(b) - IC with several internal sensors
>> +
>> +The example below describes how to deploy several thermal zones based off a
>> +single sensor IC, assuming it has several internal sensors. This is a common
>> +case on SoC designs with several internal IPs that may need different thermal
>> +requirements, and thus may have their own sensor to monitor or detect internal
>> +hotspots in their silicon.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with several bandgap temperature sensors.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <1>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     0>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       cpu-alert: cpu-alert {
>> +                               temperature = <100000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       cpu-crit: cpu-crit {
>> +                               temperature = <125000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       gpu-thermal: gpu-thermal {
>> +               polling-delay-passive = <120>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     1>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       gpu-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-crit: gpu-crit {
>> +                               temperature = <105000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +
>> +       dsp-thermal: dsp-thermal {
>> +               polling-delay-passive = <50>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&bandgap0     2>;
>> +
>> +               trips {
>> +                       /* each zone within the SoC may have its own trips */
>> +                       dsp-alert: gpu-alert {
>> +                               temperature = <90000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       dsp-crit: gpu-crit {
>> +                               temperature = <135000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       /* each zone within the SoC may have its own cooling */
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In the example above, there is one bandgap IC which has the capability to
>> +monitor three sensors. The hardware has been designed so that sensors are
>> +placed on different places in the DIE to monitor different temperature
>> +hotspots: one for CPU thermal zone, one for GPU thermal zone and the
>> +other to monitor a DSP thermal zone.
>> +
>> +Thus, there is a need to assign each sensor provided by the bandgap IC
>> +to different thermal zones. This is achieved by means of using the
>> +#thermal-sensor-cells property and using the first cell of the sensor
>> +specifier as sensor ID. In the example, then, <bandgap 0> is used to
>> +monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
>> +zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
>> +may be uncorrelated, having its own dT/dt requirements, trips
>> +and cooling maps.
>> +
>> +
>> +(c) - Several sensors within one single thermal zone
>> +
>> +The example below illustrates how to use more than one sensor within
>> +one thermal zone.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * A simple IC with a single temperature sensor.
>> +        */
>> +       adc: sensor@0x49 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +ocp {
>> +       ...
>> +       /*
>> +        * A simple IC with a single bandgap temperature sensor.
>> +        */
>> +       bandgap0: bandgap@0x0000ED00 {
>> +               ...
>> +               #thermal-sensor-cells = <0>;
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       cpu-thermal: cpu-thermal {
>> +               polling-delay-passive = <250>; /* milliseconds */
>> +               polling-delay = <1000>; /* milliseconds */
>> +
>> +               thermal-sensors = <&bandgap0>,  /* cpu */
>> +                                 <&adc>;       /* pcb north */
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +               coefficients =          <100    -120    484>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +};
>> +
>> +In some cases, there is a need to use more than one sensor to extrapolate
>> +a thermal hotspot in the silicon. The above example illustrates this situation.
>> +For instance, it may be the case that a sensor external to CPU IP may be placed
>> +close to CPU hotspot and together with internal CPU sensor, it is used
>> +to determine the hotspot. Assuming this is the case for the above example,
>> +the hypothetical extrapolation rule would be:
>> +               hotspot = 100 * bandgap - 120 * adc + 484
>> +
>> +In other context, the same idea can be used to add fixed offset. For instance,
>> +consider the hotspot extrapolation rule below:
>> +               hotspot = 1 * adc + 6000
>> +
>> +In the above equation, the hotspot is always 6C higher than what is read
>> +from the ADC sensor. The binding would be then:
>> +        thermal-sensors =  <&adc>;
>> +
>> +               /* hotspot = 1 * adc + 6000 */
>> +       coefficients =          <1      6000>;
>> +
>> +(d) - Board thermal
>> +
>> +The board thermal example below illustrates how to setup one thermal zone
>> +with many sensors and many cooling devices.
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +&i2c1 {
>> +       ...
>> +       /*
>> +        * An IC with several temperature sensor.
>> +        */
>> +       adc-dummy: sensor@0x50 {
>> +               ...
>> +               #thermal-sensor-cells = <1>; /* sensor internal ID */
>> +       };
>> +};
>> +
>> +thermal-zones {
>> +       batt-thermal {
>> +               polling-delay-passive = <500>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     4>;
>> +
>> +               trips {
>> +                       ...
>> +               };
>> +
>> +               cooling-maps {
>> +                       ...
>> +               };
>> +       };
>> +
>> +       board-thermal: board-thermal {
>> +               polling-delay-passive = <1000>; /* milliseconds */
>> +               polling-delay = <2500>; /* milliseconds */
>> +
>> +                               /* sensor       ID */
>> +               thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
>> +                                 <&adc-dummy     1>, /* lcd */
>> +                                 <&adc-dymmy     2>; /* back cover */
>> +               /*
>> +                * An array of coefficients describing the sensor
>> +                * linear relation. E.g.:
>> +                * z = c1*x1 + c2*x2 + c3*x3
>> +                */
>> +               coefficients =          <1200   -345    890>;
>> +
>> +               trips {
>> +                       /* Trips are based on resulting linear equation */
>> +                       cpu-trip: cpu-trip {
>> +                               temperature = <60000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       gpu-trip: gpu-trip {
>> +                               temperature = <55000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       }
>> +                       lcd-trip: lcp-trip {
>> +                               temperature = <53000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "passive";
>> +                       };
>> +                       crit-trip: crit-trip {
>> +                               temperature = <68000>; /* millicelsius */
>> +                               hysteresis = <2000>; /* millicelsius */
>> +                               type = "critical";
>> +                       };
>> +               };
>> +
>> +               cooling-maps {
>> +                       map0 {
>> +                               trip = <&cpu-trip>;
>> +                               cooling-device = <&cpu0 0 2>;
>> +                               contribution = <55>;
>> +                       };
>> +                       map1 {
>> +                               trip = <&gpu-trip>;
>> +                               cooling-device = <&gpu0 0 2>;
>> +                               contribution = <20>;
>> +                       };
>> +                       map2 {
>> +                               trip = <&lcd-trip>;
>> +                               cooling-device = <&lcd0 5 10>;
>> +                               contribution = <15>;
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +The above example is a mix of previous examples, a sensor IP with several internal
>> +sensors used to monitor different zones, one of them is composed by several sensors and
>> +with different cooling devices.
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index dbfc390..dd81eb8 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,6 +29,19 @@ config THERMAL_HWMON
>>           Say 'Y' here if you want all thermal sensors to
>>           have hwmon sysfs interface too.
>>
>> +config THERMAL_OF
>> +       bool
>> +       prompt "APIs to parse thermal data out of device tree"
>> +       depends on OF
>> +       default y
>> +       help
>> +         This options provides helpers to add the support to
>> +         read and parse thermal data definitions out of the
>> +         device tree blob.
>> +
>> +         Say 'Y' here if you need to build thermal infrastructure
>> +         based on device tree.
>> +
>>  choice
>>         prompt "Default Thermal governor"
>>         default THERMAL_DEFAULT_GOV_STEP_WISE
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 584b363..4b03956 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -7,6 +7,7 @@ thermal_sys-y                   += thermal_core.o
>>
>>  # interface to/from other layers providing sensors
>>  thermal_sys-$(CONFIG_THERMAL_HWMON)            += thermal_hwmon.o
>> +thermal_sys-$(CONFIG_THERMAL_OF)               += of-thermal.o
>>
>>  # governors
>>  thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> new file mode 100644
>> index 0000000..66f9eb2
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,849 @@
>> +/*
>> + *  of-thermal.c - Generic Thermal Management device tree support.
>> + *
>> + *  Copyright (C) 2013 Texas Instruments
>> + *  Copyright (C) 2013 Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + *
>> + *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + *
>> + *  This program is free software; you can redistribute it and/or modify
>> + *  it under the terms of the GNU General Public License as published by
>> + *  the Free Software Foundation; version 2 of the License.
>> + *
>> + *  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.
>> + *
>> + *  You should have received a copy of the GNU General Public License along
>> + *  with this program; if not, write to the Free Software Foundation, Inc.,
>> + *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> + */
>> +#include <linux/thermal.h>
>> +#include <linux/slab.h>
>> +#include <linux/types.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/string.h>
>> +
>> +#include "thermal_core.h"
>> +
>> +/***   Private data structures to represent thermal device tree data ***/
>> +
>> +/**
>> + * struct __thermal_trip - representation of a point in temperature domain
>> + * @np: pointer to struct device_node that this trip point was created from
>> + * @temperature: temperature value in miliCelsius
>> + * @hysteresis: relative hysteresis in miliCelsius
>> + * @type: trip point type
>> + */
>> +
>> +struct __thermal_trip {
>> +       struct device_node *np;
>> +       unsigned long int temperature;
>> +       unsigned long int hysteresis;
>> +       enum thermal_trip_type type;
>> +};
>> +
>> +/**
>> + * struct __thermal_bind_param - a match between trip and cooling device
>> + * @cooling_device: a pointer to identify the referred cooling device
>> + * @trip_id: the trip point index
>> + * @usage: the percentage (from 0 to 100) of cooling contribution
>> + * @min: minimum cooling state used at this trip point
>> + * @max: maximum cooling state used at this trip point
>> + */
>> +
>> +struct __thermal_bind_params {
>> +       struct device_node *cooling_device;
>> +       unsigned int trip_id;
>> +       unsigned int usage;
>> +       unsigned long min;
>> +       unsigned long max;
>> +};
>> +
>> +/**
>> + * struct __thermal_zone - internal representation of a thermal zone
>> + * @mode: current thermal zone device mode (enabled/disabled)
>> + * @passive_delay: polling interval while passive cooling is activated
>> + * @polling_delay: zone polling interval
>> + * @ntrips: number of trip points
>> + * @trips: an array of trip points (0..ntrips - 1)
>> + * @num_tbps: number of thermal bind params
>> + * @tbps: an array of thermal bind params (0..num_tbps - 1)
>> + * @sensor_data: sensor private data used while reading temperature and trend
>> + * @get_temp: sensor callback to read temperature
>> + * @get_trend: sensor callback to read temperature trend
>> + */
>> +
>> +struct __thermal_zone {
>> +       enum thermal_device_mode mode;
>> +       int passive_delay;
>> +       int polling_delay;
>> +
>> +       /* trip data */
>> +       int ntrips;
>> +       struct __thermal_trip *trips;
>> +
>> +       /* cooling binding data */
>> +       int num_tbps;
>> +       struct __thermal_bind_params *tbps;
>> +
>> +       /* sensor interface */
>> +       void *sensor_data;
>> +       int (*get_temp)(void *, long *);
>> +       int (*get_trend)(void *, long *);
>> +};
>> +
>> +/***   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;
>> +
>> +       if (!data->get_temp)
>> +               return -EINVAL;
>> +
>> +       return data->get_temp(data->sensor_data, temp);
>> +}
>> +
>> +static int of_thermal_get_trend(struct thermal_zone_device *tz, int trip,
>> +                               enum thermal_trend *trend)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       long dev_trend;
>> +       int r;
>> +
>> +       if (!data->get_trend)
>> +               return -EINVAL;
>> +
>> +       r = data->get_trend(data->sensor_data, &dev_trend);
>> +       if (r)
>> +               return r;
>> +
>> +       /* TODO: These intervals might have some thresholds, but in core code */
>> +       if (dev_trend > 0)
>> +               *trend = THERMAL_TREND_RAISING;
>> +       else if (dev_trend < 0)
>> +               *trend = THERMAL_TREND_DROPPING;
>> +       else
>> +               *trend = THERMAL_TREND_STABLE;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_bind(struct thermal_zone_device *thermal,
>> +                          struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to bind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_bind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev,
>> +                                               tbp->min,
>> +                                               tbp->max);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_unbind(struct thermal_zone_device *thermal,
>> +                            struct thermal_cooling_device *cdev)
>> +{
>> +       struct __thermal_zone *data = thermal->devdata;
>> +       int i;
>> +
>> +       if (!data || IS_ERR(data))
>> +               return -ENODEV;
>> +
>> +       /* find where to unbind */
>> +       for (i = 0; i < data->num_tbps; i++) {
>> +               struct __thermal_bind_params *tbp = data->tbps + i;
>> +
>> +               if (tbp->cooling_device == cdev->np) {
>> +                       int ret;
>> +
>> +                       ret = thermal_zone_unbind_cooling_device(thermal,
>> +                                               tbp->trip_id, cdev);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode *mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       *mode = data->mode;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_mode(struct thermal_zone_device *tz,
>> +                              enum thermal_device_mode mode)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       mutex_lock(&tz->lock);
>> +
>> +       if (mode == THERMAL_DEVICE_ENABLED)
>> +               tz->polling_delay = data->polling_delay;
>> +       else
>> +               tz->polling_delay = 0;
>> +
>> +       mutex_unlock(&tz->lock);
>> +
>> +       data->mode = mode;
>> +       thermal_zone_device_update(tz);
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_type(struct thermal_zone_device *tz, int trip,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *type = data->trips[trip].type;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *temp = data->trips[trip].temperature;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].temperature = temp;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long *hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       *hyst = data->trips[trip].hysteresis;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
>> +                                   unsigned long hyst)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +
>> +       if (trip >= data->ntrips || trip < 0)
>> +               return -EDOM;
>> +
>> +       /* thermal framework should take care of data->mask & (1 << trip) */
>> +       data->trips[trip].hysteresis = hyst;
>> +
>> +       return 0;
>> +}
>> +
>> +static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
>> +                                   unsigned long *temp)
>> +{
>> +       struct __thermal_zone *data = tz->devdata;
>> +       int i;
>> +
>> +       for (i = 0; i < data->ntrips; i++)
>> +               if (data->trips[i].type == THERMAL_TRIP_CRITICAL) {
>> +                       *temp = data->trips[i].temperature;
>> +                       return 0;
>> +               }
>> +
>> +       return -EINVAL;
>> +}
>> +
>> +static struct thermal_zone_device_ops of_thermal_ops = {
>> +       .get_mode = of_thermal_get_mode,
>> +       .set_mode = of_thermal_set_mode,
>> +
>> +       .get_trip_type = of_thermal_get_trip_type,
>> +       .get_trip_temp = of_thermal_get_trip_temp,
>> +       .set_trip_temp = of_thermal_set_trip_temp,
>> +       .get_trip_hyst = of_thermal_get_trip_hyst,
>> +       .set_trip_hyst = of_thermal_set_trip_hyst,
>> +       .get_crit_temp = of_thermal_get_crit_temp,
>> +
>> +       .bind = of_thermal_bind,
>> +       .unbind = of_thermal_unbind,
>> +};
>> +
>> +/***   sensor API   ***/
>> +
>> +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 *))
>> +{
>> +       struct thermal_zone_device *tzd;
>> +       struct __thermal_zone *tz;
>> +
>> +       tzd = thermal_zone_get_zone_by_name(zone->name);
>> +       if (IS_ERR(tzd))
>> +               return ERR_PTR(-EPROBE_DEFER);
>> +
>> +       tz = tzd->devdata;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tz->get_temp = get_temp;
>> +       tz->get_trend = get_trend;
>> +       tz->sensor_data = data;
>> +
>> +       tzd->ops->get_temp = of_thermal_get_temp;
>> +       tzd->ops->get_trend = of_thermal_get_trend;
>> +       mutex_unlock(&tzd->lock);
>> +
>> +       return tzd;
>> +}
>> +
>> +/**
>> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @sensor_id: a sensor identifier, in case the sensor IP has more
>> + *             than one sensors
>> + * @data: a private pointer (owned by the caller) that will be passed
>> + *        back, when a temperature reading is needed.
>> + * @get_temp: a pointer to a function that reads the sensor temperature.
>> + * @get_trend: a pointer to a function that reads the sensor temperature trend.
>> + *
>> + * This function will search the list of thermal zones described in device
>> + * tree and look for the zone that refer to the sensor device pointed by
>> + * @dev->of_node as temperature providers. For the zone pointing to the
>> + * sensor node, the sensor will be added to the DT thermal zone device.
>> + *
>> + * The thermal zone temperature is provided by the @get_temp function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * The thermal zone temperature trend is provided by the @get_trend function
>> + * pointer. When called, it will have the private pointer @data back.
>> + *
>> + * TODO:
>> + * 01 - This function must enqueue the new sensor instead of using
>> + * it as the only source of temperature values.
>> + *
>> + * 02 - There must be a way to match the sensor with all thermal zones
>> + * that refer to it.
>> + *
>> + * Return: On success returns a valid struct thermal_zone_device,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +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 *))
>> +{
>> +       struct device_node *np, *child, *sensor_np;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       sensor_np = dev->of_node;
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct of_phandle_args sensor_specs;
>> +               int ret, id;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "thermal-sensors",
>> +                                                "#thermal-sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count >= 1) {
>> +                       id = sensor_specs.args[0];
>> +                       WARN(sensor_specs.args_count > 1,
>> +                            "%s: too many cells in sensor specifier %d\n",
>> +                            sensor_specs.np->name, sensor_specs.args_count);
>> +               } else {
>> +                       id = 0;
>> +               }
>> +
>> +               if (sensor_specs.np == sensor_np && id == sensor_id) {
>> +                       of_node_put(np);
>> +                       return thermal_zone_of_add_sensor(child, sensor_np,
>> +                                                         data,
>> +                                                         get_temp,
>> +                                                         get_trend);
>> +               }
>> +       }
>> +       of_node_put(np);
>> +
>> +       return ERR_PTR(-ENODEV);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
>> +
>> +/**
>> + * thermal_zone_of_sensor_unregister - unregisters a sensor from a DT thermal zone
>> + * @dev: a valid struct device pointer of a sensor device. Must contain
>> + *       a valid .of_node, for the sensor node.
>> + * @tzd: a pointer to struct thermal_zone_device where the sensor is registered.
>> + *
>> + * This function removes the sensor callbacks and private data from the
>> + * thermal zone device registered with thermal_zone_of_sensor_register()
>> + * API. It will also silent the zone by remove the .get_temp() and .get_trend()
>> + * thermal zone device callbacks.
>> + *
>> + * TODO: When the support to several sensors per zone is added, this
>> + * function must search the sensor list based on @dev parameter.
>> + *
>> + */
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tzd)
>> +{
>> +       struct __thermal_zone *tz;
>> +
>> +       if (!dev || !tzd || !tzd->devdata)
>> +               return;
>> +
>> +       tz = tzd->devdata;
>> +
>> +       /* no __thermal_zone, nothing to be done */
>> +       if (!tz)
>> +               return;
>> +
>> +       mutex_lock(&tzd->lock);
>> +       tzd->ops->get_temp = NULL;
>> +       tzd->ops->get_trend = NULL;
>> +
>> +       tz->get_temp = NULL;
>> +       tz->get_trend = NULL;
>> +       tz->sensor_data = NULL;
>> +       mutex_unlock(&tzd->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_unregister);
>> +
>> +/***   functions parsing device tree nodes   ***/
>> +
>> +/**
>> + * thermal_of_populate_bind_params - parse and fill cooling map data
>> + * @np: DT node containing a cooling-map node
>> + * @__tbp: data structure to be filled with cooling map info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-map type of node represented by
>> + * @np parameter and fills the read data into @__tbp data structure.
>> + * It needs the already parsed array of trip points of the thermal zone
>> + * in consideration.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_bind_params(struct device_node *np,
>> +                                          struct __thermal_bind_params *__tbp,
>> +                                          struct __thermal_trip *trips,
>> +                                          int ntrips)
>> +{
>> +       struct of_phandle_args cooling_spec;
>> +       struct device_node *trip;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       /* Default weight. Usage is optional */
>> +       __tbp->usage = 0;
>> +       ret = of_property_read_u32(np, "contribution", &prop);
>> +       if (ret == 0)
>> +               __tbp->usage = prop;
>> +
>> +       trip = of_parse_phandle(np, "trip", 0);
>> +       if (!trip) {
>> +               pr_err("missing trip property\n");
>> +               return -ENODEV;
>> +       }
>> +
>> +       /* match using device_node */
>> +       for (i = 0; i < ntrips; i++)
>> +               if (trip == trips[i].np) {
>> +                       __tbp->trip_id = i;
>> +                       break;
>> +               }
>> +
>> +       if (i == ntrips) {
>> +               ret = -ENODEV;
>> +               goto end;
>> +       }
>> +
>> +       ret = of_parse_phandle_with_args(np, "cooling-device", "#cooling-cells",
>> +                                        0, &cooling_spec);
>> +       if (ret < 0) {
>> +               pr_err("missing cooling_device property\n");
>> +               goto end;
>> +       }
>> +       __tbp->cooling_device = cooling_spec.np;
>> +       if (cooling_spec.args_count >= 2) { /* at least min and max */
>> +               __tbp->min = cooling_spec.args[0];
>> +               __tbp->max = cooling_spec.args[1];
>> +       } else {
>> +               pr_err("wrong reference to cooling device, missing limits\n");
>> +       }
>> +
>> +end:
>> +       of_node_put(trip);
>> +
>> +       return ret;
>> +}
>> +
>> +/**
>> + * It maps 'enum thermal_trip_type' found in include/linux/thermal.h
>> + * into the device tree binding of 'trip', property type.
>> + */
>> +static const char * const trip_types[] = {
>> +       [THERMAL_TRIP_ACTIVE]   = "active",
>> +       [THERMAL_TRIP_PASSIVE]  = "passive",
>> +       [THERMAL_TRIP_HOT]      = "hot",
>> +       [THERMAL_TRIP_CRITICAL] = "critical",
>> +};
>> +
>> +/**
>> + * thermal_of_get_trip_type - Get phy mode for given device_node
>> + * @np:        Pointer to the given device_node
>> + * @type: Pointer to resulting trip type
>> + *
>> + * The function gets trip type string from property 'type',
>> + * and store its index in trip_types table in @type,
>> + *
>> + * Return: 0 on success, or errno in error case.
>> + */
>> +static int thermal_of_get_trip_type(struct device_node *np,
>> +                                   enum thermal_trip_type *type)
>> +{
>> +       const char *t;
>> +       int err, i;
>> +
>> +       err = of_property_read_string(np, "type", &t);
>> +       if (err < 0)
>> +               return err;
>> +
>> +       for (i = 0; i < ARRAY_SIZE(trip_types); i++)
>> +               if (!strcasecmp(t, trip_types[i])) {
>> +                       *type = i;
>> +                       return 0;
>> +               }
>> +
>> +       return -ENODEV;
>> +}
>> +
>> +/**
>> + * thermal_of_populate_trip - parse and fill one trip point data
>> + * @np: DT node containing a trip point node
>> + * @trip: trip point data structure to be filled up
>> + *
>> + * This function parses a trip point type of node represented by
>> + * @np parameter and fills the read data into @trip data structure.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + */
>> +static int thermal_of_populate_trip(struct device_node *np,
>> +                                   struct __thermal_trip *trip)
>> +{
>> +       int prop;
>> +       int ret;
>> +
>> +       ret = of_property_read_u32(np, "temperature", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing temperature property\n");
>> +               return ret;
>> +       }
>> +       trip->temperature = prop;
>> +
>> +       ret = of_property_read_u32(np, "hysteresis", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing hysteresis property\n");
>> +               return ret;
>> +       }
>> +       trip->hysteresis = prop;
>> +
>> +       ret = thermal_of_get_trip_type(np, &trip->type);
>> +       if (ret < 0) {
>> +               pr_err("wrong trip type property\n");
>> +               return ret;
>> +       }
>> +
>> +       /* Required for cooling map matching */
>> +       trip->np = np;
>> +
>> +       return 0;
>> +}
>> +
>> +/**
>> + * thermal_of_build_thermal_zone - parse and fill one thermal zone data
>> + * @np: DT node containing a thermal zone node
>> + *
>> + * This function parses a thermal zone type of node represented by
>> + * @np parameter and fills the read data into a __thermal_zone data structure
>> + * and return this pointer.
>> + *
>> + * TODO: Missing properties to parse: thermal-sensor-names and coefficients
>> + *
>> + * Return: On success returns a valid struct __thermal_zone,
>> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
>> + * check the return value with help of IS_ERR() helper.
>> + */
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +       struct device_node *child = NULL, *gchild;
>> +       struct __thermal_zone *tz;
>> +       int ret, i;
>> +       u32 prop;
>> +
>> +       if (!np) {
>> +               pr_err("no thermal zone np\n");
>> +               return ERR_PTR(-EINVAL);
>> +       }
>> +
>> +       tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>> +       if (!tz)
>> +               return ERR_PTR(-ENOMEM);
>> +
>> +       ret = of_property_read_u32(np, "polling-delay-passive", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay-passive property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->passive_delay = prop;
>> +
>> +       ret = of_property_read_u32(np, "polling-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling-delay property\n");
>> +               goto free_tz;
>> +       }
>> +       tz->polling_delay = prop;
>> +
>> +       /* trips */
>> +       child = of_get_child_by_name(np, "trips");
>> +
>> +       /* No trips provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->ntrips = of_get_child_count(child);
>> +       if (tz->ntrips == 0) /* must have at least one child */
>> +               goto finish;
>> +
>> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +       if (!tz->trips) {
>> +               ret = -ENOMEM;
>> +               goto free_tz;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild) {
>> +               ret = thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +               if (ret)
>> +                       goto free_trips;
>> +       }
>> +
>> +       of_node_put(child);
>> +
>> +       /* cooling-maps */
>> +       child = of_get_child_by_name(np, "cooling-maps");
>> +
>> +       /* cooling-maps not provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->num_tbps = of_get_child_count(child);
>> +       if (tz->num_tbps == 0)
>> +               goto finish;
>> +
>> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +       if (!tz->tbps) {
>> +               ret = -ENOMEM;
>> +               goto free_trips;
>> +       }
>> +
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               ret = thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +                                                     tz->trips, tz->ntrips);
>> +               if (ret)
>> +                       goto free_tbps;
>> +
>> +finish:
>> +       of_node_put(child);
>> +       tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +       return tz;
>> +
>> +free_tbps:
>> +       kfree(tz->tbps);
>> +free_trips:
>> +       kfree(tz->trips);
>> +free_tz:
>> +       kfree(tz);
>> +       of_node_put(child);
>> +
>> +       return ERR_PTR(ret);
>> +}
>> +
>> +static inline void of_thermal_free_zone(struct __thermal_zone *tz)
>> +{
>> +       kfree(tz->tbps);
>> +       kfree(tz->trips);
>> +       kfree(tz);
>> +}
>> +
>> +/**
>> + * of_parse_thermal_zones - parse device tree thermal data
>> + *
>> + * Initialization function that can be called by machine initialization
>> + * code to parse thermal data and populate the thermal framework
>> + * with hardware thermal zones info. This function only parses thermal zones.
>> + * Cooling devices and sensor devices nodes are supposed to be parsed
>> + * by their respective drivers.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + *
>> + */
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +       struct __thermal_zone *tz;
>> +       struct thermal_zone_device_ops *ops;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_debug("unable to find thermal zones\n");
>> +               return 0; /* Run successfully on systems without thermal DT */
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +               struct thermal_zone_params *tzp;
>> +
>> +               tz = thermal_of_build_thermal_zone(child);
>> +               if (IS_ERR(tz)) {
>> +                       pr_err("failed to build thermal zone %s: %ld\n",
>> +                              child->name,
>> +                              PTR_ERR(tz));
>> +                       continue;
>> +               }
>> +
>> +               ops = kmemdup(&of_thermal_ops, sizeof(*ops), GFP_KERNEL);
>> +               if (!ops)
>> +                       goto exit_free;
>> +
>> +               tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +               if (!tzp) {
>> +                       kfree(ops);
>> +                       goto exit_free;
>> +               }
>> +
>> +               /* No hwmon because there might be hwmon drivers registering */
>> +               tzp->no_hwmon = true;
>> +
>> +               zone = thermal_zone_device_register(child->name, tz->ntrips,
>> +                                                   0, tz,
>> +                                                   ops, tzp,
>> +                                                   tz->passive_delay,
>> +                                                   tz->polling_delay);
>> +               if (IS_ERR(zone)) {
>> +                       pr_err("Failed to build %s zone %ld\n", child->name,
>> +                              PTR_ERR(zone));
>> +                       kfree(tzp);
>> +                       kfree(ops);
>> +                       of_thermal_free_zone(tz);
>> +                       /* attempting to build remaining zones still */
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +exit_free:
>> +       of_thermal_free_zone(tz);
>> +
>> +       /* no memory available, so free what we have built */
>> +       of_thermal_destroy_zones();
>> +
>> +       return -ENOMEM;
>> +}
>> +
>> +/**
>> + * of_thermal_destroy_zones - remove all zones parsed and allocated resources
>> + *
>> + * Finds all zones parsed and added to the thermal framework and remove them
>> + * from the system, together with their resources.
>> + *
>> + */
>> +void __exit of_thermal_destroy_zones(void)
>> +{
>> +       struct device_node *np, *child;
>> +
>> +       np = of_find_node_by_name(NULL, "thermal-zones");
>> +       if (!np) {
>> +               pr_err("unable to find thermal zones\n");
>> +               return;
>> +       }
>> +
>> +       for_each_child_of_node(np, child) {
>> +               struct thermal_zone_device *zone;
>> +
>> +               zone = thermal_zone_get_zone_by_name(child->name);
>> +               if (IS_ERR(zone))
>> +                       continue;
>> +
>> +               thermal_zone_device_unregister(zone);
>> +               kfree(zone->tzp);
>> +               kfree(zone->ops);
>> +               of_thermal_free_zone(zone->devdata);
>> +       }
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index f7a9f4f..fec3351 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -1371,7 +1371,7 @@ static void remove_trip_attrs(struct thermal_zone_device *tz)
>>   */
>>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
>>         int trips, int mask, void *devdata,
>> -       const struct thermal_zone_device_ops *ops,
>> +       struct thermal_zone_device_ops *ops,
>>         const struct thermal_zone_params *tzp,
>>         int passive_delay, int polling_delay)
>>  {
>> @@ -1751,8 +1751,14 @@ static int __init thermal_init(void)
>>         if (result)
>>                 goto unregister_class;
>>
>> +       result = of_parse_thermal_zones();
>> +       if (result)
>> +               goto exit_netlink;
>> +
>>         return 0;
>>
>> +exit_netlink:
>> +       genetlink_exit();
>>  unregister_governors:
>>         thermal_unregister_governors();
>>  unregister_class:
>> @@ -1768,6 +1774,7 @@ error:
>>
>>  static void __exit thermal_exit(void)
>>  {
>> +       of_thermal_destroy_zones();
>>         genetlink_exit();
>>         class_unregister(&thermal_class);
>>         thermal_unregister_governors();
>> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
>> index 7cf2f66..3db339f 100644
>> --- a/drivers/thermal/thermal_core.h
>> +++ b/drivers/thermal/thermal_core.h
>> @@ -77,4 +77,13 @@ static inline int thermal_gov_user_space_register(void) { return 0; }
>>  static inline void thermal_gov_user_space_unregister(void) {}
>>  #endif /* CONFIG_THERMAL_GOV_USER_SPACE */
>>
>> +/* device tree support */
>> +#ifdef CONFIG_THERMAL_OF
>> +int of_parse_thermal_zones(void);
>> +void of_thermal_destroy_zones(void);
>> +#else
>> +static inline int of_parse_thermal_zones(void) { return 0; }
>> +static inline void of_thermal_destroy_zones(void) { }
>> +#endif
>> +
>>  #endif /* __THERMAL_CORE_H__ */
>> diff --git a/include/dt-bindings/thermal/thermal.h b/include/dt-bindings/thermal/thermal.h
>> new file mode 100644
>> index 0000000..59c4581
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/thermal.h
>> @@ -0,0 +1,27 @@
>> +/*
>> + * This header provides constants for most thermal bindings.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *     Eduardo Valentin <eduardo.valentin@ti.com>
>> + *
>> + * GPLv2 only
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_THERMAL_H
>> +#define _DT_BINDINGS_THERMAL_THERMAL_H
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE            "active"
>> +#define THERMAL_TRIP_PASSIVE           "passive"
>> +#define THERMAL_TRIP_HOT               "hot"
>> +#define THERMAL_TRIP_CRITICAL          "critical"
> 
> I don't like this. If someone wants to include this in a C file they can't do so
> at the same time as include/linux/thermal.h. The defined names are longer than
> the actual string values, and the comment makes it sound like these could be
> modified rather than being a fixed ABI.
> 
> I do not see the point of these constants.
> 
> Thanks,
> Mark.
> 
>> +
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT               (-1UL)
>> +
>> +#endif
>> +
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index b268d3c..b780c5b 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -143,6 +143,7 @@ struct thermal_cooling_device {
>>         int id;
>>         char type[THERMAL_NAME_LENGTH];
>>         struct device device;
>> +       struct device_node *np;
>>         void *devdata;
>>         const struct thermal_cooling_device_ops *ops;
>>         bool updated; /* true if the cooling device does not need update */
>> @@ -172,7 +173,7 @@ struct thermal_zone_device {
>>         int emul_temperature;
>>         int passive;
>>         unsigned int forced_passive;
>> -       const struct thermal_zone_device_ops *ops;
>> +       struct thermal_zone_device_ops *ops;
>>         const struct thermal_zone_params *tzp;
>>         struct thermal_governor *governor;
>>         struct list_head thermal_instances;
>> @@ -242,8 +243,31 @@ struct thermal_genl_event {
>>  };
>>
>>  /* Function declarations */
>> +#ifdef CONFIG_THERMAL_OF
>> +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 *));
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz);
>> +#else
>> +static inline 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 *))
>> +{
>> +       return NULL;
>> +}
>> +
>> +static inline
>> +void thermal_zone_of_sensor_unregister(struct device *dev,
>> +                                      struct thermal_zone_device *tz)
>> +{
>> +}
>> +
>> +#endif
>>  struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
>> -               void *, const struct thermal_zone_device_ops *,
>> +               void *, struct thermal_zone_device_ops *,
>>                 const struct thermal_zone_params *, int, int);
>>  void thermal_zone_device_unregister(struct thermal_zone_device *);
>>
>> --
>> 1.8.2.1.342.gfa7285d
>>
>>
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCHv4 02/18] thermal: core: allow binding via .bind when tzp is present
  2013-09-27  3:13   ` Eduardo Valentin
@ 2013-11-06  2:56     ` Wei Ni
  -1 siblings, 0 replies; 101+ messages in thread
From: Wei Ni @ 2013-11-06  2:56 UTC (permalink / raw)
  To: Eduardo Valentin, swarren, pawel.moll, mark.rutland,
	ian.campbell, rob.herring, linux, rui.zhang
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel

On 09/27/2013 11:13 AM, Eduardo Valentin wrote:
> This patch allows drivers register thermal zone devices
> with thermal zone params and .bind callbacks. In this case,
> it will use the .bind callback.
> 
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  drivers/thermal/thermal_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 8a94300..f7a9f4f 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -247,7 +247,7 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
>  		if (!pos->tzp && !pos->ops->bind)
>  			continue;
>  
> -		if (!pos->tzp && pos->ops->bind) {
> +		if (pos->ops->bind) {

Hi, Eduardo
In bind_tz() routine, it also has same problem.
I had sent out similar patch "[PATCHv4 02/18] thermal: core: allow
binding via .bind when tzp is present" to fix it, but no response yet.
I think you can add my changes in your series :)

Thanks.
Wei.

>  			ret = pos->ops->bind(pos, cdev);
>  			if (ret)
>  				print_bind_err_msg(pos, cdev, ret);
> 


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [lm-sensors] [PATCHv4 02/18] thermal: core: allow binding via .bind when tzp is present
@ 2013-11-06  2:56     ` Wei Ni
  0 siblings, 0 replies; 101+ messages in thread
From: Wei Ni @ 2013-11-06  2:56 UTC (permalink / raw)
  To: Eduardo Valentin, swarren, pawel.moll, mark.rutland,
	ian.campbell, rob.herring, linux, rui.zhang
  Cc: grant.likely, durgadoss.r, linux-pm, devicetree, lm-sensors,
	linux-kernel

On 09/27/2013 11:13 AM, Eduardo Valentin wrote:
> This patch allows drivers register thermal zone devices
> with thermal zone params and .bind callbacks. In this case,
> it will use the .bind callback.
> 
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  drivers/thermal/thermal_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 8a94300..f7a9f4f 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -247,7 +247,7 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
>  		if (!pos->tzp && !pos->ops->bind)
>  			continue;
>  
> -		if (!pos->tzp && pos->ops->bind) {
> +		if (pos->ops->bind) {

Hi, Eduardo
In bind_tz() routine, it also has same problem.
I had sent out similar patch "[PATCHv4 02/18] thermal: core: allow
binding via .bind when tzp is present" to fix it, but no response yet.
I think you can add my changes in your series :)

Thanks.
Wei.

>  			ret = pos->ops->bind(pos, cdev);
>  			if (ret)
>  				print_bind_err_msg(pos, cdev, ret);
> 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

^ permalink raw reply	[flat|nested] 101+ messages in thread

end of thread, other threads:[~2013-11-06  2:57 UTC | newest]

Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-27  3:13 [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4) Eduardo Valentin
2013-09-27  3:13 ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13 ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 01/18] thermal: allow registering without .get_temp Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 02/18] thermal: core: allow binding via .bind when tzp is present Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-11-06  2:56   ` Wei Ni
2013-11-06  2:56     ` [lm-sensors] " Wei Ni
2013-09-27  3:13 ` [PATCHv7 03/18] thermal: introduce device tree parser Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-30 15:36   ` Mark Rutland
2013-09-30 15:36     ` [lm-sensors] " Mark Rutland
2013-09-30 20:47     ` Eduardo Valentin
2013-09-30 20:47       ` [lm-sensors] " Eduardo Valentin
2013-09-30 20:47       ` Eduardo Valentin
2013-10-01  2:39   ` [PATCHv8 " Eduardo Valentin
2013-10-01  2:39     ` [lm-sensors] " Eduardo Valentin
2013-10-01  2:39     ` Eduardo Valentin
2013-10-07 20:51     ` Mark Rutland
2013-10-07 20:51       ` [lm-sensors] " Mark Rutland
2013-10-08 14:59       ` Eduardo Valentin
2013-10-08 14:59         ` [lm-sensors] " Eduardo Valentin
2013-10-08 14:59         ` Eduardo Valentin
2013-11-05 18:08       ` Eduardo Valentin
2013-11-05 18:08         ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 04/18] thermal: core: introduce thermal_of_cooling_device_register Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 05/18] thermal: cpu_cooling: introduce of_cpufreq_cooling_register Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 06/18] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] [PATCHv4 06/18] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device propertie Eduardo Valentin
2013-09-27  3:13   ` [PATCHv4 06/18] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 07/18] hwmon: lm75: expose to thermal fw via DT nodes Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 08/18] hwmon: tmp102: " Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 09/18] thermal: ti-soc-thermal: use thermal DT infrastructure Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 10/18] arm: dts: add omap4 CPU thermal data Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 11/18] arm: dts: add omap4430 " Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27 12:24   ` Nishanth Menon
2013-09-27 12:24     ` [lm-sensors] " Nishanth Menon
2013-09-27 12:24     ` Nishanth Menon
2013-09-27 12:24     ` Nishanth Menon
2013-09-27 13:20     ` Eduardo Valentin
2013-09-27 13:20       ` [lm-sensors] " Eduardo Valentin
2013-09-27 13:20       ` Eduardo Valentin
2013-09-27 13:20       ` Eduardo Valentin
2013-09-27 13:26       ` Nishanth Menon
2013-09-27 13:26         ` [lm-sensors] " Nishanth Menon
2013-09-27 13:26         ` Nishanth Menon
2013-09-27 13:42         ` Eduardo Valentin
2013-09-27 13:42           ` [lm-sensors] " Eduardo Valentin
2013-09-27 13:42           ` Eduardo Valentin
2013-09-27 13:42           ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 12/18] arm: dts: add omap4460 " Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 13/18] arm: dts: add cooling properties on omap4430 cpu node Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 14/18] arm: dts: add cooling properties on omap4460 " Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 15/18] arm: dts: add omap5 GPU thermal data Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 16/18] arm: dts: add omap5 CORE " Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 17/18] arm: dts: add omap5 " Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13 ` [PATCHv4 18/18] arm: dts: add cooling properties on omap5 cpu node Eduardo Valentin
2013-09-27  3:13   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:13   ` Eduardo Valentin
2013-09-27  3:15 ` [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4) Eduardo Valentin
2013-09-27  3:15   ` [lm-sensors] " Eduardo Valentin
2013-09-27  3:15   ` Eduardo Valentin

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.