[PATCH 00/16] device thermal limits represented in device tree nodes (v3)

[PATCH 00/16] device thermal limits represented in device tree nodes (v3)

[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 third version
of this work. Previous versions were sent as RFCs and can be found here:
RFCv2: http://lkml.org/lkml/2013/8/23/594
RFCv1: http://lkml.org/lkml/2013/7/22/319

The major change between RFCv2 and this version is the fact that I am now
designing the binding accordingly to the common practice of creating links
from consumers to producers, as seen in regulators for instance. The change
make a thermal zone node point to used cooling devices and used sensor devices.
As direct need, cooling devices then need to be properly represented.
I am proposing to have cooling properties inside existing nodes, e.g. fan nodes,
cpu nodes. The change also required me to modify the existing thermal core
code to allow decoupling thermal zones from sensor code. Currently, the
binding proposal covers for the situation in which one thermal zone has
several sensor devices. Although this situation is not covered by the
current thermal framework code, and thus not supported by this series.
I believe this is not a stopper for this series, it can be done
in later patch sets.

The second patch includes a detailed documentation with examples
and the proposed code. In this patch series, a part from the dt parser,
there are changes in the cpufreq code to load the cpu cooling device,
also changes in the following sensor drivers: tmp102, lm75 and ti-soc-thermal.
Several changes in TI's SoC DT bindings are also included, as source
of tested examples.

The present patch series was tested on OMAP4430, OMAP4460, OMAP5430 and DRA7,
although the DRA7 changes were not sent as the core device tree support is
currently in the process to find its way to upstream.

All best,

Eduardo Valentin (16):
  drivers: thermal: allow registering without .get_temp
  drivers: thermal: introduce device tree parser
  drivers: 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        | 498 ++++++++++++++
 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                               |  46 +-
 drivers/hwmon/tmp102.c                             |  28 +
 drivers/thermal/Kconfig                            |  14 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/cpu_cooling.c                      |  31 +
 drivers/thermal/of-thermal.c                       | 763 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |  19 +-
 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                            |  28 +-
 22 files changed, 1701 insertions(+), 32 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

[PATCH 00/16] device thermal limits represented in device tree nodes (v3)

[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 third version
of this work. Previous versions were sent as RFCs and can be found here:
RFCv2: http://lkml.org/lkml/2013/8/23/594
RFCv1: http://lkml.org/lkml/2013/7/22/319

The major change between RFCv2 and this version is the fact that I am now
designing the binding accordingly to the common practice of creating links
from consumers to producers, as seen in regulators for instance. The change
make a thermal zone node point to used cooling devices and used sensor devices.
As direct need, cooling devices then need to be properly represented.
I am proposing to have cooling properties inside existing nodes, e.g. fan nodes,
cpu nodes. The change also required me to modify the existing thermal core
code to allow decoupling thermal zones from sensor code. Currently, the
binding proposal covers for the situation in which one thermal zone has
several sensor devices. Although this situation is not covered by the
current thermal framework code, and thus not supported by this series.
I believe this is not a stopper for this series, it can be done
in later patch sets.

The second patch includes a detailed documentation with examples
and the proposed code. In this patch series, a part from the dt parser,
there are changes in the cpufreq code to load the cpu cooling device,
also changes in the following sensor drivers: tmp102, lm75 and ti-soc-thermal.
Several changes in TI's SoC DT bindings are also included, as source
of tested examples.

The present patch series was tested on OMAP4430, OMAP4460, OMAP5430 and DRA7,
although the DRA7 changes were not sent as the core device tree support is
currently in the process to find its way to upstream.

All best,

Eduardo Valentin (16):
  drivers: thermal: allow registering without .get_temp
  drivers: thermal: introduce device tree parser
  drivers: 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        | 498 ++++++++++++++
 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                               |  46 +-
 drivers/hwmon/tmp102.c                             |  28 +
 drivers/thermal/Kconfig                            |  14 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/cpu_cooling.c                      |  31 +
 drivers/thermal/of-thermal.c                       | 763 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |  19 +-
 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                            |  28 +-
 22 files changed, 1701 insertions(+), 32 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] [PATCH 00/16] device thermal limits represented in device tree nodes (v3)

[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 third version
of this work. Previous versions were sent as RFCs and can be found here:
RFCv2: http://lkml.org/lkml/2013/8/23/594
RFCv1: http://lkml.org/lkml/2013/7/22/319

The major change between RFCv2 and this version is the fact that I am now
designing the binding accordingly to the common practice of creating links
from consumers to producers, as seen in regulators for instance. The change
make a thermal zone node point to used cooling devices and used sensor devices.
As direct need, cooling devices then need to be properly represented.
I am proposing to have cooling properties inside existing nodes, e.g. fan nodes,
cpu nodes. The change also required me to modify the existing thermal core
code to allow decoupling thermal zones from sensor code. Currently, the
binding proposal covers for the situation in which one thermal zone has
several sensor devices. Although this situation is not covered by the
current thermal framework code, and thus not supported by this series.
I believe this is not a stopper for this series, it can be done
in later patch sets.

The second patch includes a detailed documentation with examples
and the proposed code. In this patch series, a part from the dt parser,
there are changes in the cpufreq code to load the cpu cooling device,
also changes in the following sensor drivers: tmp102, lm75 and ti-soc-thermal.
Several changes in TI's SoC DT bindings are also included, as source
of tested examples.

The present patch series was tested on OMAP4430, OMAP4460, OMAP5430 and DRA7,
although the DRA7 changes were not sent as the core device tree support is
currently in the process to find its way to upstream.

All best,

Eduardo Valentin (16):
  drivers: thermal: allow registering without .get_temp
  drivers: thermal: introduce device tree parser
  drivers: 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        | 498 ++++++++++++++
 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                               |  46 +-
 drivers/hwmon/tmp102.c                             |  28 +
 drivers/thermal/Kconfig                            |  14 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/cpu_cooling.c                      |  31 +
 drivers/thermal/of-thermal.c                       | 763 +++++++++++++++++++++
 drivers/thermal/thermal_core.c                     |  19 +-
 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                            |  28 +-
 22 files changed, 1701 insertions(+), 32 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

[PATCH 03/16] drivers: thermal: cpu_cooling: introduce of_cpufreq_cooling_register

[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 | 31 +++++++++++++++++++++++++++++++
 include/linux/cpu_cooling.h   | 25 +++++++++++++++++++++++++
 3 files changed, 57 insertions(+)

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..cd2f532 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -491,6 +491,37 @@ cpufreq_cooling_register(const struct cpumask *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.
+ *
+ * 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)
+{
+	struct thermal_cooling_device *cdev;
+
+	if (!np)
+		return ERR_PTR(-EINVAL);
+
+	cdev = cpufreq_cooling_register(clip_cpus);
+	if (IS_ERR(cdev))
+		return cdev;
+
+	cdev->np = np;
+
+	return cdev;
+}
+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

[PATCH 03/16] drivers: thermal: cpu_cooling: introduce of_cpufreq_cooling_register

[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 | 31 +++++++++++++++++++++++++++++++
 include/linux/cpu_cooling.h   | 25 +++++++++++++++++++++++++
 3 files changed, 57 insertions(+)

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..cd2f532 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -491,6 +491,37 @@ cpufreq_cooling_register(const struct cpumask *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.
+ *
+ * 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)
+{
+	struct thermal_cooling_device *cdev;
+
+	if (!np)
+		return ERR_PTR(-EINVAL);
+
+	cdev = cpufreq_cooling_register(clip_cpus);
+	if (IS_ERR(cdev))
+		return cdev;
+
+	cdev->np = np;
+
+	return cdev;
+}
+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] [PATCH 03/16] drivers: thermal: cpu_cooling: introduce of_cpufreq_cooling_register

[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 | 31 +++++++++++++++++++++++++++++++
 include/linux/cpu_cooling.h   | 25 +++++++++++++++++++++++++
 3 files changed, 57 insertions(+)

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..cd2f532 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -491,6 +491,37 @@ cpufreq_cooling_register(const struct cpumask *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.
+ *
+ * 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)
+{
+	struct thermal_cooling_device *cdev;
+
+	if (!np)
+		return ERR_PTR(-EINVAL);
+
+	cdev = cpufreq_cooling_register(clip_cpus);
+	if (IS_ERR(cdev))
+		return cdev;
+
+	cdev->np = np;
+
+	return cdev;
+}
+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

[PATCH 04/16] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties

[Eduardo Valentin]

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..92e6921 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 && 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 cbfffa9..c573e95 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -12,7 +12,9 @@
 #define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
 
 #include <linux/clk.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>
@@ -20,6 +22,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 */
@@ -28,6 +31,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)
 {
@@ -255,6 +259,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;
 
@@ -267,6 +282,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

[PATCH 04/16] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties

[Eduardo Valentin]

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..92e6921 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 && 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 cbfffa9..c573e95 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -12,7 +12,9 @@
 #define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
 
 #include <linux/clk.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>
@@ -20,6 +22,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 */
@@ -28,6 +31,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)
 {
@@ -255,6 +259,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;
 
@@ -267,6 +282,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] [PATCH 04/16] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties

[Eduardo Valentin]

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..92e6921 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 && 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 cbfffa9..c573e95 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -12,7 +12,9 @@
 #define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
 
 #include <linux/clk.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>
@@ -20,6 +22,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 */
@@ -28,6 +31,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)
 {
@@ -255,6 +259,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;
 
@@ -267,6 +282,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

[PATCH 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..2ba09ef 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,42 @@ 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);
+	long temperature;
+
+	if (IS_ERR(data))
+		return PTR_ERR(data);
+
+	temperature = lm75_reg_to_mc(data->temp[0], data->resolution);
+	if (temperature < 0)
+		dev_warn(data->hwmon_dev,
+			 "operating in negative temp: %ld\n", temperature);
+
+	*temp = temperature;
+
+	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 +294,17 @@ 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)) {
+		dev_warn(&client->dev,
+			 "Could not parse thermal data in device tree: %ld\n",
+			 PTR_ERR(data->tz));
+		data->tz = NULL;
+	}
+
 	dev_info(&client->dev, "%s: sensor '%s'\n",
 		 dev_name(data->hwmon_dev), client->name);
 
@@ -285,6 +319,8 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

[PATCH 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..2ba09ef 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,42 @@ 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);
+	long temperature;
+
+	if (IS_ERR(data))
+		return PTR_ERR(data);
+
+	temperature = lm75_reg_to_mc(data->temp[0], data->resolution);
+	if (temperature < 0)
+		dev_warn(data->hwmon_dev,
+			 "operating in negative temp: %ld\n", temperature);
+
+	*temp = temperature;
+
+	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 +294,17 @@ 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)) {
+		dev_warn(&client->dev,
+			 "Could not parse thermal data in device tree: %ld\n",
+			 PTR_ERR(data->tz));
+		data->tz = NULL;
+	}
+
 	dev_info(&client->dev, "%s: sensor '%s'\n",
 		 dev_name(data->hwmon_dev), client->name);
 
@@ -285,6 +319,8 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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] [PATCH 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..2ba09ef 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,42 @@ 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);
+	long temperature;
+
+	if (IS_ERR(data))
+		return PTR_ERR(data);
+
+	temperature = lm75_reg_to_mc(data->temp[0], data->resolution);
+	if (temperature < 0)
+		dev_warn(data->hwmon_dev,
+			 "operating in negative temp: %ld\n", temperature);
+
+	*temp = temperature;
+
+	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 +294,17 @@ 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)) {
+		dev_warn(&client->dev,
+			 "Could not parse thermal data in device tree: %ld\n",
+			 PTR_ERR(data->tz));
+		data->tz = NULL;
+	}
+
 	dev_info(&client->dev, "%s: sensor '%s'\n",
 		 dev_name(data->hwmon_dev), client->name);
 
@@ -285,6 +319,8 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

Re: [PATCH 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> 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-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
> Cc: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
> ---
>   drivers/hwmon/lm75.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index c03b490..2ba09ef 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,42 @@ 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);
> +	long temperature;
> +
> +	if (IS_ERR(data))
> +		return PTR_ERR(data);
> +
> +	temperature = lm75_reg_to_mc(data->temp[0], data->resolution);
> +	if (temperature < 0)
> +		dev_warn(data->hwmon_dev,
> +			 "operating in negative temp: %ld\n", temperature);

Please drop this warning. It is not the responsibility of the chip driver
to declare valid operational conditions, much less an arbitrary one
like zero degrees C.

Guenter

> +
> +	*temp = temperature;
> +
> +	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 +294,17 @@ 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)) {
> +		dev_warn(&client->dev,
> +			 "Could not parse thermal data in device tree: %ld\n",
> +			 PTR_ERR(data->tz));
> +		data->tz = NULL;
> +	}
> +
>   	dev_info(&client->dev, "%s: sensor '%s'\n",
>   		 dev_name(data->hwmon_dev), client->name);
>
> @@ -285,6 +319,8 @@ static int lm75_remove(struct i2c_client *client)
>   {
>   	struct lm75_data *data = i2c_get_clientdata(client);
>
> +	/* thermal zone life cycle is not our responsibility */
> +	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);
>

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

Re: [PATCH 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>   drivers/hwmon/lm75.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index c03b490..2ba09ef 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,42 @@ 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);
> +	long temperature;
> +
> +	if (IS_ERR(data))
> +		return PTR_ERR(data);
> +
> +	temperature = lm75_reg_to_mc(data->temp[0], data->resolution);
> +	if (temperature < 0)
> +		dev_warn(data->hwmon_dev,
> +			 "operating in negative temp: %ld\n", temperature);

Please drop this warning. It is not the responsibility of the chip driver
to declare valid operational conditions, much less an arbitrary one
like zero degrees C.

Guenter

> +
> +	*temp = temperature;
> +
> +	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 +294,17 @@ 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)) {
> +		dev_warn(&client->dev,
> +			 "Could not parse thermal data in device tree: %ld\n",
> +			 PTR_ERR(data->tz));
> +		data->tz = NULL;
> +	}
> +
>   	dev_info(&client->dev, "%s: sensor '%s'\n",
>   		 dev_name(data->hwmon_dev), client->name);
>
> @@ -285,6 +319,8 @@ static int lm75_remove(struct i2c_client *client)
>   {
>   	struct lm75_data *data = i2c_get_clientdata(client);
>
> +	/* thermal zone life cycle is not our responsibility */
> +	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);
>

Re: [lm-sensors] [PATCH 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>   drivers/hwmon/lm75.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index c03b490..2ba09ef 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,42 @@ 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);
> +	long temperature;
> +
> +	if (IS_ERR(data))
> +		return PTR_ERR(data);
> +
> +	temperature = lm75_reg_to_mc(data->temp[0], data->resolution);
> +	if (temperature < 0)
> +		dev_warn(data->hwmon_dev,
> +			 "operating in negative temp: %ld\n", temperature);

Please drop this warning. It is not the responsibility of the chip driver
to declare valid operational conditions, much less an arbitrary one
like zero degrees C.

Guenter

> +
> +	*temp = temperature;
> +
> +	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 +294,17 @@ 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)) {
> +		dev_warn(&client->dev,
> +			 "Could not parse thermal data in device tree: %ld\n",
> +			 PTR_ERR(data->tz));
> +		data->tz = NULL;
> +	}
> +
>   	dev_info(&client->dev, "%s: sensor '%s'\n",
>   		 dev_name(data->hwmon_dev), client->name);
>
> @@ -285,6 +319,8 @@ static int lm75_remove(struct i2c_client *client)
>   {
>   	struct lm75_data *data = i2c_get_clientdata(client);
>
> +	/* thermal zone life cycle is not our responsibility */
> +	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);
>


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

[PATCHv2 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
---
 drivers/hwmon/lm75.c | 36 +++++++++++++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 5 deletions(-)

---

Guenter,

Here is a version without the warnings, as requested.

Eduardo

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..e42e361 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,8 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

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

[PATCHv2 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 36 +++++++++++++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 5 deletions(-)

---

Guenter,

Here is a version without the warnings, as requested.

Eduardo

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..e42e361 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,8 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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] [PATCHv2 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/lm75.c | 36 +++++++++++++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 5 deletions(-)

---

Guenter,

Here is a version without the warnings, as requested.

Eduardo

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..e42e361 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,8 @@ static int lm75_remove(struct i2c_client *client)
 {
 	struct lm75_data *data = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

[PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

Very minor change, removing comment, as requested.

Eduardo

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

[PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

Very minor change, removing comment, as requested.

Eduardo

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] [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

Very minor change, removing comment, as requested.

Eduardo

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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

I assume this will be sent upstream through the thermal tree ?

Guenter

Re: [lm-sensors] [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

I assume this will be sent upstream through the thermal tree ?

Guenter


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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 21-09-2013 14:06, Guenter Roeck wrote:
> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux@roeck-us.net>
>> Cc: lm-sensors@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> 
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> 

Cool! thanks again for taking the time to review this.

> I assume this will be sent upstream through the thermal tree ?

Yeah, that is the idea, at least for the core part. The hwmon changes I
believe goes via hwmon tree, right?


I still need acks from device tree maintainers before moving forward,
though.


> 
> Guenter
> 
> 
> 


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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 21-09-2013 14:06, Guenter Roeck wrote:
> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux@roeck-us.net>
>> Cc: lm-sensors@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> 
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> 

Cool! thanks again for taking the time to review this.

> I assume this will be sent upstream through the thermal tree ?

Yeah, that is the idea, at least for the core part. The hwmon changes I
believe goes via hwmon tree, right?


I still need acks from device tree maintainers before moving forward,
though.


> 
> Guenter
> 
> 
> 


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

Re: [lm-sensors] [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 21-09-2013 14:06, Guenter Roeck wrote:
> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux@roeck-us.net>
>> Cc: lm-sensors@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> 
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> 

Cool! thanks again for taking the time to review this.

> I assume this will be sent upstream through the thermal tree ?

Yeah, that is the idea, at least for the core part. The hwmon changes I
believe goes via hwmon tree, right?


I still need acks from device tree maintainers before moving forward,
though.


> 
> Guenter
> 
> 
> 


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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
> On 21-09-2013 14:06, Guenter Roeck wrote:
>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>> 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-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
>>> Cc: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>>> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>>
>> Acked-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>>
>
> Cool! thanks again for taking the time to review this.
>
>> I assume this will be sent upstream through the thermal tree ?
>
> Yeah, that is the idea, at least for the core part. The hwmon changes I
> believe goes via hwmon tree, right?
>

Not necessarily, as the hwmon code depends on the core code.
In such cases it is quite common that both are sent through the same tree.

Guenter

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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
> On 21-09-2013 14:06, Guenter Roeck wrote:
>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>> 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: Guenter Roeck <linux@roeck-us.net>
>>> Cc: lm-sensors@lm-sensors.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>
>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>
>
> Cool! thanks again for taking the time to review this.
>
>> I assume this will be sent upstream through the thermal tree ?
>
> Yeah, that is the idea, at least for the core part. The hwmon changes I
> believe goes via hwmon tree, right?
>

Not necessarily, as the hwmon code depends on the core code.
In such cases it is quite common that both are sent through the same tree.

Guenter

Re: [lm-sensors] [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
> On 21-09-2013 14:06, Guenter Roeck wrote:
>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>> 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: Guenter Roeck <linux@roeck-us.net>
>>> Cc: lm-sensors@lm-sensors.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>
>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>
>
> Cool! thanks again for taking the time to review this.
>
>> I assume this will be sent upstream through the thermal tree ?
>
> Yeah, that is the idea, at least for the core part. The hwmon changes I
> believe goes via hwmon tree, right?
>

Not necessarily, as the hwmon code depends on the core code.
In such cases it is quite common that both are sent through the same tree.

Guenter


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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 21-09-2013 19:56, Guenter Roeck wrote:
> On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
>> On 21-09-2013 14:06, Guenter Roeck wrote:
>>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>>> 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: Guenter Roeck <linux@roeck-us.net>
>>>> Cc: lm-sensors@lm-sensors.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>
>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>
>>
>> Cool! thanks again for taking the time to review this.
>>
>>> I assume this will be sent upstream through the thermal tree ?
>>
>> Yeah, that is the idea, at least for the core part. The hwmon changes I
>> believe goes via hwmon tree, right?
>>
> 
> Not necessarily, as the hwmon code depends on the core code.
> In such cases it is quite common that both are sent through the same tree.

If this works for you I can queue these changes via the thermal tree.

> 
> Guenter
> 
> 
> 


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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 21-09-2013 19:56, Guenter Roeck wrote:
> On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
>> On 21-09-2013 14:06, Guenter Roeck wrote:
>>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>>> 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: Guenter Roeck <linux@roeck-us.net>
>>>> Cc: lm-sensors@lm-sensors.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>
>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>
>>
>> Cool! thanks again for taking the time to review this.
>>
>>> I assume this will be sent upstream through the thermal tree ?
>>
>> Yeah, that is the idea, at least for the core part. The hwmon changes I
>> believe goes via hwmon tree, right?
>>
> 
> Not necessarily, as the hwmon code depends on the core code.
> In such cases it is quite common that both are sent through the same tree.

If this works for you I can queue these changes via the thermal tree.

> 
> Guenter
> 
> 
> 


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

Re: [lm-sensors] [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 21-09-2013 19:56, Guenter Roeck wrote:
> On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
>> On 21-09-2013 14:06, Guenter Roeck wrote:
>>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>>> 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: Guenter Roeck <linux@roeck-us.net>
>>>> Cc: lm-sensors@lm-sensors.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>
>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>
>>
>> Cool! thanks again for taking the time to review this.
>>
>>> I assume this will be sent upstream through the thermal tree ?
>>
>> Yeah, that is the idea, at least for the core part. The hwmon changes I
>> believe goes via hwmon tree, right?
>>
> 
> Not necessarily, as the hwmon code depends on the core code.
> In such cases it is quite common that both are sent through the same tree.

If this works for you I can queue these changes via the thermal tree.

> 
> Guenter
> 
> 
> 


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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/21/2013 05:23 PM, Eduardo Valentin wrote:
> On 21-09-2013 19:56, Guenter Roeck wrote:
>> On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
>>> On 21-09-2013 14:06, Guenter Roeck wrote:
>>>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>>>> 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-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
>>>>> Cc: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>>>>> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
>>>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>>>>
>>>> Acked-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>>>>
>>>
>>> Cool! thanks again for taking the time to review this.
>>>
>>>> I assume this will be sent upstream through the thermal tree ?
>>>
>>> Yeah, that is the idea, at least for the core part. The hwmon changes I
>>> believe goes via hwmon tree, right?
>>>
>>
>> Not necessarily, as the hwmon code depends on the core code.
>> In such cases it is quite common that both are sent through the same tree.
>
> If this works for you I can queue these changes via the thermal tree.
>

Ok with me.

Guenter


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

Re: [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/21/2013 05:23 PM, Eduardo Valentin wrote:
> On 21-09-2013 19:56, Guenter Roeck wrote:
>> On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
>>> On 21-09-2013 14:06, Guenter Roeck wrote:
>>>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>>>> 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: Guenter Roeck <linux@roeck-us.net>
>>>>> Cc: lm-sensors@lm-sensors.org
>>>>> Cc: linux-kernel@vger.kernel.org
>>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>>
>>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>>
>>>
>>> Cool! thanks again for taking the time to review this.
>>>
>>>> I assume this will be sent upstream through the thermal tree ?
>>>
>>> Yeah, that is the idea, at least for the core part. The hwmon changes I
>>> believe goes via hwmon tree, right?
>>>
>>
>> Not necessarily, as the hwmon code depends on the core code.
>> In such cases it is quite common that both are sent through the same tree.
>
> If this works for you I can queue these changes via the thermal tree.
>

Ok with me.

Guenter

Re: [lm-sensors] [PATCHv3 05/16] hwmon: lm75: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/21/2013 05:23 PM, Eduardo Valentin wrote:
> On 21-09-2013 19:56, Guenter Roeck wrote:
>> On 09/21/2013 04:30 PM, Eduardo Valentin wrote:
>>> On 21-09-2013 14:06, Guenter Roeck wrote:
>>>> On 09/18/2013 09:21 AM, Eduardo Valentin wrote:
>>>>> 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: Guenter Roeck <linux@roeck-us.net>
>>>>> Cc: lm-sensors@lm-sensors.org
>>>>> Cc: linux-kernel@vger.kernel.org
>>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>>>>
>>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>>
>>>
>>> Cool! thanks again for taking the time to review this.
>>>
>>>> I assume this will be sent upstream through the thermal tree ?
>>>
>>> Yeah, that is the idea, at least for the core part. The hwmon changes I
>>> believe goes via hwmon tree, right?
>>>
>>
>> Not necessarily, as the hwmon code depends on the core code.
>> In such cases it is quite common that both are sent through the same tree.
>
> If this works for you I can queue these changes via the thermal tree.
>

Ok with me.

Guenter



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

[PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..e432444 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,19 @@ 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));
+
+	if (tmp102->temp[0] < 0)
+		dev_warn(tmp102->hwmon_dev,
+			 "operating in negative temp: %d\n", tmp102->temp[0]);
+
+	*temp = tmp102->temp[0];
+
+	return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
@@ -204,6 +220,16 @@ 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)) {
+		dev_warn(&client->dev,
+			 "Could not parse thermal data in device tree: %ld\n",
+			 PTR_ERR(tmp102->tz));
+		tmp102->tz = NULL;
+	}
+
 	dev_info(&client->dev, "initialized\n");
 
 	return 0;
@@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

[PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..e432444 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,19 @@ 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));
+
+	if (tmp102->temp[0] < 0)
+		dev_warn(tmp102->hwmon_dev,
+			 "operating in negative temp: %d\n", tmp102->temp[0]);
+
+	*temp = tmp102->temp[0];
+
+	return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
@@ -204,6 +220,16 @@ 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)) {
+		dev_warn(&client->dev,
+			 "Could not parse thermal data in device tree: %ld\n",
+			 PTR_ERR(tmp102->tz));
+		tmp102->tz = NULL;
+	}
+
 	dev_info(&client->dev, "initialized\n");
 
 	return 0;
@@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..e432444 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,19 @@ 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));
+
+	if (tmp102->temp[0] < 0)
+		dev_warn(tmp102->hwmon_dev,
+			 "operating in negative temp: %d\n", tmp102->temp[0]);
+
+	*temp = tmp102->temp[0];
+
+	return 0;
+}
+
 static ssize_t tmp102_show_temp(struct device *dev,
 				struct device_attribute *attr,
 				char *buf)
@@ -204,6 +220,16 @@ 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)) {
+		dev_warn(&client->dev,
+			 "Could not parse thermal data in device tree: %ld\n",
+			 PTR_ERR(tmp102->tz));
+		tmp102->tz = NULL;
+	}
+
 	dev_info(&client->dev, "initialized\n");
 
 	return 0;
@@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
> ---
>   drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
>   1 file changed, 28 insertions(+)
>
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index d7b47ab..e432444 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,19 @@ 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));
> +
> +	if (tmp102->temp[0] < 0)
> +		dev_warn(tmp102->hwmon_dev,
> +			 "operating in negative temp: %d\n", tmp102->temp[0]);
> +

Please drop this warning.

Guenter

> +	*temp = tmp102->temp[0];
> +
> +	return 0;
> +}
> +
>   static ssize_t tmp102_show_temp(struct device *dev,
>   				struct device_attribute *attr,
>   				char *buf)
> @@ -204,6 +220,16 @@ 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)) {
> +		dev_warn(&client->dev,
> +			 "Could not parse thermal data in device tree: %ld\n",
> +			 PTR_ERR(tmp102->tz));

Please drop this warning. You already create error messages in
thermal_zone_of_sensor_register(). That should be sufficient.
The same applies to the lm75 patch.

As a side note, I would suggest to provide devm_ functions for registration.
We are introducing those for hwmon registration, which enables us to remove
most _remove functions. It would be great if we can keep it that way.

On a higher level, I don't think it is a good idea to make thermal zones
and thermal zone data mandatory. Many systems may neither need nor want it.

Guenter

> +		tmp102->tz = NULL;
> +	}
> +
>   	dev_info(&client->dev, "initialized\n");
>
>   	return 0;
> @@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
>   {
>   	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>
> +	/* thermal zone life cycle is not our responsibility */
> +	thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
>   	hwmon_device_unregister(tmp102->hwmon_dev);
>   	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
>
>

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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>   drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
>   1 file changed, 28 insertions(+)
>
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index d7b47ab..e432444 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,19 @@ 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));
> +
> +	if (tmp102->temp[0] < 0)
> +		dev_warn(tmp102->hwmon_dev,
> +			 "operating in negative temp: %d\n", tmp102->temp[0]);
> +

Please drop this warning.

Guenter

> +	*temp = tmp102->temp[0];
> +
> +	return 0;
> +}
> +
>   static ssize_t tmp102_show_temp(struct device *dev,
>   				struct device_attribute *attr,
>   				char *buf)
> @@ -204,6 +220,16 @@ 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)) {
> +		dev_warn(&client->dev,
> +			 "Could not parse thermal data in device tree: %ld\n",
> +			 PTR_ERR(tmp102->tz));

Please drop this warning. You already create error messages in
thermal_zone_of_sensor_register(). That should be sufficient.
The same applies to the lm75 patch.

As a side note, I would suggest to provide devm_ functions for registration.
We are introducing those for hwmon registration, which enables us to remove
most _remove functions. It would be great if we can keep it that way.

On a higher level, I don't think it is a good idea to make thermal zones
and thermal zone data mandatory. Many systems may neither need nor want it.

Guenter

> +		tmp102->tz = NULL;
> +	}
> +
>   	dev_info(&client->dev, "initialized\n");
>
>   	return 0;
> @@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
>   {
>   	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>
> +	/* thermal zone life cycle is not our responsibility */
> +	thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
>   	hwmon_device_unregister(tmp102->hwmon_dev);
>   	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
>
>

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>   drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
>   1 file changed, 28 insertions(+)
>
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index d7b47ab..e432444 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,19 @@ 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));
> +
> +	if (tmp102->temp[0] < 0)
> +		dev_warn(tmp102->hwmon_dev,
> +			 "operating in negative temp: %d\n", tmp102->temp[0]);
> +

Please drop this warning.

Guenter

> +	*temp = tmp102->temp[0];
> +
> +	return 0;
> +}
> +
>   static ssize_t tmp102_show_temp(struct device *dev,
>   				struct device_attribute *attr,
>   				char *buf)
> @@ -204,6 +220,16 @@ 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)) {
> +		dev_warn(&client->dev,
> +			 "Could not parse thermal data in device tree: %ld\n",
> +			 PTR_ERR(tmp102->tz));

Please drop this warning. You already create error messages in
thermal_zone_of_sensor_register(). That should be sufficient.
The same applies to the lm75 patch.

As a side note, I would suggest to provide devm_ functions for registration.
We are introducing those for hwmon registration, which enables us to remove
most _remove functions. It would be great if we can keep it that way.

On a higher level, I don't think it is a good idea to make thermal zones
and thermal zone data mandatory. Many systems may neither need nor want it.

Guenter

> +		tmp102->tz = NULL;
> +	}
> +
>   	dev_info(&client->dev, "initialized\n");
>
>   	return 0;
> @@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
>   {
>   	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>
> +	/* thermal zone life cycle is not our responsibility */
> +	thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
>   	hwmon_device_unregister(tmp102->hwmon_dev);
>   	sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
>
>


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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 15-09-2013 19:33, Guenter Roeck wrote:
> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>> ---
>>   drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..e432444 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,19 @@ 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));
>> +
>> +    if (tmp102->temp[0] < 0)
>> +        dev_warn(tmp102->hwmon_dev,
>> +             "operating in negative temp: %d\n", tmp102->temp[0]);
>> +
> 
> Please drop this warning.
> 

Done for both drivers.

> Guenter
> 
>> +    *temp = tmp102->temp[0];
>> +
>> +    return 0;
>> +}
>> +
>>   static ssize_t tmp102_show_temp(struct device *dev,
>>                   struct device_attribute *attr,
>>                   char *buf)
>> @@ -204,6 +220,16 @@ 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)) {
>> +        dev_warn(&client->dev,
>> +             "Could not parse thermal data in device tree: %ld\n",
>> +             PTR_ERR(tmp102->tz));
> 
> Please drop this warning. You already create error messages in
> thermal_zone_of_sensor_register(). That should be sufficient.
> The same applies to the lm75 patch.

OK. Done for both.

> 
> As a side note, I would suggest to provide devm_ functions for
> registration.
> We are introducing those for hwmon registration, which enables us to remove
> most _remove functions. It would be great if we can keep it that way.
> 

Right. This side note is taken. Actually this is on my todo list for
quite a while. But I believe this should not block this series, should
it? I will be probably cleaning the thermal framework code after this
current work is accepted at least.

> On a higher level, I don't think it is a good idea to make thermal zones
> and thermal zone data mandatory. Many systems may neither need nor want it.
> 

Well, I agree with you. Did you see something hard required in the patch
I sent. I made it so that it could continue the driver probe without
thermal zones, as you requested.


I will repost both patches in reply to our thread.

Eduardo

> Guenter
> 
>> +        tmp102->tz = NULL;
>> +    }
>> +
>>       dev_info(&client->dev, "initialized\n");
>>
>>       return 0;
>> @@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
>>   {
>>       struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>
>> +    /* thermal zone life cycle is not our responsibility */
>> +    thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
>>       hwmon_device_unregister(tmp102->hwmon_dev);
>>       sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
>>
>>
> 
> 
> 


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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 15-09-2013 19:33, Guenter Roeck wrote:
> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux@roeck-us.net>
>> Cc: lm-sensors@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>   drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..e432444 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,19 @@ 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));
>> +
>> +    if (tmp102->temp[0] < 0)
>> +        dev_warn(tmp102->hwmon_dev,
>> +             "operating in negative temp: %d\n", tmp102->temp[0]);
>> +
> 
> Please drop this warning.
> 

Done for both drivers.

> Guenter
> 
>> +    *temp = tmp102->temp[0];
>> +
>> +    return 0;
>> +}
>> +
>>   static ssize_t tmp102_show_temp(struct device *dev,
>>                   struct device_attribute *attr,
>>                   char *buf)
>> @@ -204,6 +220,16 @@ 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)) {
>> +        dev_warn(&client->dev,
>> +             "Could not parse thermal data in device tree: %ld\n",
>> +             PTR_ERR(tmp102->tz));
> 
> Please drop this warning. You already create error messages in
> thermal_zone_of_sensor_register(). That should be sufficient.
> The same applies to the lm75 patch.

OK. Done for both.

> 
> As a side note, I would suggest to provide devm_ functions for
> registration.
> We are introducing those for hwmon registration, which enables us to remove
> most _remove functions. It would be great if we can keep it that way.
> 

Right. This side note is taken. Actually this is on my todo list for
quite a while. But I believe this should not block this series, should
it? I will be probably cleaning the thermal framework code after this
current work is accepted at least.

> On a higher level, I don't think it is a good idea to make thermal zones
> and thermal zone data mandatory. Many systems may neither need nor want it.
> 

Well, I agree with you. Did you see something hard required in the patch
I sent. I made it so that it could continue the driver probe without
thermal zones, as you requested.


I will repost both patches in reply to our thread.

Eduardo

> Guenter
> 
>> +        tmp102->tz = NULL;
>> +    }
>> +
>>       dev_info(&client->dev, "initialized\n");
>>
>>       return 0;
>> @@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
>>   {
>>       struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>
>> +    /* thermal zone life cycle is not our responsibility */
>> +    thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
>>       hwmon_device_unregister(tmp102->hwmon_dev);
>>       sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
>>
>>
> 
> 
> 


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

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 15-09-2013 19:33, Guenter Roeck wrote:
> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux@roeck-us.net>
>> Cc: lm-sensors@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>   drivers/hwmon/tmp102.c | 28 ++++++++++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..e432444 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,19 @@ 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));
>> +
>> +    if (tmp102->temp[0] < 0)
>> +        dev_warn(tmp102->hwmon_dev,
>> +             "operating in negative temp: %d\n", tmp102->temp[0]);
>> +
> 
> Please drop this warning.
> 

Done for both drivers.

> Guenter
> 
>> +    *temp = tmp102->temp[0];
>> +
>> +    return 0;
>> +}
>> +
>>   static ssize_t tmp102_show_temp(struct device *dev,
>>                   struct device_attribute *attr,
>>                   char *buf)
>> @@ -204,6 +220,16 @@ 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)) {
>> +        dev_warn(&client->dev,
>> +             "Could not parse thermal data in device tree: %ld\n",
>> +             PTR_ERR(tmp102->tz));
> 
> Please drop this warning. You already create error messages in
> thermal_zone_of_sensor_register(). That should be sufficient.
> The same applies to the lm75 patch.

OK. Done for both.

> 
> As a side note, I would suggest to provide devm_ functions for
> registration.
> We are introducing those for hwmon registration, which enables us to remove
> most _remove functions. It would be great if we can keep it that way.
> 

Right. This side note is taken. Actually this is on my todo list for
quite a while. But I believe this should not block this series, should
it? I will be probably cleaning the thermal framework code after this
current work is accepted at least.

> On a higher level, I don't think it is a good idea to make thermal zones
> and thermal zone data mandatory. Many systems may neither need nor want it.
> 

Well, I agree with you. Did you see something hard required in the patch
I sent. I made it so that it could continue the driver probe without
thermal zones, as you requested.


I will repost both patches in reply to our thread.

Eduardo

> Guenter
> 
>> +        tmp102->tz = NULL;
>> +    }
>> +
>>       dev_info(&client->dev, "initialized\n");
>>
>>       return 0;
>> @@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
>>   {
>>       struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>
>> +    /* thermal zone life cycle is not our responsibility */
>> +    thermal_zone_of_sensor_unregister(&client->dev, tmp102->tz);
>>       hwmon_device_unregister(tmp102->hwmon_dev);
>>       sysfs_remove_group(&client->dev.kobj, &tmp102_attr_group);
>>
>>
> 
> 
> 


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

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 07:18, Guenter Roeck wrote:
> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
>> On 15-09-2013 19:33, Guenter Roeck wrote:
>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>>>> 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: Guenter Roeck
>>>> <linux@roeck-us.net> Cc: lm-sensors@lm-sensors.org Cc:
>>>> linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin
>>>> <eduardo.valentin@ti.com> --- drivers/hwmon/tmp102.c | 28
>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
>>>> 
>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
>>> 
>>> Please drop this warning.
>>> 
>> 
>> Done for both drivers.
>> 
>>> Guenter
>>> 
>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
>>>> ssize_t tmp102_show_temp(struct device *dev, struct
>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
>>>> dev_warn(&client->dev, +             "Could not parse thermal
>>>> data in device tree: %ld\n", +
>>>> PTR_ERR(tmp102->tz));
>>> 
>>> Please drop this warning. You already create error messages in 
>>> thermal_zone_of_sensor_register(). That should be sufficient. The
>>> same applies to the lm75 patch.
>> 
>> OK. Done for both.
>> 
>>> 
>>> As a side note, I would suggest to provide devm_ functions for 
>>> registration. We are introducing those for hwmon registration,
>>> which enables us to remove most _remove functions. It would be
>>> great if we can keep it that way.
>>> 
>> 
>> Right. This side note is taken. Actually this is on my todo list
>> for quite a while. But I believe this should not block this series,
>> should it? I will be probably cleaning the thermal framework code
>> after this current work is accepted at least.
>> 
>>> On a higher level, I don't think it is a good idea to make
>>> thermal zones and thermal zone data mandatory. Many systems may
>>> neither need nor want it.
>>> 
>> 
>> Well, I agree with you. Did you see something hard required in the
>> patch I sent. I made it so that it could continue the driver probe
>> without thermal zones, as you requested.
>> 
> If it is not mandatory you should not dump an error message to the
> console in the thermal registration function. Since you do, you at
> least consider it mandatory if that function is called.
> 
> So please either drop the error message from the registration
> function or add a check into the drivers to only register into the
> thermal subsystem if there is a respective thermal entry for that
> sensor in the devicetree data.
> 
> There are systes out there with literally dozens of temperature
> sensors. In many cases, those are purely for system health
> monitoring, not for thermal management. I don't want to end up in a
> situation where users complain about dozens of error messages on the
> console and no way to avoid it but providing dummy thermal subsystem
> data.
> 

Now I see.


Then I will rollback to the previous version in which lm sensors were
first probing for thermal properties within their dt node. Something like:
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index dc96598..cb1c663 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -216,11 +216,13 @@ 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;
+       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
+               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");


Does it sound reasonable?


> Guenter
> 
> 


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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 07:18, Guenter Roeck wrote:
> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
>> On 15-09-2013 19:33, Guenter Roeck wrote:
>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>>>> 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: Guenter Roeck
>>>> <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Cc:
>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Eduardo Valentin
>>>> <eduardo.valentin-l0cyMroinI0@public.gmane.org> --- drivers/hwmon/tmp102.c | 28
>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
>>>> 
>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
>>> 
>>> Please drop this warning.
>>> 
>> 
>> Done for both drivers.
>> 
>>> Guenter
>>> 
>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
>>>> ssize_t tmp102_show_temp(struct device *dev, struct
>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
>>>> dev_warn(&client->dev, +             "Could not parse thermal
>>>> data in device tree: %ld\n", +
>>>> PTR_ERR(tmp102->tz));
>>> 
>>> Please drop this warning. You already create error messages in 
>>> thermal_zone_of_sensor_register(). That should be sufficient. The
>>> same applies to the lm75 patch.
>> 
>> OK. Done for both.
>> 
>>> 
>>> As a side note, I would suggest to provide devm_ functions for 
>>> registration. We are introducing those for hwmon registration,
>>> which enables us to remove most _remove functions. It would be
>>> great if we can keep it that way.
>>> 
>> 
>> Right. This side note is taken. Actually this is on my todo list
>> for quite a while. But I believe this should not block this series,
>> should it? I will be probably cleaning the thermal framework code
>> after this current work is accepted at least.
>> 
>>> On a higher level, I don't think it is a good idea to make
>>> thermal zones and thermal zone data mandatory. Many systems may
>>> neither need nor want it.
>>> 
>> 
>> Well, I agree with you. Did you see something hard required in the
>> patch I sent. I made it so that it could continue the driver probe
>> without thermal zones, as you requested.
>> 
> If it is not mandatory you should not dump an error message to the
> console in the thermal registration function. Since you do, you at
> least consider it mandatory if that function is called.
> 
> So please either drop the error message from the registration
> function or add a check into the drivers to only register into the
> thermal subsystem if there is a respective thermal entry for that
> sensor in the devicetree data.
> 
> There are systes out there with literally dozens of temperature
> sensors. In many cases, those are purely for system health
> monitoring, not for thermal management. I don't want to end up in a
> situation where users complain about dozens of error messages on the
> console and no way to avoid it but providing dummy thermal subsystem
> data.
> 

Now I see.


Then I will rollback to the previous version in which lm sensors were
first probing for thermal properties within their dt node. Something like:
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index dc96598..cb1c663 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -216,11 +216,13 @@ 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;
+       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
+               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");


Does it sound reasonable?


> Guenter
> 
> 


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

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
> On 18-09-2013 07:18, Guenter Roeck wrote:
> > On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
> >> On 15-09-2013 19:33, Guenter Roeck wrote:
> >>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> >>>> 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: Guenter Roeck
> >>>> <linux@roeck-us.net> Cc: lm-sensors@lm-sensors.org Cc:
> >>>> linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin
> >>>> <eduardo.valentin@ti.com> --- drivers/hwmon/tmp102.c | 28
> >>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
> >>>> 
> >>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
> >>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
> >>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
> >>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
> >>> 
> >>> Please drop this warning.
> >>> 
> >> 
> >> Done for both drivers.
> >> 
> >>> Guenter
> >>> 
> >>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
> >>>> ssize_t tmp102_show_temp(struct device *dev, struct
> >>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
> >>>> dev_warn(&client->dev, +             "Could not parse thermal
> >>>> data in device tree: %ld\n", +
> >>>> PTR_ERR(tmp102->tz));
> >>> 
> >>> Please drop this warning. You already create error messages in 
> >>> thermal_zone_of_sensor_register(). That should be sufficient. The
> >>> same applies to the lm75 patch.
> >> 
> >> OK. Done for both.
> >> 
> >>> 
> >>> As a side note, I would suggest to provide devm_ functions for 
> >>> registration. We are introducing those for hwmon registration,
> >>> which enables us to remove most _remove functions. It would be
> >>> great if we can keep it that way.
> >>> 
> >> 
> >> Right. This side note is taken. Actually this is on my todo list
> >> for quite a while. But I believe this should not block this series,
> >> should it? I will be probably cleaning the thermal framework code
> >> after this current work is accepted at least.
> >> 
> >>> On a higher level, I don't think it is a good idea to make
> >>> thermal zones and thermal zone data mandatory. Many systems may
> >>> neither need nor want it.
> >>> 
> >> 
> >> Well, I agree with you. Did you see something hard required in the
> >> patch I sent. I made it so that it could continue the driver probe
> >> without thermal zones, as you requested.
> >> 
> > If it is not mandatory you should not dump an error message to the
> > console in the thermal registration function. Since you do, you at
> > least consider it mandatory if that function is called.
> > 
> > So please either drop the error message from the registration
> > function or add a check into the drivers to only register into the
> > thermal subsystem if there is a respective thermal entry for that
> > sensor in the devicetree data.
> > 
> > There are systes out there with literally dozens of temperature
> > sensors. In many cases, those are purely for system health
> > monitoring, not for thermal management. I don't want to end up in a
> > situation where users complain about dozens of error messages on the
> > console and no way to avoid it but providing dummy thermal subsystem
> > data.
> > 
> 
> Now I see.
> 
> 
> Then I will rollback to the previous version in which lm sensors were
> first probing for thermal properties within their dt node. Something like:
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index dc96598..cb1c663 100644
> --- a/drivers/hwmon/tmp102.c
> +++ b/drivers/hwmon/tmp102.c
> @@ -216,11 +216,13 @@ 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;
> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
> +               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");
> 
> 
> Does it sound reasonable?
> 
Personally I would prefer if the registration code fails silently.
Pushing the above code into each driver is just adding the same code
repeatedly all over the place.

Also, each sensor instance will still result in an error if there
is no global "thermal-zones" entry. Checking for that global entry
in each driver would be even more excessive, and I just don't like
that noisyness.

Also, I think you'll need to create devicetree bindings documents
for the two sensors.

Guenter

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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
> On 18-09-2013 07:18, Guenter Roeck wrote:
> > On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
> >> On 15-09-2013 19:33, Guenter Roeck wrote:
> >>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> >>>> 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: Guenter Roeck
> >>>> <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Cc:
> >>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Eduardo Valentin
> >>>> <eduardo.valentin-l0cyMroinI0@public.gmane.org> --- drivers/hwmon/tmp102.c | 28
> >>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
> >>>> 
> >>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
> >>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
> >>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
> >>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
> >>> 
> >>> Please drop this warning.
> >>> 
> >> 
> >> Done for both drivers.
> >> 
> >>> Guenter
> >>> 
> >>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
> >>>> ssize_t tmp102_show_temp(struct device *dev, struct
> >>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
> >>>> dev_warn(&client->dev, +             "Could not parse thermal
> >>>> data in device tree: %ld\n", +
> >>>> PTR_ERR(tmp102->tz));
> >>> 
> >>> Please drop this warning. You already create error messages in 
> >>> thermal_zone_of_sensor_register(). That should be sufficient. The
> >>> same applies to the lm75 patch.
> >> 
> >> OK. Done for both.
> >> 
> >>> 
> >>> As a side note, I would suggest to provide devm_ functions for 
> >>> registration. We are introducing those for hwmon registration,
> >>> which enables us to remove most _remove functions. It would be
> >>> great if we can keep it that way.
> >>> 
> >> 
> >> Right. This side note is taken. Actually this is on my todo list
> >> for quite a while. But I believe this should not block this series,
> >> should it? I will be probably cleaning the thermal framework code
> >> after this current work is accepted at least.
> >> 
> >>> On a higher level, I don't think it is a good idea to make
> >>> thermal zones and thermal zone data mandatory. Many systems may
> >>> neither need nor want it.
> >>> 
> >> 
> >> Well, I agree with you. Did you see something hard required in the
> >> patch I sent. I made it so that it could continue the driver probe
> >> without thermal zones, as you requested.
> >> 
> > If it is not mandatory you should not dump an error message to the
> > console in the thermal registration function. Since you do, you at
> > least consider it mandatory if that function is called.
> > 
> > So please either drop the error message from the registration
> > function or add a check into the drivers to only register into the
> > thermal subsystem if there is a respective thermal entry for that
> > sensor in the devicetree data.
> > 
> > There are systes out there with literally dozens of temperature
> > sensors. In many cases, those are purely for system health
> > monitoring, not for thermal management. I don't want to end up in a
> > situation where users complain about dozens of error messages on the
> > console and no way to avoid it but providing dummy thermal subsystem
> > data.
> > 
> 
> Now I see.
> 
> 
> Then I will rollback to the previous version in which lm sensors were
> first probing for thermal properties within their dt node. Something like:
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index dc96598..cb1c663 100644
> --- a/drivers/hwmon/tmp102.c
> +++ b/drivers/hwmon/tmp102.c
> @@ -216,11 +216,13 @@ 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;
> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
> +               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");
> 
> 
> Does it sound reasonable?
> 
Personally I would prefer if the registration code fails silently.
Pushing the above code into each driver is just adding the same code
repeatedly all over the place.

Also, each sensor instance will still result in an error if there
is no global "thermal-zones" entry. Checking for that global entry
in each driver would be even more excessive, and I just don't like
that noisyness.

Also, I think you'll need to create devicetree bindings documents
for the two sensors.

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

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 11:17, Guenter Roeck wrote:
> On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
>> On 18-09-2013 07:18, Guenter Roeck wrote:
>>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
>>>> On 15-09-2013 19:33, Guenter Roeck wrote:
>>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>>>>>> 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: Guenter Roeck
>>>>>> <linux@roeck-us.net> Cc: lm-sensors@lm-sensors.org Cc:
>>>>>> linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin
>>>>>> <eduardo.valentin@ti.com> --- drivers/hwmon/tmp102.c | 28
>>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
>>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
>>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
>>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
>>>>>
>>>>> Please drop this warning.
>>>>>
>>>>
>>>> Done for both drivers.
>>>>
>>>>> Guenter
>>>>>
>>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
>>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
>>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
>>>>>> dev_warn(&client->dev, +             "Could not parse thermal
>>>>>> data in device tree: %ld\n", +
>>>>>> PTR_ERR(tmp102->tz));
>>>>>
>>>>> Please drop this warning. You already create error messages in 
>>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
>>>>> same applies to the lm75 patch.
>>>>
>>>> OK. Done for both.
>>>>
>>>>>
>>>>> As a side note, I would suggest to provide devm_ functions for 
>>>>> registration. We are introducing those for hwmon registration,
>>>>> which enables us to remove most _remove functions. It would be
>>>>> great if we can keep it that way.
>>>>>
>>>>
>>>> Right. This side note is taken. Actually this is on my todo list
>>>> for quite a while. But I believe this should not block this series,
>>>> should it? I will be probably cleaning the thermal framework code
>>>> after this current work is accepted at least.
>>>>
>>>>> On a higher level, I don't think it is a good idea to make
>>>>> thermal zones and thermal zone data mandatory. Many systems may
>>>>> neither need nor want it.
>>>>>
>>>>
>>>> Well, I agree with you. Did you see something hard required in the
>>>> patch I sent. I made it so that it could continue the driver probe
>>>> without thermal zones, as you requested.
>>>>
>>> If it is not mandatory you should not dump an error message to the
>>> console in the thermal registration function. Since you do, you at
>>> least consider it mandatory if that function is called.
>>>
>>> So please either drop the error message from the registration
>>> function or add a check into the drivers to only register into the
>>> thermal subsystem if there is a respective thermal entry for that
>>> sensor in the devicetree data.
>>>
>>> There are systes out there with literally dozens of temperature
>>> sensors. In many cases, those are purely for system health
>>> monitoring, not for thermal management. I don't want to end up in a
>>> situation where users complain about dozens of error messages on the
>>> console and no way to avoid it but providing dummy thermal subsystem
>>> data.
>>>
>>
>> Now I see.
>>
>>
>> Then I will rollback to the previous version in which lm sensors were
>> first probing for thermal properties within their dt node. Something like:
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index dc96598..cb1c663 100644
>> --- a/drivers/hwmon/tmp102.c
>> +++ b/drivers/hwmon/tmp102.c
>> @@ -216,11 +216,13 @@ 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;
>> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
>> +               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");
>>
>>
>> Does it sound reasonable?
>>
> Personally I would prefer if the registration code fails silently.
> Pushing the above code into each driver is just adding the same code
> repeatedly all over the place.

Fair enough. It becomes tedious and just duplicating code. I agree.

So I will keep the v2 I just sent and remove the annoying error messages
from of-thermal.c while registering the sensors.

> 
> Also, each sensor instance will still result in an error if there
> is no global "thermal-zones" entry. Checking for that global entry
> in each driver would be even more excessive, and I just don't like
> that noisyness.
> 
> Also, I think you'll need to create devicetree bindings documents
> for the two sensors.
> 

Why would I? There is only one extra property and that is already
documented. I think the sensor still falls into the dummy dt node.

> Guenter
> 
> 


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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 11:17, Guenter Roeck wrote:
> On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
>> On 18-09-2013 07:18, Guenter Roeck wrote:
>>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
>>>> On 15-09-2013 19:33, Guenter Roeck wrote:
>>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>>>>>> 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: Guenter Roeck
>>>>>> <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Cc:
>>>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Eduardo Valentin
>>>>>> <eduardo.valentin-l0cyMroinI0@public.gmane.org> --- drivers/hwmon/tmp102.c | 28
>>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
>>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
>>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
>>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
>>>>>
>>>>> Please drop this warning.
>>>>>
>>>>
>>>> Done for both drivers.
>>>>
>>>>> Guenter
>>>>>
>>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
>>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
>>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
>>>>>> dev_warn(&client->dev, +             "Could not parse thermal
>>>>>> data in device tree: %ld\n", +
>>>>>> PTR_ERR(tmp102->tz));
>>>>>
>>>>> Please drop this warning. You already create error messages in 
>>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
>>>>> same applies to the lm75 patch.
>>>>
>>>> OK. Done for both.
>>>>
>>>>>
>>>>> As a side note, I would suggest to provide devm_ functions for 
>>>>> registration. We are introducing those for hwmon registration,
>>>>> which enables us to remove most _remove functions. It would be
>>>>> great if we can keep it that way.
>>>>>
>>>>
>>>> Right. This side note is taken. Actually this is on my todo list
>>>> for quite a while. But I believe this should not block this series,
>>>> should it? I will be probably cleaning the thermal framework code
>>>> after this current work is accepted at least.
>>>>
>>>>> On a higher level, I don't think it is a good idea to make
>>>>> thermal zones and thermal zone data mandatory. Many systems may
>>>>> neither need nor want it.
>>>>>
>>>>
>>>> Well, I agree with you. Did you see something hard required in the
>>>> patch I sent. I made it so that it could continue the driver probe
>>>> without thermal zones, as you requested.
>>>>
>>> If it is not mandatory you should not dump an error message to the
>>> console in the thermal registration function. Since you do, you at
>>> least consider it mandatory if that function is called.
>>>
>>> So please either drop the error message from the registration
>>> function or add a check into the drivers to only register into the
>>> thermal subsystem if there is a respective thermal entry for that
>>> sensor in the devicetree data.
>>>
>>> There are systes out there with literally dozens of temperature
>>> sensors. In many cases, those are purely for system health
>>> monitoring, not for thermal management. I don't want to end up in a
>>> situation where users complain about dozens of error messages on the
>>> console and no way to avoid it but providing dummy thermal subsystem
>>> data.
>>>
>>
>> Now I see.
>>
>>
>> Then I will rollback to the previous version in which lm sensors were
>> first probing for thermal properties within their dt node. Something like:
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index dc96598..cb1c663 100644
>> --- a/drivers/hwmon/tmp102.c
>> +++ b/drivers/hwmon/tmp102.c
>> @@ -216,11 +216,13 @@ 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;
>> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
>> +               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");
>>
>>
>> Does it sound reasonable?
>>
> Personally I would prefer if the registration code fails silently.
> Pushing the above code into each driver is just adding the same code
> repeatedly all over the place.

Fair enough. It becomes tedious and just duplicating code. I agree.

So I will keep the v2 I just sent and remove the annoying error messages
from of-thermal.c while registering the sensors.

> 
> Also, each sensor instance will still result in an error if there
> is no global "thermal-zones" entry. Checking for that global entry
> in each driver would be even more excessive, and I just don't like
> that noisyness.
> 
> Also, I think you'll need to create devicetree bindings documents
> for the two sensors.
> 

Why would I? There is only one extra property and that is already
documented. I think the sensor still falls into the dummy dt node.

> Guenter
> 
> 


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

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Wed, Sep 18, 2013 at 11:54:18AM -0400, Eduardo Valentin wrote:
> On 18-09-2013 11:17, Guenter Roeck wrote:
> > On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
> >> On 18-09-2013 07:18, Guenter Roeck wrote:
> >>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
> >>>> On 15-09-2013 19:33, Guenter Roeck wrote:
> >>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> >>>>>> 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: Guenter Roeck
> >>>>>> <linux@roeck-us.net> Cc: lm-sensors@lm-sensors.org Cc:
> >>>>>> linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin
> >>>>>> <eduardo.valentin@ti.com> --- drivers/hwmon/tmp102.c | 28
> >>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
> >>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
> >>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
> >>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
> >>>>>
> >>>>> Please drop this warning.
> >>>>>
> >>>>
> >>>> Done for both drivers.
> >>>>
> >>>>> Guenter
> >>>>>
> >>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
> >>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
> >>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
> >>>>>> dev_warn(&client->dev, +             "Could not parse thermal
> >>>>>> data in device tree: %ld\n", +
> >>>>>> PTR_ERR(tmp102->tz));
> >>>>>
> >>>>> Please drop this warning. You already create error messages in 
> >>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
> >>>>> same applies to the lm75 patch.
> >>>>
> >>>> OK. Done for both.
> >>>>
> >>>>>
> >>>>> As a side note, I would suggest to provide devm_ functions for 
> >>>>> registration. We are introducing those for hwmon registration,
> >>>>> which enables us to remove most _remove functions. It would be
> >>>>> great if we can keep it that way.
> >>>>>
> >>>>
> >>>> Right. This side note is taken. Actually this is on my todo list
> >>>> for quite a while. But I believe this should not block this series,
> >>>> should it? I will be probably cleaning the thermal framework code
> >>>> after this current work is accepted at least.
> >>>>
> >>>>> On a higher level, I don't think it is a good idea to make
> >>>>> thermal zones and thermal zone data mandatory. Many systems may
> >>>>> neither need nor want it.
> >>>>>
> >>>>
> >>>> Well, I agree with you. Did you see something hard required in the
> >>>> patch I sent. I made it so that it could continue the driver probe
> >>>> without thermal zones, as you requested.
> >>>>
> >>> If it is not mandatory you should not dump an error message to the
> >>> console in the thermal registration function. Since you do, you at
> >>> least consider it mandatory if that function is called.
> >>>
> >>> So please either drop the error message from the registration
> >>> function or add a check into the drivers to only register into the
> >>> thermal subsystem if there is a respective thermal entry for that
> >>> sensor in the devicetree data.
> >>>
> >>> There are systes out there with literally dozens of temperature
> >>> sensors. In many cases, those are purely for system health
> >>> monitoring, not for thermal management. I don't want to end up in a
> >>> situation where users complain about dozens of error messages on the
> >>> console and no way to avoid it but providing dummy thermal subsystem
> >>> data.
> >>>
> >>
> >> Now I see.
> >>
> >>
> >> Then I will rollback to the previous version in which lm sensors were
> >> first probing for thermal properties within their dt node. Something like:
> >> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> >> index dc96598..cb1c663 100644
> >> --- a/drivers/hwmon/tmp102.c
> >> +++ b/drivers/hwmon/tmp102.c
> >> @@ -216,11 +216,13 @@ 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;
> >> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
> >> +               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");
> >>
> >>
> >> Does it sound reasonable?
> >>
> > Personally I would prefer if the registration code fails silently.
> > Pushing the above code into each driver is just adding the same code
> > repeatedly all over the place.
> 
> Fair enough. It becomes tedious and just duplicating code. I agree.
> 
> So I will keep the v2 I just sent and remove the annoying error messages
> from of-thermal.c while registering the sensors.
> 
> > 
> > Also, each sensor instance will still result in an error if there
> > is no global "thermal-zones" entry. Checking for that global entry
> > in each driver would be even more excessive, and I just don't like
> > that noisyness.
> > 
> > Also, I think you'll need to create devicetree bindings documents
> > for the two sensors.
> > 
> 
> Why would I? There is only one extra property and that is already
> documented. I think the sensor still falls into the dummy dt node.
> 
I'll leave that up to the devicetree folks to decide.

Guenter

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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Wed, Sep 18, 2013 at 11:54:18AM -0400, Eduardo Valentin wrote:
> On 18-09-2013 11:17, Guenter Roeck wrote:
> > On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
> >> On 18-09-2013 07:18, Guenter Roeck wrote:
> >>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
> >>>> On 15-09-2013 19:33, Guenter Roeck wrote:
> >>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> >>>>>> 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: Guenter Roeck
> >>>>>> <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Cc:
> >>>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Eduardo Valentin
> >>>>>> <eduardo.valentin-l0cyMroinI0@public.gmane.org> --- drivers/hwmon/tmp102.c | 28
> >>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
> >>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
> >>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
> >>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
> >>>>>
> >>>>> Please drop this warning.
> >>>>>
> >>>>
> >>>> Done for both drivers.
> >>>>
> >>>>> Guenter
> >>>>>
> >>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
> >>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
> >>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
> >>>>>> dev_warn(&client->dev, +             "Could not parse thermal
> >>>>>> data in device tree: %ld\n", +
> >>>>>> PTR_ERR(tmp102->tz));
> >>>>>
> >>>>> Please drop this warning. You already create error messages in 
> >>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
> >>>>> same applies to the lm75 patch.
> >>>>
> >>>> OK. Done for both.
> >>>>
> >>>>>
> >>>>> As a side note, I would suggest to provide devm_ functions for 
> >>>>> registration. We are introducing those for hwmon registration,
> >>>>> which enables us to remove most _remove functions. It would be
> >>>>> great if we can keep it that way.
> >>>>>
> >>>>
> >>>> Right. This side note is taken. Actually this is on my todo list
> >>>> for quite a while. But I believe this should not block this series,
> >>>> should it? I will be probably cleaning the thermal framework code
> >>>> after this current work is accepted at least.
> >>>>
> >>>>> On a higher level, I don't think it is a good idea to make
> >>>>> thermal zones and thermal zone data mandatory. Many systems may
> >>>>> neither need nor want it.
> >>>>>
> >>>>
> >>>> Well, I agree with you. Did you see something hard required in the
> >>>> patch I sent. I made it so that it could continue the driver probe
> >>>> without thermal zones, as you requested.
> >>>>
> >>> If it is not mandatory you should not dump an error message to the
> >>> console in the thermal registration function. Since you do, you at
> >>> least consider it mandatory if that function is called.
> >>>
> >>> So please either drop the error message from the registration
> >>> function or add a check into the drivers to only register into the
> >>> thermal subsystem if there is a respective thermal entry for that
> >>> sensor in the devicetree data.
> >>>
> >>> There are systes out there with literally dozens of temperature
> >>> sensors. In many cases, those are purely for system health
> >>> monitoring, not for thermal management. I don't want to end up in a
> >>> situation where users complain about dozens of error messages on the
> >>> console and no way to avoid it but providing dummy thermal subsystem
> >>> data.
> >>>
> >>
> >> Now I see.
> >>
> >>
> >> Then I will rollback to the previous version in which lm sensors were
> >> first probing for thermal properties within their dt node. Something like:
> >> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> >> index dc96598..cb1c663 100644
> >> --- a/drivers/hwmon/tmp102.c
> >> +++ b/drivers/hwmon/tmp102.c
> >> @@ -216,11 +216,13 @@ 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;
> >> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
> >> +               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");
> >>
> >>
> >> Does it sound reasonable?
> >>
> > Personally I would prefer if the registration code fails silently.
> > Pushing the above code into each driver is just adding the same code
> > repeatedly all over the place.
> 
> Fair enough. It becomes tedious and just duplicating code. I agree.
> 
> So I will keep the v2 I just sent and remove the annoying error messages
> from of-thermal.c while registering the sensors.
> 
> > 
> > Also, each sensor instance will still result in an error if there
> > is no global "thermal-zones" entry. Checking for that global entry
> > in each driver would be even more excessive, and I just don't like
> > that noisyness.
> > 
> > Also, I think you'll need to create devicetree bindings documents
> > for the two sensors.
> > 
> 
> Why would I? There is only one extra property and that is already
> documented. I think the sensor still falls into the dummy dt node.
> 
I'll leave that up to the devicetree folks to decide.

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

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 11:57, Guenter Roeck wrote:
> On Wed, Sep 18, 2013 at 11:54:18AM -0400, Eduardo Valentin wrote:
>> On 18-09-2013 11:17, Guenter Roeck wrote:
>>> On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
>>>> On 18-09-2013 07:18, Guenter Roeck wrote:
>>>>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
>>>>>> On 15-09-2013 19:33, Guenter Roeck wrote:
>>>>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>>>>>>>> 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: Guenter Roeck
>>>>>>>> <linux@roeck-us.net> Cc: lm-sensors@lm-sensors.org Cc:
>>>>>>>> linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin
>>>>>>>> <eduardo.valentin@ti.com> --- drivers/hwmon/tmp102.c | 28
>>>>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
>>>>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
>>>>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
>>>>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
>>>>>>>
>>>>>>> Please drop this warning.
>>>>>>>
>>>>>>
>>>>>> Done for both drivers.
>>>>>>
>>>>>>> Guenter
>>>>>>>
>>>>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
>>>>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
>>>>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
>>>>>>>> dev_warn(&client->dev, +             "Could not parse thermal
>>>>>>>> data in device tree: %ld\n", +
>>>>>>>> PTR_ERR(tmp102->tz));
>>>>>>>
>>>>>>> Please drop this warning. You already create error messages in 
>>>>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
>>>>>>> same applies to the lm75 patch.
>>>>>>
>>>>>> OK. Done for both.
>>>>>>
>>>>>>>
>>>>>>> As a side note, I would suggest to provide devm_ functions for 
>>>>>>> registration. We are introducing those for hwmon registration,
>>>>>>> which enables us to remove most _remove functions. It would be
>>>>>>> great if we can keep it that way.
>>>>>>>
>>>>>>
>>>>>> Right. This side note is taken. Actually this is on my todo list
>>>>>> for quite a while. But I believe this should not block this series,
>>>>>> should it? I will be probably cleaning the thermal framework code
>>>>>> after this current work is accepted at least.
>>>>>>
>>>>>>> On a higher level, I don't think it is a good idea to make
>>>>>>> thermal zones and thermal zone data mandatory. Many systems may
>>>>>>> neither need nor want it.
>>>>>>>
>>>>>>
>>>>>> Well, I agree with you. Did you see something hard required in the
>>>>>> patch I sent. I made it so that it could continue the driver probe
>>>>>> without thermal zones, as you requested.
>>>>>>
>>>>> If it is not mandatory you should not dump an error message to the
>>>>> console in the thermal registration function. Since you do, you at
>>>>> least consider it mandatory if that function is called.
>>>>>
>>>>> So please either drop the error message from the registration
>>>>> function or add a check into the drivers to only register into the
>>>>> thermal subsystem if there is a respective thermal entry for that
>>>>> sensor in the devicetree data.
>>>>>
>>>>> There are systes out there with literally dozens of temperature
>>>>> sensors. In many cases, those are purely for system health
>>>>> monitoring, not for thermal management. I don't want to end up in a
>>>>> situation where users complain about dozens of error messages on the
>>>>> console and no way to avoid it but providing dummy thermal subsystem
>>>>> data.
>>>>>
>>>>
>>>> Now I see.
>>>>
>>>>
>>>> Then I will rollback to the previous version in which lm sensors were
>>>> first probing for thermal properties within their dt node. Something like:
>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>>>> index dc96598..cb1c663 100644
>>>> --- a/drivers/hwmon/tmp102.c
>>>> +++ b/drivers/hwmon/tmp102.c
>>>> @@ -216,11 +216,13 @@ 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;
>>>> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
>>>> +               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");
>>>>
>>>>
>>>> Does it sound reasonable?
>>>>
>>> Personally I would prefer if the registration code fails silently.
>>> Pushing the above code into each driver is just adding the same code
>>> repeatedly all over the place.
>>
>> Fair enough. It becomes tedious and just duplicating code. I agree.
>>
>> So I will keep the v2 I just sent and remove the annoying error messages
>> from of-thermal.c while registering the sensors.
>>
>>>
>>> Also, each sensor instance will still result in an error if there
>>> is no global "thermal-zones" entry. Checking for that global entry
>>> in each driver would be even more excessive, and I just don't like
>>> that noisyness.
>>>
>>> Also, I think you'll need to create devicetree bindings documents
>>> for the two sensors.
>>>
>>
>> Why would I? There is only one extra property and that is already
>> documented. I think the sensor still falls into the dummy dt node.
>>
> I'll leave that up to the devicetree folks to decide.

OK. Fair enough. Let s see what they have to say. Mark, Pawel, Stephen?

Guenter, any other objections a part from those I already fixed?

> 
> Guenter
> 
> 


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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 11:57, Guenter Roeck wrote:
> On Wed, Sep 18, 2013 at 11:54:18AM -0400, Eduardo Valentin wrote:
>> On 18-09-2013 11:17, Guenter Roeck wrote:
>>> On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
>>>> On 18-09-2013 07:18, Guenter Roeck wrote:
>>>>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
>>>>>> On 15-09-2013 19:33, Guenter Roeck wrote:
>>>>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>>>>>>>> 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: Guenter Roeck
>>>>>>>> <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Cc:
>>>>>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Eduardo Valentin
>>>>>>>> <eduardo.valentin-l0cyMroinI0@public.gmane.org> --- drivers/hwmon/tmp102.c | 28
>>>>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
>>>>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
>>>>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
>>>>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
>>>>>>>
>>>>>>> Please drop this warning.
>>>>>>>
>>>>>>
>>>>>> Done for both drivers.
>>>>>>
>>>>>>> Guenter
>>>>>>>
>>>>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
>>>>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
>>>>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
>>>>>>>> dev_warn(&client->dev, +             "Could not parse thermal
>>>>>>>> data in device tree: %ld\n", +
>>>>>>>> PTR_ERR(tmp102->tz));
>>>>>>>
>>>>>>> Please drop this warning. You already create error messages in 
>>>>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
>>>>>>> same applies to the lm75 patch.
>>>>>>
>>>>>> OK. Done for both.
>>>>>>
>>>>>>>
>>>>>>> As a side note, I would suggest to provide devm_ functions for 
>>>>>>> registration. We are introducing those for hwmon registration,
>>>>>>> which enables us to remove most _remove functions. It would be
>>>>>>> great if we can keep it that way.
>>>>>>>
>>>>>>
>>>>>> Right. This side note is taken. Actually this is on my todo list
>>>>>> for quite a while. But I believe this should not block this series,
>>>>>> should it? I will be probably cleaning the thermal framework code
>>>>>> after this current work is accepted at least.
>>>>>>
>>>>>>> On a higher level, I don't think it is a good idea to make
>>>>>>> thermal zones and thermal zone data mandatory. Many systems may
>>>>>>> neither need nor want it.
>>>>>>>
>>>>>>
>>>>>> Well, I agree with you. Did you see something hard required in the
>>>>>> patch I sent. I made it so that it could continue the driver probe
>>>>>> without thermal zones, as you requested.
>>>>>>
>>>>> If it is not mandatory you should not dump an error message to the
>>>>> console in the thermal registration function. Since you do, you at
>>>>> least consider it mandatory if that function is called.
>>>>>
>>>>> So please either drop the error message from the registration
>>>>> function or add a check into the drivers to only register into the
>>>>> thermal subsystem if there is a respective thermal entry for that
>>>>> sensor in the devicetree data.
>>>>>
>>>>> There are systes out there with literally dozens of temperature
>>>>> sensors. In many cases, those are purely for system health
>>>>> monitoring, not for thermal management. I don't want to end up in a
>>>>> situation where users complain about dozens of error messages on the
>>>>> console and no way to avoid it but providing dummy thermal subsystem
>>>>> data.
>>>>>
>>>>
>>>> Now I see.
>>>>
>>>>
>>>> Then I will rollback to the previous version in which lm sensors were
>>>> first probing for thermal properties within their dt node. Something like:
>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>>>> index dc96598..cb1c663 100644
>>>> --- a/drivers/hwmon/tmp102.c
>>>> +++ b/drivers/hwmon/tmp102.c
>>>> @@ -216,11 +216,13 @@ 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;
>>>> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
>>>> +               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");
>>>>
>>>>
>>>> Does it sound reasonable?
>>>>
>>> Personally I would prefer if the registration code fails silently.
>>> Pushing the above code into each driver is just adding the same code
>>> repeatedly all over the place.
>>
>> Fair enough. It becomes tedious and just duplicating code. I agree.
>>
>> So I will keep the v2 I just sent and remove the annoying error messages
>> from of-thermal.c while registering the sensors.
>>
>>>
>>> Also, each sensor instance will still result in an error if there
>>> is no global "thermal-zones" entry. Checking for that global entry
>>> in each driver would be even more excessive, and I just don't like
>>> that noisyness.
>>>
>>> Also, I think you'll need to create devicetree bindings documents
>>> for the two sensors.
>>>
>>
>> Why would I? There is only one extra property and that is already
>> documented. I think the sensor still falls into the dummy dt node.
>>
> I'll leave that up to the devicetree folks to decide.

OK. Fair enough. Let s see what they have to say. Mark, Pawel, Stephen?

Guenter, any other objections a part from those I already fixed?

> 
> Guenter
> 
> 


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

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Wed, Sep 18, 2013 at 12:23:31PM -0400, Eduardo Valentin wrote:
> On 18-09-2013 11:57, Guenter Roeck wrote:
> > On Wed, Sep 18, 2013 at 11:54:18AM -0400, Eduardo Valentin wrote:
> >> On 18-09-2013 11:17, Guenter Roeck wrote:
> >>> On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
> >>>> On 18-09-2013 07:18, Guenter Roeck wrote:
> >>>>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
> >>>>>> On 15-09-2013 19:33, Guenter Roeck wrote:
> >>>>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> >>>>>>>> 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: Guenter Roeck
> >>>>>>>> <linux@roeck-us.net> Cc: lm-sensors@lm-sensors.org Cc:
> >>>>>>>> linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin
> >>>>>>>> <eduardo.valentin@ti.com> --- drivers/hwmon/tmp102.c | 28
> >>>>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
> >>>>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
> >>>>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
> >>>>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
> >>>>>>>
> >>>>>>> Please drop this warning.
> >>>>>>>
> >>>>>>
> >>>>>> Done for both drivers.
> >>>>>>
> >>>>>>> Guenter
> >>>>>>>
> >>>>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
> >>>>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
> >>>>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
> >>>>>>>> dev_warn(&client->dev, +             "Could not parse thermal
> >>>>>>>> data in device tree: %ld\n", +
> >>>>>>>> PTR_ERR(tmp102->tz));
> >>>>>>>
> >>>>>>> Please drop this warning. You already create error messages in 
> >>>>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
> >>>>>>> same applies to the lm75 patch.
> >>>>>>
> >>>>>> OK. Done for both.
> >>>>>>
> >>>>>>>
> >>>>>>> As a side note, I would suggest to provide devm_ functions for 
> >>>>>>> registration. We are introducing those for hwmon registration,
> >>>>>>> which enables us to remove most _remove functions. It would be
> >>>>>>> great if we can keep it that way.
> >>>>>>>
> >>>>>>
> >>>>>> Right. This side note is taken. Actually this is on my todo list
> >>>>>> for quite a while. But I believe this should not block this series,
> >>>>>> should it? I will be probably cleaning the thermal framework code
> >>>>>> after this current work is accepted at least.
> >>>>>>
> >>>>>>> On a higher level, I don't think it is a good idea to make
> >>>>>>> thermal zones and thermal zone data mandatory. Many systems may
> >>>>>>> neither need nor want it.
> >>>>>>>
> >>>>>>
> >>>>>> Well, I agree with you. Did you see something hard required in the
> >>>>>> patch I sent. I made it so that it could continue the driver probe
> >>>>>> without thermal zones, as you requested.
> >>>>>>
> >>>>> If it is not mandatory you should not dump an error message to the
> >>>>> console in the thermal registration function. Since you do, you at
> >>>>> least consider it mandatory if that function is called.
> >>>>>
> >>>>> So please either drop the error message from the registration
> >>>>> function or add a check into the drivers to only register into the
> >>>>> thermal subsystem if there is a respective thermal entry for that
> >>>>> sensor in the devicetree data.
> >>>>>
> >>>>> There are systes out there with literally dozens of temperature
> >>>>> sensors. In many cases, those are purely for system health
> >>>>> monitoring, not for thermal management. I don't want to end up in a
> >>>>> situation where users complain about dozens of error messages on the
> >>>>> console and no way to avoid it but providing dummy thermal subsystem
> >>>>> data.
> >>>>>
> >>>>
> >>>> Now I see.
> >>>>
> >>>>
> >>>> Then I will rollback to the previous version in which lm sensors were
> >>>> first probing for thermal properties within their dt node. Something like:
> >>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> >>>> index dc96598..cb1c663 100644
> >>>> --- a/drivers/hwmon/tmp102.c
> >>>> +++ b/drivers/hwmon/tmp102.c
> >>>> @@ -216,11 +216,13 @@ 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;
> >>>> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
> >>>> +               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");
> >>>>
> >>>>
> >>>> Does it sound reasonable?
> >>>>
> >>> Personally I would prefer if the registration code fails silently.
> >>> Pushing the above code into each driver is just adding the same code
> >>> repeatedly all over the place.
> >>
> >> Fair enough. It becomes tedious and just duplicating code. I agree.
> >>
> >> So I will keep the v2 I just sent and remove the annoying error messages
> >> from of-thermal.c while registering the sensors.
> >>
> >>>
> >>> Also, each sensor instance will still result in an error if there
> >>> is no global "thermal-zones" entry. Checking for that global entry
> >>> in each driver would be even more excessive, and I just don't like
> >>> that noisyness.
> >>>
> >>> Also, I think you'll need to create devicetree bindings documents
> >>> for the two sensors.
> >>>
> >>
> >> Why would I? There is only one extra property and that is already
> >> documented. I think the sensor still falls into the dummy dt node.
> >>
> > I'll leave that up to the devicetree folks to decide.
> 
> OK. Fair enough. Let s see what they have to say. Mark, Pawel, Stephen?
> 
> Guenter, any other objections a part from those I already fixed?
> 
Not in the drivers, except that I am quite sure that the unregister call
will cause a NULL pointer access if the passed thermal zone is NULL.
I'll comment on that separetely in the related patch.

Guenter

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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Wed, Sep 18, 2013 at 12:23:31PM -0400, Eduardo Valentin wrote:
> On 18-09-2013 11:57, Guenter Roeck wrote:
> > On Wed, Sep 18, 2013 at 11:54:18AM -0400, Eduardo Valentin wrote:
> >> On 18-09-2013 11:17, Guenter Roeck wrote:
> >>> On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
> >>>> On 18-09-2013 07:18, Guenter Roeck wrote:
> >>>>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
> >>>>>> On 15-09-2013 19:33, Guenter Roeck wrote:
> >>>>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> >>>>>>>> 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: Guenter Roeck
> >>>>>>>> <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Cc:
> >>>>>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Eduardo Valentin
> >>>>>>>> <eduardo.valentin-l0cyMroinI0@public.gmane.org> --- drivers/hwmon/tmp102.c | 28
> >>>>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
> >>>>>>>> index d7b47ab..e432444 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,19 @@ 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)); + +    if
> >>>>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
> >>>>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
> >>>>>>>
> >>>>>>> Please drop this warning.
> >>>>>>>
> >>>>>>
> >>>>>> Done for both drivers.
> >>>>>>
> >>>>>>> Guenter
> >>>>>>>
> >>>>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
> >>>>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
> >>>>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ 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)) { +
> >>>>>>>> dev_warn(&client->dev, +             "Could not parse thermal
> >>>>>>>> data in device tree: %ld\n", +
> >>>>>>>> PTR_ERR(tmp102->tz));
> >>>>>>>
> >>>>>>> Please drop this warning. You already create error messages in 
> >>>>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
> >>>>>>> same applies to the lm75 patch.
> >>>>>>
> >>>>>> OK. Done for both.
> >>>>>>
> >>>>>>>
> >>>>>>> As a side note, I would suggest to provide devm_ functions for 
> >>>>>>> registration. We are introducing those for hwmon registration,
> >>>>>>> which enables us to remove most _remove functions. It would be
> >>>>>>> great if we can keep it that way.
> >>>>>>>
> >>>>>>
> >>>>>> Right. This side note is taken. Actually this is on my todo list
> >>>>>> for quite a while. But I believe this should not block this series,
> >>>>>> should it? I will be probably cleaning the thermal framework code
> >>>>>> after this current work is accepted at least.
> >>>>>>
> >>>>>>> On a higher level, I don't think it is a good idea to make
> >>>>>>> thermal zones and thermal zone data mandatory. Many systems may
> >>>>>>> neither need nor want it.
> >>>>>>>
> >>>>>>
> >>>>>> Well, I agree with you. Did you see something hard required in the
> >>>>>> patch I sent. I made it so that it could continue the driver probe
> >>>>>> without thermal zones, as you requested.
> >>>>>>
> >>>>> If it is not mandatory you should not dump an error message to the
> >>>>> console in the thermal registration function. Since you do, you at
> >>>>> least consider it mandatory if that function is called.
> >>>>>
> >>>>> So please either drop the error message from the registration
> >>>>> function or add a check into the drivers to only register into the
> >>>>> thermal subsystem if there is a respective thermal entry for that
> >>>>> sensor in the devicetree data.
> >>>>>
> >>>>> There are systes out there with literally dozens of temperature
> >>>>> sensors. In many cases, those are purely for system health
> >>>>> monitoring, not for thermal management. I don't want to end up in a
> >>>>> situation where users complain about dozens of error messages on the
> >>>>> console and no way to avoid it but providing dummy thermal subsystem
> >>>>> data.
> >>>>>
> >>>>
> >>>> Now I see.
> >>>>
> >>>>
> >>>> Then I will rollback to the previous version in which lm sensors were
> >>>> first probing for thermal properties within their dt node. Something like:
> >>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> >>>> index dc96598..cb1c663 100644
> >>>> --- a/drivers/hwmon/tmp102.c
> >>>> +++ b/drivers/hwmon/tmp102.c
> >>>> @@ -216,11 +216,13 @@ 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;
> >>>> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
> >>>> +               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");
> >>>>
> >>>>
> >>>> Does it sound reasonable?
> >>>>
> >>> Personally I would prefer if the registration code fails silently.
> >>> Pushing the above code into each driver is just adding the same code
> >>> repeatedly all over the place.
> >>
> >> Fair enough. It becomes tedious and just duplicating code. I agree.
> >>
> >> So I will keep the v2 I just sent and remove the annoying error messages
> >> from of-thermal.c while registering the sensors.
> >>
> >>>
> >>> Also, each sensor instance will still result in an error if there
> >>> is no global "thermal-zones" entry. Checking for that global entry
> >>> in each driver would be even more excessive, and I just don't like
> >>> that noisyness.
> >>>
> >>> Also, I think you'll need to create devicetree bindings documents
> >>> for the two sensors.
> >>>
> >>
> >> Why would I? There is only one extra property and that is already
> >> documented. I think the sensor still falls into the dummy dt node.
> >>
> > I'll leave that up to the devicetree folks to decide.
> 
> OK. Fair enough. Let s see what they have to say. Mark, Pawel, Stephen?
> 
> Guenter, any other objections a part from those I already fixed?
> 
Not in the drivers, except that I am quite sure that the unregister call
will cause a NULL pointer access if the passed thermal zone is NULL.
I'll comment on that separetely in the related patch.

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

[PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

---

Guenter,

Here is a version without the warnings, as requested.

Eduardo

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

[PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

---

Guenter,

Here is a version without the warnings, as requested.

Eduardo

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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] [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

---

Guenter,

Here is a version without the warnings, as requested.

Eduardo

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
 {
 	struct tmp102 *tmp102 = i2c_get_clientdata(client);
 
+	/* thermal zone life cycle is not our responsibility */
+	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

Re: [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Tue, Sep 17, 2013 at 06:34:05PM -0400, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
> ---
>  drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> ---
> 
> Guenter,
> 
> Here is a version without the warnings, as requested.
> 
> Eduardo
> 
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
>  {
>  	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>  
> +	/* thermal zone life cycle is not our responsibility */

This comment does not provide any value. Please drop it from both drivers.
Sorry I missed that earlier.

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

Re: [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Tue, Sep 17, 2013 at 06:34:05PM -0400, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> ---
> 
> Guenter,
> 
> Here is a version without the warnings, as requested.
> 
> Eduardo
> 
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
>  {
>  	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>  
> +	/* thermal zone life cycle is not our responsibility */

This comment does not provide any value. Please drop it from both drivers.
Sorry I missed that earlier.

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

Re: [lm-sensors] [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On Tue, Sep 17, 2013 at 06:34:05PM -0400, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> ---
> 
> Guenter,
> 
> Here is a version without the warnings, as requested.
> 
> Eduardo
> 
> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
>  {
>  	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>  
> +	/* thermal zone life cycle is not our responsibility */

This comment does not provide any value. Please drop it from both drivers.
Sorry I missed that earlier.

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

Re: [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 07:06, Guenter Roeck wrote:
> On Tue, Sep 17, 2013 at 06:34:05PM -0400, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> ---
>>
>> Guenter,
>>
>> Here is a version without the warnings, as requested.
>>
>> Eduardo
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
>>  {
>>  	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>  
>> +	/* thermal zone life cycle is not our responsibility */
> 
> This comment does not provide any value. Please drop it from both drivers.
> Sorry I missed that earlier.

Yeah, I even forgot to drop it myself. No problem, I am resending both
without it.

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


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

Re: [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 07:06, Guenter Roeck wrote:
> On Tue, Sep 17, 2013 at 06:34:05PM -0400, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux@roeck-us.net>
>> Cc: lm-sensors@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>  drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> ---
>>
>> Guenter,
>>
>> Here is a version without the warnings, as requested.
>>
>> Eduardo
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
>>  {
>>  	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>  
>> +	/* thermal zone life cycle is not our responsibility */
> 
> This comment does not provide any value. Please drop it from both drivers.
> Sorry I missed that earlier.

Yeah, I even forgot to drop it myself. No problem, I am resending both
without it.

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


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

Re: [lm-sensors] [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

On 18-09-2013 07:06, Guenter Roeck wrote:
> On Tue, Sep 17, 2013 at 06:34:05PM -0400, Eduardo Valentin wrote:
>> 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: Guenter Roeck <linux@roeck-us.net>
>> Cc: lm-sensors@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>  drivers/hwmon/tmp102.c | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> ---
>>
>> Guenter,
>>
>> Here is a version without the warnings, as requested.
>>
>> Eduardo
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..dc96598 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,8 @@ static int tmp102_remove(struct i2c_client *client)
>>  {
>>  	struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>  
>> +	/* thermal zone life cycle is not our responsibility */
> 
> This comment does not provide any value. Please drop it from both drivers.
> Sorry I missed that earlier.

Yeah, I even forgot to drop it myself. No problem, I am resending both
without it.

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


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

[PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

Very minor change, removing comment, as requested.

Eduardo

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

[PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

Very minor change, removing comment, as requested.

Eduardo

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] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

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

Very minor change, removing comment, as requested.

Eduardo

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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/18/2013 09:23 AM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>

Acked-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>


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

Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/18/2013 09:23 AM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

Re: [lm-sensors] [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Guenter Roeck]

On 09/18/2013 09:23 AM, Eduardo Valentin wrote:
> 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: Guenter Roeck <linux@roeck-us.net>
> Cc: lm-sensors@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>



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

[PATCH 01/16] drivers: thermal: allow registering without .get_temp

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

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

[PATCH 01/16] drivers: thermal: allow registering without .get_temp

[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] [PATCH 01/16] drivers: thermal: allow registering without .get_temp

[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

[PATCH 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 763 +++++++++++++++++++++
 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, 1345 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..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..a6dde56
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,763 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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)) {
+		pr_err("zone not yet registered %s\n", zone->name);
+		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) {
+		dev_err(dev, "unable to find thermal zones\n");
+		return ERR_PTR(-ENODEV);
+	}
+
+	if (!dev || !dev->of_node) {
+		dev_err(dev, "invalid device struct\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret) {
+			dev_err(dev, "zone without sensors\n");
+			continue;
+		}
+
+		if (sensor_specs.args_count < 1) {
+			dev_err(dev, "must contain at least 1 parameter\n");
+			continue;
+		}
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

[PATCH 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 763 +++++++++++++++++++++
 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, 1345 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..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..a6dde56
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,763 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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)) {
+		pr_err("zone not yet registered %s\n", zone->name);
+		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) {
+		dev_err(dev, "unable to find thermal zones\n");
+		return ERR_PTR(-ENODEV);
+	}
+
+	if (!dev || !dev->of_node) {
+		dev_err(dev, "invalid device struct\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret) {
+			dev_err(dev, "zone without sensors\n");
+			continue;
+		}
+
+		if (sensor_specs.args_count < 1) {
+			dev_err(dev, "must contain at least 1 parameter\n");
+			continue;
+		}
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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] [PATCH 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 763 +++++++++++++++++++++
 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, 1345 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..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..a6dde56
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,763 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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)) {
+		pr_err("zone not yet registered %s\n", zone->name);
+		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) {
+		dev_err(dev, "unable to find thermal zones\n");
+		return ERR_PTR(-ENODEV);
+	}
+
+	if (!dev || !dev->of_node) {
+		dev_err(dev, "invalid device struct\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	sensor_np = dev->of_node;
+
+	for_each_child_of_node(np, child) {
+		struct of_phandle_args sensor_specs;
+		int ret;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret) {
+			dev_err(dev, "zone without sensors\n");
+			continue;
+		}
+
+		if (sensor_specs.args_count < 1) {
+			dev_err(dev, "must contain at least 1 parameter\n");
+			continue;
+		}
+
+		if (sensor_specs.np = sensor_np &&
+		    sensor_specs.args[0] = 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 = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

[PATCHv2 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
 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, 1335 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
---

Hi all,

As per Guenter's request, I changed this code to fail silently while
registering sensor drivers.

Cheers,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..857d40c
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,753 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

[PATCHv2 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
 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, 1335 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
---

Hi all,

As per Guenter's request, I changed this code to fail silently while
registering sensor drivers.

Cheers,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..857d40c
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,753 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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] [PATCHv2 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
 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, 1335 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
---

Hi all,

As per Guenter's request, I changed this code to fail silently while
registering sensor drivers.

Cheers,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..857d40c
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,753 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np = sensor_np &&
+		    sensor_specs.args[0] = 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 = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

Re: [PATCHv2 02/16] drivers: thermal: introduce device tree parser

[Guenter Roeck]

On Wed, Sep 18, 2013 at 12:03:09PM -0400, 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>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
>  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, 1335 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
> ---
> 
> Hi all,
> 
> As per Guenter's request, I changed this code to fail silently while
> registering sensor drivers.
> 
> Cheers,
> 
> Eduardo
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..6664533
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,498 @@
> +* 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 attachments: 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.
> +
> +* Sensor devices
> +
> +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. Temperature sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #sensor-cells:	Used to provide sensor device specific information
> +			while referring to it. Must be at least 1, 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. 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 level of cooling.
> +
> +Required property:
> +- cooling-min-level:	A unsigned integer indicating the smallest
> +			cooling level accepted. Typically 0.
> +- cooling-max-level:	An unsigned integer indicating the largest
> +			cooling level accepted.
> +- #cooling-cells:	Used to provide cooling device specific information
> +			while referring to it. Must be at least 2, in order
> +			to specify minimum and maximum cooling level used
> +			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
> +- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
> +			relative value, in milliCelsius.
> +- type:			the trip type. Here is the type mapping:
> +	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
> +	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
> +	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
> +	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
> +
> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
> +
> +* Cooling device attachments
> +
> +The cooling device attachments 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 parameters,
> +			referring to which cooling device is used in this
> +			binding. The required parameters are: the minimum
> +			cooling level and the maximum cooling level used
> +			in this attach.
> +- trip:			A phandle of a trip point node within the same thermal
> +			zone.
> +
> +Optional property:
> +- contribution:		The cooling contribution to the thermal zone of the
> +			referred cooling device at the referred trip point.
> +			The contribution is a value from 0 to 100. The sum
> +			of all cooling contributions within a thermal zone
> +			must never exceed 100.
> +
> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
> +limit parameters means:
> +(i)   - minimum level allowed for minimum cooling level used in the reference.
> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> +
> +* Thermal zones
> +
> +The thermal-zone node is the node containing all the required info
> +for describing a thermal zone, including its cdev 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 attachments.
> +
> +Required properties:
> +- passive-delay:	The maximum number of milliseconds to wait between polls
> +			when performing passive cooling.
> +- polling-delay:	The maximum number of milliseconds to wait between polls
> +			when checking this thermal zone.
> +- sensors:		A list of sensor phandles and their parameters. The
> +			required parameter is the sensor id, in order to
> +			identify internal sensors when the sensor IC features
> +			several sensing units.
> +- trips:		A sub-node containing several trip point nodes required
> +			to describe the thermal zone.
> +- cooling-attachments	A sub-node containing several cooling device attaches
> +			nodes, used to describe the relation between trips
> +			and cooling devices.
> +
> +Optional property:
> +- coefficients:		An array of integers (one signed cell) containing
> +			coefficients to compose a linear relation between
> +			the sensors described in the sensors property.
> +			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 (passive-delay); 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.
> +
> +* 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-level = <0>;
> +		cooling-max-level = <3>;
> +		#cooling-cells = <2>; /* min followed by max */
> +	};
> +	...
> +};
> +
> +&i2c1 {
> +	...
> +	fan0: fan@0x48 {
> +		...
> +		cooling-min-level = <0>;
> +		cooling-max-level = <9>;
> +		#cooling-cells = <2>; /* min followed by max */
> +	};
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +	...
> +	#sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +	passive-delay = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        sensors = <&bandgap0     0>;
> +
> +        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-attachments {
> +		attach0 {
> +			trip = <&cpu-alert0>;
> +			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +		};
> +		attach1 {
> +			trip = <&cpu-alert1>;
> +			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +		};
> +		attach2 {
> +			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, is used to remove the heat out of the thermal
> +zone 'cpu-thermal' using its cooling levels 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 level.
> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
> +passive cooling device, using all its cooling levels 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 {
> +	...
> +	#sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +	passive-delay = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        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-attachments {
> +		/* each zone within the SoC may have its own cooling */
> +		...
> +	};
> +};
> +
> +gpu-thermal: gpu-thermal {
> +	passive-delay = <120>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        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-attachments {
> +		/* each zone within the SoC may have its own cooling */
> +		...
> +	};
> +};
> +
> +dsp-thermal: dsp-thermal {
> +	passive-delay = <50>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        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-attachments {
> +		/* 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
> +#sensor-cells property and using the first parameter 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 attachments.
> +
> +
> +(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 {
> +		...
> +		#sensor-cells = <1>;
> +	};
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +	...
> +	#sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +	passive-delay = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        sensors = <&bandgap0	0>,
> +		  <&adc		0>;
> +
> +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
> +	coefficients = 		<100	-120	484>;
> +
> +        trips {
> +		...
> +        };
> +
> +	cooling-attachments {
> +		...
> +	};
> +};
> +
> +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:
> +	passive-delay = <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 */
> +        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 {
> +		...
> +		#sensor-cells = <1>; /* sensor internal ID */
> +	};
> +};
> +
> +batt-thermal {
> +	passive-delay = <500>; /* milliseconds */
> +	polling-delay = <2500>; /* milliseconds */
> +
> +	/* sensor       ID */
> +	sensors = <&adc-dummy     4>;
> +
> +	trips {
> +		...
> +	};
> +
> +	cooling-attachments {
> +		...
> +	};
> +};
> +
> +board-thermal: board-thermal {
> +	passive-delay = <1000>; /* milliseconds */
> +	polling-delay = <2500>; /* milliseconds */
> +
> +		/* sensor       ID */
> +	sensors = <&adc-dummy     0>,
> +		  <&adc-dummy     1>,
> +		  <&adc-dymmy     2>;
> +			/*
> +			 * 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-attachments {
> +		attach0 {
> +			trip = <&cpu-trip>;
> +			cooling-device = <&cpu0 0 2>;
> +			contribution = <55>;
> +		};
> +		attach1 {
> +			trip = <&gpu-trip>;
> +			cooling-device = <&gpu0 0 2>;
> +			contribution = <20>;
> +		};
> +		attach2 {
> +			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..857d40c
> --- /dev/null
> +++ b/drivers/thermal/of-thermal.c
> @@ -0,0 +1,753 @@
> +/*
> + *  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>
> +
> +/***   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 level used at this trip point
> + * @max: maximum cooling level 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;
> +
> +	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;
> +
> +		/* For now, thermal framework supports only 1 sensor per zone */
> +		ret = of_parse_phandle_with_args(child, "sensors",
> +						 "#sensor-cells",
> +						 0, &sensor_specs);
> +		if (ret)
> +			continue;
> +
> +		if (sensor_specs.args_count < 1)
> +			continue;
> +
> +		if (sensor_specs.np == sensor_np &&
> +		    sensor_specs.args[0] == 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 = tzd->devdata;
> +

You might want to check for a NULL thermal zone device before dereferencing it.

Guenter

> +	/* 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 attachment data
> + * @np: DT node containing a cooling-attachment node
> + * @__tbp: data structure to be filled with cooling attachment info
> + * @trips: array of thermal zone trip points
> + * @ntrips: number of trip points inside trips.
> + *
> + * This function parses a cooling-attachment 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, "usage", &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;
> +}
> +
> +/**
> + * 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 = of_property_read_u32(np, "type", &prop);
> +	if (ret < 0) {
> +		pr_err("missing type property\n");
> +		return ret;
> +	}
> +	trip->type = prop;
> +
> +	/* Required for cooling attachment 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.
> + *
> + * 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, *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) {
> +		pr_err("not enough memory for thermal of zone\n");
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	ret = of_property_read_u32(np, "passive-delay", &prop);
> +	if (ret < 0) {
> +		pr_err("missing passive_delay property\n");
> +		return ERR_PTR(ret);
> +	}
> +	tz->passive_delay = prop;
> +
> +	ret = of_property_read_u32(np, "polling-delay", &prop);
> +	if (ret < 0) {
> +		pr_err("missing polling_delay property\n");
> +		return ERR_PTR(ret);
> +	}
> +	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);
> +	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
> +	if (!tz->trips)
> +		return ERR_PTR(-ENOMEM);
> +	i = 0;
> +	for_each_child_of_node(child, gchild)
> +		thermal_of_populate_trip(gchild, &tz->trips[i++]);
> +
> +	of_node_put(child);
> +
> +	/* cooling-attachments */
> +	child = of_get_child_by_name(np, "cooling-attachments");
> +
> +	/* cooling-attachments provided */
> +	if (!child)
> +		goto finish;
> +
> +	tz->num_tbps = of_get_child_count(child);
> +	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
> +	if (!tz->tbps)
> +		return ERR_PTR(-ENOMEM);
> +	i = 0;
> +	for_each_child_of_node(child, gchild)
> +		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
> +						tz->trips, tz->ntrips);
> +
> +finish:
> +	tz->mode = THERMAL_DEVICE_DISABLED;
> +
> +	return 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_err("unable to find thermal zones\n");
> +		return 0;
> +	}
> +
> +	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 %ld\n",
> +			       PTR_ERR(tz));
> +			return 0;
> +		}
> +
> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal ops\n");
> +			return 0;
> +		}
> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
> +
> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal zone params\n");
> +			return 0;
> +		}
> +		/* 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));
> +	}
> +	return 0;
> +}
> +
> +/**
> + * 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;
> +	struct __thermal_zone *tz;
> +
> +	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);
> +		tz = zone->devdata;
> +		kfree(tz->tbps);
> +		kfree(tz->trips);
> +		kfree(tz);
> +	}
> +}
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 8a94300..a733241 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..6dd6ccd
> --- /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		0
> +#define THERMAL_TRIP_PASSIVE		1
> +#define THERMAL_TRIP_HOT		2
> +#define THERMAL_TRIP_CRITICAL		3
> +
> +/* 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
> 
> 

Re: [lm-sensors] [PATCHv2 02/16] drivers: thermal: introduce device tree parser

[Guenter Roeck]

On Wed, Sep 18, 2013 at 12:03:09PM -0400, 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>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
>  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, 1335 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
> ---
> 
> Hi all,
> 
> As per Guenter's request, I changed this code to fail silently while
> registering sensor drivers.
> 
> Cheers,
> 
> Eduardo
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..6664533
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,498 @@
> +* 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 attachments: 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.
> +
> +* Sensor devices
> +
> +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. Temperature sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #sensor-cells:	Used to provide sensor device specific information
> +			while referring to it. Must be at least 1, 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. 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 level of cooling.
> +
> +Required property:
> +- cooling-min-level:	A unsigned integer indicating the smallest
> +			cooling level accepted. Typically 0.
> +- cooling-max-level:	An unsigned integer indicating the largest
> +			cooling level accepted.
> +- #cooling-cells:	Used to provide cooling device specific information
> +			while referring to it. Must be at least 2, in order
> +			to specify minimum and maximum cooling level used
> +			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
> +- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
> +			relative value, in milliCelsius.
> +- type:			the trip type. Here is the type mapping:
> +	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
> +	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
> +	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
> +	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
> +
> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
> +
> +* Cooling device attachments
> +
> +The cooling device attachments 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 parameters,
> +			referring to which cooling device is used in this
> +			binding. The required parameters are: the minimum
> +			cooling level and the maximum cooling level used
> +			in this attach.
> +- trip:			A phandle of a trip point node within the same thermal
> +			zone.
> +
> +Optional property:
> +- contribution:		The cooling contribution to the thermal zone of the
> +			referred cooling device at the referred trip point.
> +			The contribution is a value from 0 to 100. The sum
> +			of all cooling contributions within a thermal zone
> +			must never exceed 100.
> +
> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
> +limit parameters means:
> +(i)   - minimum level allowed for minimum cooling level used in the reference.
> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> +
> +* Thermal zones
> +
> +The thermal-zone node is the node containing all the required info
> +for describing a thermal zone, including its cdev 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 attachments.
> +
> +Required properties:
> +- passive-delay:	The maximum number of milliseconds to wait between polls
> +			when performing passive cooling.
> +- polling-delay:	The maximum number of milliseconds to wait between polls
> +			when checking this thermal zone.
> +- sensors:		A list of sensor phandles and their parameters. The
> +			required parameter is the sensor id, in order to
> +			identify internal sensors when the sensor IC features
> +			several sensing units.
> +- trips:		A sub-node containing several trip point nodes required
> +			to describe the thermal zone.
> +- cooling-attachments	A sub-node containing several cooling device attaches
> +			nodes, used to describe the relation between trips
> +			and cooling devices.
> +
> +Optional property:
> +- coefficients:		An array of integers (one signed cell) containing
> +			coefficients to compose a linear relation between
> +			the sensors described in the sensors property.
> +			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 (passive-delay); 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.
> +
> +* 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-level = <0>;
> +		cooling-max-level = <3>;
> +		#cooling-cells = <2>; /* min followed by max */
> +	};
> +	...
> +};
> +
> +&i2c1 {
> +	...
> +	fan0: fan@0x48 {
> +		...
> +		cooling-min-level = <0>;
> +		cooling-max-level = <9>;
> +		#cooling-cells = <2>; /* min followed by max */
> +	};
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +	...
> +	#sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +	passive-delay = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        sensors = <&bandgap0     0>;
> +
> +        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-attachments {
> +		attach0 {
> +			trip = <&cpu-alert0>;
> +			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +		};
> +		attach1 {
> +			trip = <&cpu-alert1>;
> +			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +		};
> +		attach2 {
> +			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, is used to remove the heat out of the thermal
> +zone 'cpu-thermal' using its cooling levels 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 level.
> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
> +passive cooling device, using all its cooling levels 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 {
> +	...
> +	#sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +	passive-delay = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        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-attachments {
> +		/* each zone within the SoC may have its own cooling */
> +		...
> +	};
> +};
> +
> +gpu-thermal: gpu-thermal {
> +	passive-delay = <120>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        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-attachments {
> +		/* each zone within the SoC may have its own cooling */
> +		...
> +	};
> +};
> +
> +dsp-thermal: dsp-thermal {
> +	passive-delay = <50>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        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-attachments {
> +		/* 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
> +#sensor-cells property and using the first parameter 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 attachments.
> +
> +
> +(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 {
> +		...
> +		#sensor-cells = <1>;
> +	};
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +	...
> +	#sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +	passive-delay = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +        sensors = <&bandgap0	0>,
> +		  <&adc		0>;
> +
> +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
> +	coefficients = 		<100	-120	484>;
> +
> +        trips {
> +		...
> +        };
> +
> +	cooling-attachments {
> +		...
> +	};
> +};
> +
> +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:
> +	passive-delay = <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 */
> +        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 {
> +		...
> +		#sensor-cells = <1>; /* sensor internal ID */
> +	};
> +};
> +
> +batt-thermal {
> +	passive-delay = <500>; /* milliseconds */
> +	polling-delay = <2500>; /* milliseconds */
> +
> +	/* sensor       ID */
> +	sensors = <&adc-dummy     4>;
> +
> +	trips {
> +		...
> +	};
> +
> +	cooling-attachments {
> +		...
> +	};
> +};
> +
> +board-thermal: board-thermal {
> +	passive-delay = <1000>; /* milliseconds */
> +	polling-delay = <2500>; /* milliseconds */
> +
> +		/* sensor       ID */
> +	sensors = <&adc-dummy     0>,
> +		  <&adc-dummy     1>,
> +		  <&adc-dymmy     2>;
> +			/*
> +			 * 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-attachments {
> +		attach0 {
> +			trip = <&cpu-trip>;
> +			cooling-device = <&cpu0 0 2>;
> +			contribution = <55>;
> +		};
> +		attach1 {
> +			trip = <&gpu-trip>;
> +			cooling-device = <&gpu0 0 2>;
> +			contribution = <20>;
> +		};
> +		attach2 {
> +			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..857d40c
> --- /dev/null
> +++ b/drivers/thermal/of-thermal.c
> @@ -0,0 +1,753 @@
> +/*
> + *  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>
> +
> +/***   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 level used at this trip point
> + * @max: maximum cooling level 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;
> +
> +	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;
> +
> +		/* For now, thermal framework supports only 1 sensor per zone */
> +		ret = of_parse_phandle_with_args(child, "sensors",
> +						 "#sensor-cells",
> +						 0, &sensor_specs);
> +		if (ret)
> +			continue;
> +
> +		if (sensor_specs.args_count < 1)
> +			continue;
> +
> +		if (sensor_specs.np = sensor_np &&
> +		    sensor_specs.args[0] = 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 = tzd->devdata;
> +

You might want to check for a NULL thermal zone device before dereferencing it.

Guenter

> +	/* 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 attachment data
> + * @np: DT node containing a cooling-attachment node
> + * @__tbp: data structure to be filled with cooling attachment info
> + * @trips: array of thermal zone trip points
> + * @ntrips: number of trip points inside trips.
> + *
> + * This function parses a cooling-attachment 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, "usage", &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;
> +}
> +
> +/**
> + * 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 = of_property_read_u32(np, "type", &prop);
> +	if (ret < 0) {
> +		pr_err("missing type property\n");
> +		return ret;
> +	}
> +	trip->type = prop;
> +
> +	/* Required for cooling attachment 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.
> + *
> + * 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, *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) {
> +		pr_err("not enough memory for thermal of zone\n");
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	ret = of_property_read_u32(np, "passive-delay", &prop);
> +	if (ret < 0) {
> +		pr_err("missing passive_delay property\n");
> +		return ERR_PTR(ret);
> +	}
> +	tz->passive_delay = prop;
> +
> +	ret = of_property_read_u32(np, "polling-delay", &prop);
> +	if (ret < 0) {
> +		pr_err("missing polling_delay property\n");
> +		return ERR_PTR(ret);
> +	}
> +	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);
> +	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
> +	if (!tz->trips)
> +		return ERR_PTR(-ENOMEM);
> +	i = 0;
> +	for_each_child_of_node(child, gchild)
> +		thermal_of_populate_trip(gchild, &tz->trips[i++]);
> +
> +	of_node_put(child);
> +
> +	/* cooling-attachments */
> +	child = of_get_child_by_name(np, "cooling-attachments");
> +
> +	/* cooling-attachments provided */
> +	if (!child)
> +		goto finish;
> +
> +	tz->num_tbps = of_get_child_count(child);
> +	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
> +	if (!tz->tbps)
> +		return ERR_PTR(-ENOMEM);
> +	i = 0;
> +	for_each_child_of_node(child, gchild)
> +		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
> +						tz->trips, tz->ntrips);
> +
> +finish:
> +	tz->mode = THERMAL_DEVICE_DISABLED;
> +
> +	return 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_err("unable to find thermal zones\n");
> +		return 0;
> +	}
> +
> +	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 %ld\n",
> +			       PTR_ERR(tz));
> +			return 0;
> +		}
> +
> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal ops\n");
> +			return 0;
> +		}
> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
> +
> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal zone params\n");
> +			return 0;
> +		}
> +		/* 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));
> +	}
> +	return 0;
> +}
> +
> +/**
> + * 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;
> +	struct __thermal_zone *tz;
> +
> +	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);
> +		tz = zone->devdata;
> +		kfree(tz->tbps);
> +		kfree(tz->trips);
> +		kfree(tz);
> +	}
> +}
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 8a94300..a733241 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..6dd6ccd
> --- /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		0
> +#define THERMAL_TRIP_PASSIVE		1
> +#define THERMAL_TRIP_HOT		2
> +#define THERMAL_TRIP_CRITICAL		3
> +
> +/* 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

Re: [PATCHv2 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 13:08, Guenter Roeck wrote:
> On Wed, Sep 18, 2013 at 12:03:09PM -0400, 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>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
>>  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, 1335 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
>> ---
>>
>> Hi all,
>>
>> As per Guenter's request, I changed this code to fail silently while
>> registering sensor drivers.
>>
>> Cheers,
>>
>> Eduardo
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..6664533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,498 @@
>> +* 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 attachments: 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.
>> +
>> +* Sensor devices
>> +
>> +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. Temperature sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #sensor-cells:	Used to provide sensor device specific information
>> +			while referring to it. Must be at least 1, 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. 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 level of cooling.
>> +
>> +Required property:
>> +- cooling-min-level:	A unsigned integer indicating the smallest
>> +			cooling level accepted. Typically 0.
>> +- cooling-max-level:	An unsigned integer indicating the largest
>> +			cooling level accepted.
>> +- #cooling-cells:	Used to provide cooling device specific information
>> +			while referring to it. Must be at least 2, in order
>> +			to specify minimum and maximum cooling level used
>> +			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
>> +- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
>> +			relative value, in milliCelsius.
>> +- type:			the trip type. Here is the type mapping:
>> +	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
>> +	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
>> +	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
>> +	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
>> +
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
>> +
>> +* Cooling device attachments
>> +
>> +The cooling device attachments 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 parameters,
>> +			referring to which cooling device is used in this
>> +			binding. The required parameters are: the minimum
>> +			cooling level and the maximum cooling level used
>> +			in this attach.
>> +- trip:			A phandle of a trip point node within the same thermal
>> +			zone.
>> +
>> +Optional property:
>> +- contribution:		The cooling contribution to the thermal zone of the
>> +			referred cooling device at the referred trip point.
>> +			The contribution is a value from 0 to 100. The sum
>> +			of all cooling contributions within a thermal zone
>> +			must never exceed 100.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit parameters means:
>> +(i)   - minimum level allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zones
>> +
>> +The thermal-zone node is the node containing all the required info
>> +for describing a thermal zone, including its cdev 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 attachments.
>> +
>> +Required properties:
>> +- passive-delay:	The maximum number of milliseconds to wait between polls
>> +			when performing passive cooling.
>> +- polling-delay:	The maximum number of milliseconds to wait between polls
>> +			when checking this thermal zone.
>> +- sensors:		A list of sensor phandles and their parameters. The
>> +			required parameter is the sensor id, in order to
>> +			identify internal sensors when the sensor IC features
>> +			several sensing units.
>> +- trips:		A sub-node containing several trip point nodes required
>> +			to describe the thermal zone.
>> +- cooling-attachments	A sub-node containing several cooling device attaches
>> +			nodes, used to describe the relation between trips
>> +			and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:		An array of integers (one signed cell) containing
>> +			coefficients to compose a linear relation between
>> +			the sensors described in the sensors property.
>> +			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 (passive-delay); 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.
>> +
>> +* 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-level = <0>;
>> +		cooling-max-level = <3>;
>> +		#cooling-cells = <2>; /* min followed by max */
>> +	};
>> +	...
>> +};
>> +
>> +&i2c1 {
>> +	...
>> +	fan0: fan@0x48 {
>> +		...
>> +		cooling-min-level = <0>;
>> +		cooling-max-level = <9>;
>> +		#cooling-cells = <2>; /* min followed by max */
>> +	};
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        sensors = <&bandgap0     0>;
>> +
>> +        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-attachments {
>> +		attach0 {
>> +			trip = <&cpu-alert0>;
>> +			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +		};
>> +		attach1 {
>> +			trip = <&cpu-alert1>;
>> +			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +		};
>> +		attach2 {
>> +			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, is used to remove the heat out of the thermal
>> +zone 'cpu-thermal' using its cooling levels 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 level.
>> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
>> +passive cooling device, using all its cooling levels 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 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* each zone within the SoC may have its own cooling */
>> +		...
>> +	};
>> +};
>> +
>> +gpu-thermal: gpu-thermal {
>> +	passive-delay = <120>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* each zone within the SoC may have its own cooling */
>> +		...
>> +	};
>> +};
>> +
>> +dsp-thermal: dsp-thermal {
>> +	passive-delay = <50>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* 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
>> +#sensor-cells property and using the first parameter 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 attachments.
>> +
>> +
>> +(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 {
>> +		...
>> +		#sensor-cells = <1>;
>> +	};
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        sensors = <&bandgap0	0>,
>> +		  <&adc		0>;
>> +
>> +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +	coefficients = 		<100	-120	484>;
>> +
>> +        trips {
>> +		...
>> +        };
>> +
>> +	cooling-attachments {
>> +		...
>> +	};
>> +};
>> +
>> +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:
>> +	passive-delay = <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 */
>> +        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 {
>> +		...
>> +		#sensor-cells = <1>; /* sensor internal ID */
>> +	};
>> +};
>> +
>> +batt-thermal {
>> +	passive-delay = <500>; /* milliseconds */
>> +	polling-delay = <2500>; /* milliseconds */
>> +
>> +	/* sensor       ID */
>> +	sensors = <&adc-dummy     4>;
>> +
>> +	trips {
>> +		...
>> +	};
>> +
>> +	cooling-attachments {
>> +		...
>> +	};
>> +};
>> +
>> +board-thermal: board-thermal {
>> +	passive-delay = <1000>; /* milliseconds */
>> +	polling-delay = <2500>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +	sensors = <&adc-dummy     0>,
>> +		  <&adc-dummy     1>,
>> +		  <&adc-dymmy     2>;
>> +			/*
>> +			 * 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-attachments {
>> +		attach0 {
>> +			trip = <&cpu-trip>;
>> +			cooling-device = <&cpu0 0 2>;
>> +			contribution = <55>;
>> +		};
>> +		attach1 {
>> +			trip = <&gpu-trip>;
>> +			cooling-device = <&gpu0 0 2>;
>> +			contribution = <20>;
>> +		};
>> +		attach2 {
>> +			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..857d40c
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,753 @@
>> +/*
>> + *  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>
>> +
>> +/***   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 level used at this trip point
>> + * @max: maximum cooling level 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;
>> +
>> +	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;
>> +
>> +		/* For now, thermal framework supports only 1 sensor per zone */
>> +		ret = of_parse_phandle_with_args(child, "sensors",
>> +						 "#sensor-cells",
>> +						 0, &sensor_specs);
>> +		if (ret)
>> +			continue;
>> +
>> +		if (sensor_specs.args_count < 1)
>> +			continue;
>> +
>> +		if (sensor_specs.np == sensor_np &&
>> +		    sensor_specs.args[0] == 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 = tzd->devdata;
>> +
> 
> You might want to check for a NULL thermal zone device before dereferencing it.

Good point Guenter, thanks for your time reviewing this code.

I am resending this patch only with this fix as its v3.

Eduardo

> 
> Guenter
> 
>> +	/* 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 attachment data
>> + * @np: DT node containing a cooling-attachment node
>> + * @__tbp: data structure to be filled with cooling attachment info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-attachment 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, "usage", &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;
>> +}
>> +
>> +/**
>> + * 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 = of_property_read_u32(np, "type", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing type property\n");
>> +		return ret;
>> +	}
>> +	trip->type = prop;
>> +
>> +	/* Required for cooling attachment 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.
>> + *
>> + * 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, *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) {
>> +		pr_err("not enough memory for thermal of zone\n");
>> +		return ERR_PTR(-ENOMEM);
>> +	}
>> +
>> +	ret = of_property_read_u32(np, "passive-delay", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing passive_delay property\n");
>> +		return ERR_PTR(ret);
>> +	}
>> +	tz->passive_delay = prop;
>> +
>> +	ret = of_property_read_u32(np, "polling-delay", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing polling_delay property\n");
>> +		return ERR_PTR(ret);
>> +	}
>> +	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);
>> +	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +	if (!tz->trips)
>> +		return ERR_PTR(-ENOMEM);
>> +	i = 0;
>> +	for_each_child_of_node(child, gchild)
>> +		thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +
>> +	of_node_put(child);
>> +
>> +	/* cooling-attachments */
>> +	child = of_get_child_by_name(np, "cooling-attachments");
>> +
>> +	/* cooling-attachments provided */
>> +	if (!child)
>> +		goto finish;
>> +
>> +	tz->num_tbps = of_get_child_count(child);
>> +	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +	if (!tz->tbps)
>> +		return ERR_PTR(-ENOMEM);
>> +	i = 0;
>> +	for_each_child_of_node(child, gchild)
>> +		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +						tz->trips, tz->ntrips);
>> +
>> +finish:
>> +	tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +	return 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_err("unable to find thermal zones\n");
>> +		return 0;
>> +	}
>> +
>> +	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 %ld\n",
>> +			       PTR_ERR(tz));
>> +			return 0;
>> +		}
>> +
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal ops\n");
>> +			return 0;
>> +		}
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal zone params\n");
>> +			return 0;
>> +		}
>> +		/* 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));
>> +	}
>> +	return 0;
>> +}
>> +
>> +/**
>> + * 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;
>> +	struct __thermal_zone *tz;
>> +
>> +	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);
>> +		tz = zone->devdata;
>> +		kfree(tz->tbps);
>> +		kfree(tz->trips);
>> +		kfree(tz);
>> +	}
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index 8a94300..a733241 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..6dd6ccd
>> --- /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		0
>> +#define THERMAL_TRIP_PASSIVE		1
>> +#define THERMAL_TRIP_HOT		2
>> +#define THERMAL_TRIP_CRITICAL		3
>> +
>> +/* 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 --]

Re: [PATCHv2 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 13:08, Guenter Roeck wrote:
> On Wed, Sep 18, 2013 at 12:03:09PM -0400, 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>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
>>  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, 1335 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
>> ---
>>
>> Hi all,
>>
>> As per Guenter's request, I changed this code to fail silently while
>> registering sensor drivers.
>>
>> Cheers,
>>
>> Eduardo
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..6664533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,498 @@
>> +* 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 attachments: 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.
>> +
>> +* Sensor devices
>> +
>> +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. Temperature sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #sensor-cells:	Used to provide sensor device specific information
>> +			while referring to it. Must be at least 1, 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. 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 level of cooling.
>> +
>> +Required property:
>> +- cooling-min-level:	A unsigned integer indicating the smallest
>> +			cooling level accepted. Typically 0.
>> +- cooling-max-level:	An unsigned integer indicating the largest
>> +			cooling level accepted.
>> +- #cooling-cells:	Used to provide cooling device specific information
>> +			while referring to it. Must be at least 2, in order
>> +			to specify minimum and maximum cooling level used
>> +			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
>> +- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
>> +			relative value, in milliCelsius.
>> +- type:			the trip type. Here is the type mapping:
>> +	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
>> +	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
>> +	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
>> +	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
>> +
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
>> +
>> +* Cooling device attachments
>> +
>> +The cooling device attachments 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 parameters,
>> +			referring to which cooling device is used in this
>> +			binding. The required parameters are: the minimum
>> +			cooling level and the maximum cooling level used
>> +			in this attach.
>> +- trip:			A phandle of a trip point node within the same thermal
>> +			zone.
>> +
>> +Optional property:
>> +- contribution:		The cooling contribution to the thermal zone of the
>> +			referred cooling device at the referred trip point.
>> +			The contribution is a value from 0 to 100. The sum
>> +			of all cooling contributions within a thermal zone
>> +			must never exceed 100.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit parameters means:
>> +(i)   - minimum level allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zones
>> +
>> +The thermal-zone node is the node containing all the required info
>> +for describing a thermal zone, including its cdev 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 attachments.
>> +
>> +Required properties:
>> +- passive-delay:	The maximum number of milliseconds to wait between polls
>> +			when performing passive cooling.
>> +- polling-delay:	The maximum number of milliseconds to wait between polls
>> +			when checking this thermal zone.
>> +- sensors:		A list of sensor phandles and their parameters. The
>> +			required parameter is the sensor id, in order to
>> +			identify internal sensors when the sensor IC features
>> +			several sensing units.
>> +- trips:		A sub-node containing several trip point nodes required
>> +			to describe the thermal zone.
>> +- cooling-attachments	A sub-node containing several cooling device attaches
>> +			nodes, used to describe the relation between trips
>> +			and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:		An array of integers (one signed cell) containing
>> +			coefficients to compose a linear relation between
>> +			the sensors described in the sensors property.
>> +			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 (passive-delay); 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.
>> +
>> +* 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-level = <0>;
>> +		cooling-max-level = <3>;
>> +		#cooling-cells = <2>; /* min followed by max */
>> +	};
>> +	...
>> +};
>> +
>> +&i2c1 {
>> +	...
>> +	fan0: fan@0x48 {
>> +		...
>> +		cooling-min-level = <0>;
>> +		cooling-max-level = <9>;
>> +		#cooling-cells = <2>; /* min followed by max */
>> +	};
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        sensors = <&bandgap0     0>;
>> +
>> +        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-attachments {
>> +		attach0 {
>> +			trip = <&cpu-alert0>;
>> +			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +		};
>> +		attach1 {
>> +			trip = <&cpu-alert1>;
>> +			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +		};
>> +		attach2 {
>> +			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, is used to remove the heat out of the thermal
>> +zone 'cpu-thermal' using its cooling levels 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 level.
>> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
>> +passive cooling device, using all its cooling levels 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 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* each zone within the SoC may have its own cooling */
>> +		...
>> +	};
>> +};
>> +
>> +gpu-thermal: gpu-thermal {
>> +	passive-delay = <120>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* each zone within the SoC may have its own cooling */
>> +		...
>> +	};
>> +};
>> +
>> +dsp-thermal: dsp-thermal {
>> +	passive-delay = <50>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* 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
>> +#sensor-cells property and using the first parameter 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 attachments.
>> +
>> +
>> +(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 {
>> +		...
>> +		#sensor-cells = <1>;
>> +	};
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        sensors = <&bandgap0	0>,
>> +		  <&adc		0>;
>> +
>> +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +	coefficients = 		<100	-120	484>;
>> +
>> +        trips {
>> +		...
>> +        };
>> +
>> +	cooling-attachments {
>> +		...
>> +	};
>> +};
>> +
>> +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:
>> +	passive-delay = <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 */
>> +        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 {
>> +		...
>> +		#sensor-cells = <1>; /* sensor internal ID */
>> +	};
>> +};
>> +
>> +batt-thermal {
>> +	passive-delay = <500>; /* milliseconds */
>> +	polling-delay = <2500>; /* milliseconds */
>> +
>> +	/* sensor       ID */
>> +	sensors = <&adc-dummy     4>;
>> +
>> +	trips {
>> +		...
>> +	};
>> +
>> +	cooling-attachments {
>> +		...
>> +	};
>> +};
>> +
>> +board-thermal: board-thermal {
>> +	passive-delay = <1000>; /* milliseconds */
>> +	polling-delay = <2500>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +	sensors = <&adc-dummy     0>,
>> +		  <&adc-dummy     1>,
>> +		  <&adc-dymmy     2>;
>> +			/*
>> +			 * 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-attachments {
>> +		attach0 {
>> +			trip = <&cpu-trip>;
>> +			cooling-device = <&cpu0 0 2>;
>> +			contribution = <55>;
>> +		};
>> +		attach1 {
>> +			trip = <&gpu-trip>;
>> +			cooling-device = <&gpu0 0 2>;
>> +			contribution = <20>;
>> +		};
>> +		attach2 {
>> +			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..857d40c
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,753 @@
>> +/*
>> + *  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>
>> +
>> +/***   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 level used at this trip point
>> + * @max: maximum cooling level 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;
>> +
>> +	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;
>> +
>> +		/* For now, thermal framework supports only 1 sensor per zone */
>> +		ret = of_parse_phandle_with_args(child, "sensors",
>> +						 "#sensor-cells",
>> +						 0, &sensor_specs);
>> +		if (ret)
>> +			continue;
>> +
>> +		if (sensor_specs.args_count < 1)
>> +			continue;
>> +
>> +		if (sensor_specs.np == sensor_np &&
>> +		    sensor_specs.args[0] == 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 = tzd->devdata;
>> +
> 
> You might want to check for a NULL thermal zone device before dereferencing it.

Good point Guenter, thanks for your time reviewing this code.

I am resending this patch only with this fix as its v3.

Eduardo

> 
> Guenter
> 
>> +	/* 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 attachment data
>> + * @np: DT node containing a cooling-attachment node
>> + * @__tbp: data structure to be filled with cooling attachment info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-attachment 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, "usage", &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;
>> +}
>> +
>> +/**
>> + * 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 = of_property_read_u32(np, "type", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing type property\n");
>> +		return ret;
>> +	}
>> +	trip->type = prop;
>> +
>> +	/* Required for cooling attachment 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.
>> + *
>> + * 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, *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) {
>> +		pr_err("not enough memory for thermal of zone\n");
>> +		return ERR_PTR(-ENOMEM);
>> +	}
>> +
>> +	ret = of_property_read_u32(np, "passive-delay", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing passive_delay property\n");
>> +		return ERR_PTR(ret);
>> +	}
>> +	tz->passive_delay = prop;
>> +
>> +	ret = of_property_read_u32(np, "polling-delay", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing polling_delay property\n");
>> +		return ERR_PTR(ret);
>> +	}
>> +	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);
>> +	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +	if (!tz->trips)
>> +		return ERR_PTR(-ENOMEM);
>> +	i = 0;
>> +	for_each_child_of_node(child, gchild)
>> +		thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +
>> +	of_node_put(child);
>> +
>> +	/* cooling-attachments */
>> +	child = of_get_child_by_name(np, "cooling-attachments");
>> +
>> +	/* cooling-attachments provided */
>> +	if (!child)
>> +		goto finish;
>> +
>> +	tz->num_tbps = of_get_child_count(child);
>> +	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +	if (!tz->tbps)
>> +		return ERR_PTR(-ENOMEM);
>> +	i = 0;
>> +	for_each_child_of_node(child, gchild)
>> +		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +						tz->trips, tz->ntrips);
>> +
>> +finish:
>> +	tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +	return 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_err("unable to find thermal zones\n");
>> +		return 0;
>> +	}
>> +
>> +	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 %ld\n",
>> +			       PTR_ERR(tz));
>> +			return 0;
>> +		}
>> +
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal ops\n");
>> +			return 0;
>> +		}
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal zone params\n");
>> +			return 0;
>> +		}
>> +		/* 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));
>> +	}
>> +	return 0;
>> +}
>> +
>> +/**
>> + * 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;
>> +	struct __thermal_zone *tz;
>> +
>> +	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);
>> +		tz = zone->devdata;
>> +		kfree(tz->tbps);
>> +		kfree(tz->trips);
>> +		kfree(tz);
>> +	}
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index 8a94300..a733241 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..6dd6ccd
>> --- /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		0
>> +#define THERMAL_TRIP_PASSIVE		1
>> +#define THERMAL_TRIP_HOT		2
>> +#define THERMAL_TRIP_CRITICAL		3
>> +
>> +/* 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 --]

Re: [lm-sensors] [PATCHv2 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 13:08, Guenter Roeck wrote:
> On Wed, Sep 18, 2013 at 12:03:09PM -0400, 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>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 753 +++++++++++++++++++++
>>  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, 1335 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
>> ---
>>
>> Hi all,
>>
>> As per Guenter's request, I changed this code to fail silently while
>> registering sensor drivers.
>>
>> Cheers,
>>
>> Eduardo
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..6664533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,498 @@
>> +* 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 attachments: 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.
>> +
>> +* Sensor devices
>> +
>> +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. Temperature sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #sensor-cells:	Used to provide sensor device specific information
>> +			while referring to it. Must be at least 1, 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. 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 level of cooling.
>> +
>> +Required property:
>> +- cooling-min-level:	A unsigned integer indicating the smallest
>> +			cooling level accepted. Typically 0.
>> +- cooling-max-level:	An unsigned integer indicating the largest
>> +			cooling level accepted.
>> +- #cooling-cells:	Used to provide cooling device specific information
>> +			while referring to it. Must be at least 2, in order
>> +			to specify minimum and maximum cooling level used
>> +			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
>> +- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
>> +			relative value, in milliCelsius.
>> +- type:			the trip type. Here is the type mapping:
>> +	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
>> +	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
>> +	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
>> +	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
>> +
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
>> +
>> +* Cooling device attachments
>> +
>> +The cooling device attachments 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 parameters,
>> +			referring to which cooling device is used in this
>> +			binding. The required parameters are: the minimum
>> +			cooling level and the maximum cooling level used
>> +			in this attach.
>> +- trip:			A phandle of a trip point node within the same thermal
>> +			zone.
>> +
>> +Optional property:
>> +- contribution:		The cooling contribution to the thermal zone of the
>> +			referred cooling device at the referred trip point.
>> +			The contribution is a value from 0 to 100. The sum
>> +			of all cooling contributions within a thermal zone
>> +			must never exceed 100.
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit parameters means:
>> +(i)   - minimum level allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zones
>> +
>> +The thermal-zone node is the node containing all the required info
>> +for describing a thermal zone, including its cdev 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 attachments.
>> +
>> +Required properties:
>> +- passive-delay:	The maximum number of milliseconds to wait between polls
>> +			when performing passive cooling.
>> +- polling-delay:	The maximum number of milliseconds to wait between polls
>> +			when checking this thermal zone.
>> +- sensors:		A list of sensor phandles and their parameters. The
>> +			required parameter is the sensor id, in order to
>> +			identify internal sensors when the sensor IC features
>> +			several sensing units.
>> +- trips:		A sub-node containing several trip point nodes required
>> +			to describe the thermal zone.
>> +- cooling-attachments	A sub-node containing several cooling device attaches
>> +			nodes, used to describe the relation between trips
>> +			and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:		An array of integers (one signed cell) containing
>> +			coefficients to compose a linear relation between
>> +			the sensors described in the sensors property.
>> +			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 (passive-delay); 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.
>> +
>> +* 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-level = <0>;
>> +		cooling-max-level = <3>;
>> +		#cooling-cells = <2>; /* min followed by max */
>> +	};
>> +	...
>> +};
>> +
>> +&i2c1 {
>> +	...
>> +	fan0: fan@0x48 {
>> +		...
>> +		cooling-min-level = <0>;
>> +		cooling-max-level = <9>;
>> +		#cooling-cells = <2>; /* min followed by max */
>> +	};
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        sensors = <&bandgap0     0>;
>> +
>> +        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-attachments {
>> +		attach0 {
>> +			trip = <&cpu-alert0>;
>> +			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +		};
>> +		attach1 {
>> +			trip = <&cpu-alert1>;
>> +			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +		};
>> +		attach2 {
>> +			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, is used to remove the heat out of the thermal
>> +zone 'cpu-thermal' using its cooling levels 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 level.
>> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
>> +passive cooling device, using all its cooling levels 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 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* each zone within the SoC may have its own cooling */
>> +		...
>> +	};
>> +};
>> +
>> +gpu-thermal: gpu-thermal {
>> +	passive-delay = <120>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* each zone within the SoC may have its own cooling */
>> +		...
>> +	};
>> +};
>> +
>> +dsp-thermal: dsp-thermal {
>> +	passive-delay = <50>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        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-attachments {
>> +		/* 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
>> +#sensor-cells property and using the first parameter 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 attachments.
>> +
>> +
>> +(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 {
>> +		...
>> +		#sensor-cells = <1>;
>> +	};
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +	...
>> +	#sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +	passive-delay = <250>; /* milliseconds */
>> +	polling-delay = <1000>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +        sensors = <&bandgap0	0>,
>> +		  <&adc		0>;
>> +
>> +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +	coefficients = 		<100	-120	484>;
>> +
>> +        trips {
>> +		...
>> +        };
>> +
>> +	cooling-attachments {
>> +		...
>> +	};
>> +};
>> +
>> +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:
>> +	passive-delay = <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 */
>> +        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 {
>> +		...
>> +		#sensor-cells = <1>; /* sensor internal ID */
>> +	};
>> +};
>> +
>> +batt-thermal {
>> +	passive-delay = <500>; /* milliseconds */
>> +	polling-delay = <2500>; /* milliseconds */
>> +
>> +	/* sensor       ID */
>> +	sensors = <&adc-dummy     4>;
>> +
>> +	trips {
>> +		...
>> +	};
>> +
>> +	cooling-attachments {
>> +		...
>> +	};
>> +};
>> +
>> +board-thermal: board-thermal {
>> +	passive-delay = <1000>; /* milliseconds */
>> +	polling-delay = <2500>; /* milliseconds */
>> +
>> +		/* sensor       ID */
>> +	sensors = <&adc-dummy     0>,
>> +		  <&adc-dummy     1>,
>> +		  <&adc-dymmy     2>;
>> +			/*
>> +			 * 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-attachments {
>> +		attach0 {
>> +			trip = <&cpu-trip>;
>> +			cooling-device = <&cpu0 0 2>;
>> +			contribution = <55>;
>> +		};
>> +		attach1 {
>> +			trip = <&gpu-trip>;
>> +			cooling-device = <&gpu0 0 2>;
>> +			contribution = <20>;
>> +		};
>> +		attach2 {
>> +			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..857d40c
>> --- /dev/null
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -0,0 +1,753 @@
>> +/*
>> + *  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>
>> +
>> +/***   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 level used at this trip point
>> + * @max: maximum cooling level 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;
>> +
>> +	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;
>> +
>> +		/* For now, thermal framework supports only 1 sensor per zone */
>> +		ret = of_parse_phandle_with_args(child, "sensors",
>> +						 "#sensor-cells",
>> +						 0, &sensor_specs);
>> +		if (ret)
>> +			continue;
>> +
>> +		if (sensor_specs.args_count < 1)
>> +			continue;
>> +
>> +		if (sensor_specs.np == sensor_np &&
>> +		    sensor_specs.args[0] == 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 = tzd->devdata;
>> +
> 
> You might want to check for a NULL thermal zone device before dereferencing it.

Good point Guenter, thanks for your time reviewing this code.

I am resending this patch only with this fix as its v3.

Eduardo

> 
> Guenter
> 
>> +	/* 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 attachment data
>> + * @np: DT node containing a cooling-attachment node
>> + * @__tbp: data structure to be filled with cooling attachment info
>> + * @trips: array of thermal zone trip points
>> + * @ntrips: number of trip points inside trips.
>> + *
>> + * This function parses a cooling-attachment 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, "usage", &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;
>> +}
>> +
>> +/**
>> + * 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 = of_property_read_u32(np, "type", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing type property\n");
>> +		return ret;
>> +	}
>> +	trip->type = prop;
>> +
>> +	/* Required for cooling attachment 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.
>> + *
>> + * 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, *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) {
>> +		pr_err("not enough memory for thermal of zone\n");
>> +		return ERR_PTR(-ENOMEM);
>> +	}
>> +
>> +	ret = of_property_read_u32(np, "passive-delay", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing passive_delay property\n");
>> +		return ERR_PTR(ret);
>> +	}
>> +	tz->passive_delay = prop;
>> +
>> +	ret = of_property_read_u32(np, "polling-delay", &prop);
>> +	if (ret < 0) {
>> +		pr_err("missing polling_delay property\n");
>> +		return ERR_PTR(ret);
>> +	}
>> +	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);
>> +	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
>> +	if (!tz->trips)
>> +		return ERR_PTR(-ENOMEM);
>> +	i = 0;
>> +	for_each_child_of_node(child, gchild)
>> +		thermal_of_populate_trip(gchild, &tz->trips[i++]);
>> +
>> +	of_node_put(child);
>> +
>> +	/* cooling-attachments */
>> +	child = of_get_child_by_name(np, "cooling-attachments");
>> +
>> +	/* cooling-attachments provided */
>> +	if (!child)
>> +		goto finish;
>> +
>> +	tz->num_tbps = of_get_child_count(child);
>> +	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +	if (!tz->tbps)
>> +		return ERR_PTR(-ENOMEM);
>> +	i = 0;
>> +	for_each_child_of_node(child, gchild)
>> +		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +						tz->trips, tz->ntrips);
>> +
>> +finish:
>> +	tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +	return 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_err("unable to find thermal zones\n");
>> +		return 0;
>> +	}
>> +
>> +	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 %ld\n",
>> +			       PTR_ERR(tz));
>> +			return 0;
>> +		}
>> +
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal ops\n");
>> +			return 0;
>> +		}
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal zone params\n");
>> +			return 0;
>> +		}
>> +		/* 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));
>> +	}
>> +	return 0;
>> +}
>> +
>> +/**
>> + * 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;
>> +	struct __thermal_zone *tz;
>> +
>> +	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);
>> +		tz = zone->devdata;
>> +		kfree(tz->tbps);
>> +		kfree(tz->trips);
>> +		kfree(tz);
>> +	}
>> +}
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index 8a94300..a733241 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..6dd6ccd
>> --- /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		0
>> +#define THERMAL_TRIP_PASSIVE		1
>> +#define THERMAL_TRIP_HOT		2
>> +#define THERMAL_TRIP_CRITICAL		3
>> +
>> +/* 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

[PATCHv3 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 758 +++++++++++++++++++++
 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, 1340 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
---

Hello all,

Here is yet another version with very minor change. The
third version of this code now includes a check for
NULL parameters in the sensor unregister API, as requested
by Guenter.

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..e895fa4
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,758 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

[PATCHv3 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 758 +++++++++++++++++++++
 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, 1340 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
---

Hello all,

Here is yet another version with very minor change. The
third version of this code now includes a check for
NULL parameters in the sensor unregister API, as requested
by Guenter.

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..e895fa4
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,758 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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] [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 758 +++++++++++++++++++++
 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, 1340 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
---

Hello all,

Here is yet another version with very minor change. The
third version of this code now includes a check for
NULL parameters in the sensor unregister API, as requested
by Guenter.

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..e895fa4
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,758 @@
+/*
+ *  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>
+
+/***   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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+	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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np = sensor_np &&
+		    sensor_specs.args[0] = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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) {
+		pr_err("not enough memory for thermal of zone\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = of_property_read_u32(np, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal ops\n");
+			return 0;
+		}
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops) {
+			pr_err("no memory available for thermal zone params\n");
+			return 0;
+		}
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

Re: [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 15:02 -0400, 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.

trivial notes:

> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
[]
> +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;
> +
> +	if (dev_trend > 0)
> +		*trend = THERMAL_TREND_RAISING;
> +	else if (dev_trend < 0)
> +		*trend = THERMAL_TREND_DROPPING;
> +	else
> +		*trend = THERMAL_TREND_STABLE;
> +
> +	return 0;
> +}

If readings are within some non zero noise level,
perhaps stable should be returned.

> +static struct __thermal_zone *
> +thermal_of_build_thermal_zone(struct device_node *np)
> +{
> +	struct device_node *child, *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) {
> +		pr_err("not enough memory for thermal of zone\n");

Unnecessary OOM message.
All allocs without GFP_NOWARN get a dump_stack()

> +int __init of_parse_thermal_zones(void)
> +{
[]
> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal ops\n");
> +			return 0;
> +		}
> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
> +
> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal zone params\n");
> +			return 0;
> +		}

a couple more OOMs.

Re: [lm-sensors] [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 15:02 -0400, 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.

trivial notes:

> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
[]
> +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;
> +
> +	if (dev_trend > 0)
> +		*trend = THERMAL_TREND_RAISING;
> +	else if (dev_trend < 0)
> +		*trend = THERMAL_TREND_DROPPING;
> +	else
> +		*trend = THERMAL_TREND_STABLE;
> +
> +	return 0;
> +}

If readings are within some non zero noise level,
perhaps stable should be returned.

> +static struct __thermal_zone *
> +thermal_of_build_thermal_zone(struct device_node *np)
> +{
> +	struct device_node *child, *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) {
> +		pr_err("not enough memory for thermal of zone\n");

Unnecessary OOM message.
All allocs without GFP_NOWARN get a dump_stack()

> +int __init of_parse_thermal_zones(void)
> +{
[]
> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal ops\n");
> +			return 0;
> +		}
> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
> +
> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!ops) {
> +			pr_err("no memory available for thermal zone params\n");
> +			return 0;
> +		}

a couple more OOMs.



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

Re: [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

Hello Joe,

Thanks for reviewing this code. Couple of replies.

 18-09-2013 15:11, Joe Perches wrote:
> On Wed, 2013-09-18 at 15:02 -0400, 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.
> 
> trivial notes:


No issues.

> 
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> []
>> +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;
>> +
>> +	if (dev_trend > 0)
>> +		*trend = THERMAL_TREND_RAISING;
>> +	else if (dev_trend < 0)
>> +		*trend = THERMAL_TREND_DROPPING;
>> +	else
>> +		*trend = THERMAL_TREND_STABLE;
>> +
>> +	return 0;
>> +}
> 
> If readings are within some non zero noise level,
> perhaps stable should be returned.

Yes, there should be some sort of threshold for temperature trend. But I
am not sure this is the right place to implement this. This type of
feature is in my TODO list, but I am planing to get it done within the
core code of the thermal framework.


> 
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +	struct device_node *child, *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) {
>> +		pr_err("not enough memory for thermal of zone\n");
> 
> Unnecessary OOM message.
> All allocs without GFP_NOWARN get a dump_stack()
> 
>> +int __init of_parse_thermal_zones(void)
>> +{
> []
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal ops\n");
>> +			return 0;
>> +		}
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal zone params\n");
>> +			return 0;
>> +		}
> 
> a couple more OOMs.
> 

Hmmm.. I am pretty sure you have a good point. But to me seams to be
still a common practice to have drivers outputing error messages when
allocation fails. A simple git grep -A 4 kzalloc for instance, shows
that there are still quite a considerable amount of occurrences of such
practice.


> 
> 
> 


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

Re: [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

Hello Joe,

Thanks for reviewing this code. Couple of replies.

 18-09-2013 15:11, Joe Perches wrote:
> On Wed, 2013-09-18 at 15:02 -0400, 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.
> 
> trivial notes:


No issues.

> 
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> []
>> +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;
>> +
>> +	if (dev_trend > 0)
>> +		*trend = THERMAL_TREND_RAISING;
>> +	else if (dev_trend < 0)
>> +		*trend = THERMAL_TREND_DROPPING;
>> +	else
>> +		*trend = THERMAL_TREND_STABLE;
>> +
>> +	return 0;
>> +}
> 
> If readings are within some non zero noise level,
> perhaps stable should be returned.

Yes, there should be some sort of threshold for temperature trend. But I
am not sure this is the right place to implement this. This type of
feature is in my TODO list, but I am planing to get it done within the
core code of the thermal framework.


> 
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +	struct device_node *child, *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) {
>> +		pr_err("not enough memory for thermal of zone\n");
> 
> Unnecessary OOM message.
> All allocs without GFP_NOWARN get a dump_stack()
> 
>> +int __init of_parse_thermal_zones(void)
>> +{
> []
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal ops\n");
>> +			return 0;
>> +		}
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal zone params\n");
>> +			return 0;
>> +		}
> 
> a couple more OOMs.
> 

Hmmm.. I am pretty sure you have a good point. But to me seams to be
still a common practice to have drivers outputing error messages when
allocation fails. A simple git grep -A 4 kzalloc for instance, shows
that there are still quite a considerable amount of occurrences of such
practice.


> 
> 
> 


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

Re: [lm-sensors] [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

Hello Joe,

Thanks for reviewing this code. Couple of replies.

 18-09-2013 15:11, Joe Perches wrote:
> On Wed, 2013-09-18 at 15:02 -0400, 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.
> 
> trivial notes:


No issues.

> 
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> []
>> +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;
>> +
>> +	if (dev_trend > 0)
>> +		*trend = THERMAL_TREND_RAISING;
>> +	else if (dev_trend < 0)
>> +		*trend = THERMAL_TREND_DROPPING;
>> +	else
>> +		*trend = THERMAL_TREND_STABLE;
>> +
>> +	return 0;
>> +}
> 
> If readings are within some non zero noise level,
> perhaps stable should be returned.

Yes, there should be some sort of threshold for temperature trend. But I
am not sure this is the right place to implement this. This type of
feature is in my TODO list, but I am planing to get it done within the
core code of the thermal framework.


> 
>> +static struct __thermal_zone *
>> +thermal_of_build_thermal_zone(struct device_node *np)
>> +{
>> +	struct device_node *child, *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) {
>> +		pr_err("not enough memory for thermal of zone\n");
> 
> Unnecessary OOM message.
> All allocs without GFP_NOWARN get a dump_stack()
> 
>> +int __init of_parse_thermal_zones(void)
>> +{
> []
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal ops\n");
>> +			return 0;
>> +		}
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops) {
>> +			pr_err("no memory available for thermal zone params\n");
>> +			return 0;
>> +		}
> 
> a couple more OOMs.
> 

Hmmm.. I am pretty sure you have a good point. But to me seams to be
still a common practice to have drivers outputing error messages when
allocation fails. A simple git grep -A 4 kzalloc for instance, shows
that there are still quite a considerable amount of occurrences of such
practice.


> 
> 
> 


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

Re: [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 15:44 -0400, Eduardo Valentin wrote:
> Hello Joe,

Hello Eduardo.

>  18-09-2013 15:11, Joe Perches wrote:
> > On Wed, 2013-09-18 at 15:02 -0400, 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.
> > 
> > trivial notes:
[]
> > If readings are within some non zero noise level,
> > perhaps stable should be returned.
> 
> Yes, there should be some sort of threshold for temperature trend. But I
> am not sure this is the right place to implement this. This type of
> feature is in my TODO list, but I am planing to get it done within the
> core code of the thermal framework.

No worries, one day...  Just wanted to bring it to attention.

> >> +static struct __thermal_zone *
> >> +thermal_of_build_thermal_zone(struct device_node *np)
> >> +{
[]
> >> +	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
> >> +	if (!tz) {
> >> +		pr_err("not enough memory for thermal of zone\n");
> > 
> > Unnecessary OOM message.
> > All allocs without GFP_NOWARN get a dump_stack()

[]

> Hmmm.. I am pretty sure you have a good point. But to me seams to be
> still a common practice to have drivers outputing error messages when
> allocation fails. A simple git grep -A 4 kzalloc for instance, shows
> that there are still quite a considerable amount of occurrences of such
> practice.

True though a considerable number have been removed.
I think these should all be deleted eventually and
there's no good reason to add more.

Re: [lm-sensors] [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 15:44 -0400, Eduardo Valentin wrote:
> Hello Joe,

Hello Eduardo.

>  18-09-2013 15:11, Joe Perches wrote:
> > On Wed, 2013-09-18 at 15:02 -0400, 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.
> > 
> > trivial notes:
[]
> > If readings are within some non zero noise level,
> > perhaps stable should be returned.
> 
> Yes, there should be some sort of threshold for temperature trend. But I
> am not sure this is the right place to implement this. This type of
> feature is in my TODO list, but I am planing to get it done within the
> core code of the thermal framework.

No worries, one day...  Just wanted to bring it to attention.

> >> +static struct __thermal_zone *
> >> +thermal_of_build_thermal_zone(struct device_node *np)
> >> +{
[]
> >> +	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
> >> +	if (!tz) {
> >> +		pr_err("not enough memory for thermal of zone\n");
> > 
> > Unnecessary OOM message.
> > All allocs without GFP_NOWARN get a dump_stack()

[]

> Hmmm.. I am pretty sure you have a good point. But to me seams to be
> still a common practice to have drivers outputing error messages when
> allocation fails. A simple git grep -A 4 kzalloc for instance, shows
> that there are still quite a considerable amount of occurrences of such
> practice.

True though a considerable number have been removed.
I think these should all be deleted eventually and
there's no good reason to add more.



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

Re: [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 15:59, Joe Perches wrote:
> On Wed, 2013-09-18 at 15:44 -0400, Eduardo Valentin wrote:
>> Hello Joe,
> 
> Hello Eduardo.
> 
>>  18-09-2013 15:11, Joe Perches wrote:
>>> On Wed, 2013-09-18 at 15:02 -0400, 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.
>>>
>>> trivial notes:
> []
>>> If readings are within some non zero noise level,
>>> perhaps stable should be returned.
>>
>> Yes, there should be some sort of threshold for temperature trend. But I
>> am not sure this is the right place to implement this. This type of
>> feature is in my TODO list, but I am planing to get it done within the
>> core code of the thermal framework.
> 
> No worries, one day...  Just wanted to bring it to attention.

Thanks, no worries, I should be working on it at some point in near
future. It does not hurt to add a TODO mark above this code though.

> 
>>>> +static struct __thermal_zone *
>>>> +thermal_of_build_thermal_zone(struct device_node *np)
>>>> +{
> []
>>>> +	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>>>> +	if (!tz) {
>>>> +		pr_err("not enough memory for thermal of zone\n");
>>>
>>> Unnecessary OOM message.
>>> All allocs without GFP_NOWARN get a dump_stack()
> 
> []
> 
>> Hmmm.. I am pretty sure you have a good point. But to me seams to be
>> still a common practice to have drivers outputing error messages when
>> allocation fails. A simple git grep -A 4 kzalloc for instance, shows
>> that there are still quite a considerable amount of occurrences of such
>> practice.
> 
> True though a considerable number have been removed.
> I think these should all be deleted eventually and
> there's no good reason to add more.


I see.  I will repost with your suggestion. Thanks.

> 
> 
> 
> 


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

Re: [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 15:59, Joe Perches wrote:
> On Wed, 2013-09-18 at 15:44 -0400, Eduardo Valentin wrote:
>> Hello Joe,
> 
> Hello Eduardo.
> 
>>  18-09-2013 15:11, Joe Perches wrote:
>>> On Wed, 2013-09-18 at 15:02 -0400, 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.
>>>
>>> trivial notes:
> []
>>> If readings are within some non zero noise level,
>>> perhaps stable should be returned.
>>
>> Yes, there should be some sort of threshold for temperature trend. But I
>> am not sure this is the right place to implement this. This type of
>> feature is in my TODO list, but I am planing to get it done within the
>> core code of the thermal framework.
> 
> No worries, one day...  Just wanted to bring it to attention.

Thanks, no worries, I should be working on it at some point in near
future. It does not hurt to add a TODO mark above this code though.

> 
>>>> +static struct __thermal_zone *
>>>> +thermal_of_build_thermal_zone(struct device_node *np)
>>>> +{
> []
>>>> +	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>>>> +	if (!tz) {
>>>> +		pr_err("not enough memory for thermal of zone\n");
>>>
>>> Unnecessary OOM message.
>>> All allocs without GFP_NOWARN get a dump_stack()
> 
> []
> 
>> Hmmm.. I am pretty sure you have a good point. But to me seams to be
>> still a common practice to have drivers outputing error messages when
>> allocation fails. A simple git grep -A 4 kzalloc for instance, shows
>> that there are still quite a considerable amount of occurrences of such
>> practice.
> 
> True though a considerable number have been removed.
> I think these should all be deleted eventually and
> there's no good reason to add more.


I see.  I will repost with your suggestion. Thanks.

> 
> 
> 
> 


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

Re: [lm-sensors] [PATCHv3 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 15:59, Joe Perches wrote:
> On Wed, 2013-09-18 at 15:44 -0400, Eduardo Valentin wrote:
>> Hello Joe,
> 
> Hello Eduardo.
> 
>>  18-09-2013 15:11, Joe Perches wrote:
>>> On Wed, 2013-09-18 at 15:02 -0400, 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.
>>>
>>> trivial notes:
> []
>>> If readings are within some non zero noise level,
>>> perhaps stable should be returned.
>>
>> Yes, there should be some sort of threshold for temperature trend. But I
>> am not sure this is the right place to implement this. This type of
>> feature is in my TODO list, but I am planing to get it done within the
>> core code of the thermal framework.
> 
> No worries, one day...  Just wanted to bring it to attention.

Thanks, no worries, I should be working on it at some point in near
future. It does not hurt to add a TODO mark above this code though.

> 
>>>> +static struct __thermal_zone *
>>>> +thermal_of_build_thermal_zone(struct device_node *np)
>>>> +{
> []
>>>> +	tz = kzalloc(sizeof(*tz), GFP_KERNEL);
>>>> +	if (!tz) {
>>>> +		pr_err("not enough memory for thermal of zone\n");
>>>
>>> Unnecessary OOM message.
>>> All allocs without GFP_NOWARN get a dump_stack()
> 
> []
> 
>> Hmmm.. I am pretty sure you have a good point. But to me seams to be
>> still a common practice to have drivers outputing error messages when
>> allocation fails. A simple git grep -A 4 kzalloc for instance, shows
>> that there are still quite a considerable amount of occurrences of such
>> practice.
> 
> True though a considerable number have been removed.
> I think these should all be deleted eventually and
> there's no good reason to add more.


I see.  I will repost with your suggestion. Thanks.

> 
> 
> 
> 


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

[PATCHv4 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 757 +++++++++++++++++++++
 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, 1339 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
---

Hello guys,

This is version 4. It also includes just a minor change. Now
there are no error messages for OOM situations, relying on
stack dumps from MM code, as suggested by Joe Perches.

Cheers,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..831f1e6
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,757 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			return 0;
+
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops)
+			return 0;
+
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

[PATCHv4 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 757 +++++++++++++++++++++
 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, 1339 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
---

Hello guys,

This is version 4. It also includes just a minor change. Now
there are no error messages for OOM situations, relying on
stack dumps from MM code, as suggested by Joe Perches.

Cheers,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..831f1e6
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,757 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			return 0;
+
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops)
+			return 0;
+
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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] [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 757 +++++++++++++++++++++
 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, 1339 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
---

Hello guys,

This is version 4. It also includes just a minor change. Now
there are no error messages for OOM situations, relying on
stack dumps from MM code, as suggested by Joe Perches.

Cheers,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..831f1e6
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,757 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np = sensor_np &&
+		    sensor_specs.args[0] = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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_err("unable to find thermal zones\n");
+		return 0;
+	}
+
+	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 %ld\n",
+			       PTR_ERR(tz));
+			return 0;
+		}
+
+		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
+		if (!ops)
+			return 0;
+
+		memcpy(ops, &of_thermal_ops, sizeof(*ops));
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!ops)
+			return 0;
+
+		/* 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));
+	}
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:

> +/**
> + * 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_err("unable to find thermal zones\n");
> +		return 0;

return 0? This is success?

> +	}
> +
> +	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 %ld\n",
> +			       PTR_ERR(tz));
> +			return 0;
> +		}
> +
> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> +		if (!ops)
> +			return 0;
> +
> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));

kmemdup instead of alloc/memcpy

> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!ops)
> +			return 0;
> +
> +		/* 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));
> +	}
> +	return 0;
> +}

All returns are 0, always successful?

Re: [lm-sensors] [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:

> +/**
> + * 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_err("unable to find thermal zones\n");
> +		return 0;

return 0? This is success?

> +	}
> +
> +	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 %ld\n",
> +			       PTR_ERR(tz));
> +			return 0;
> +		}
> +
> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> +		if (!ops)
> +			return 0;
> +
> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));

kmemdup instead of alloc/memcpy

> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!ops)
> +			return 0;
> +
> +		/* 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));
> +	}
> +	return 0;
> +}

All returns are 0, always successful?



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

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 16:44, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
> 
>> +/**
>> + * 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_err("unable to find thermal zones\n");
>> +		return 0;
> 
> return 0? This is success?

This case is success because there should be systems without thermal DT
entries.

> 
>> +	}
>> +
>> +	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 %ld\n",
>> +			       PTR_ERR(tz));
>> +			return 0;
>> +		}
>> +
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops)
>> +			return 0;
>> +
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
> 
> kmemdup instead of alloc/memcpy
> 

OK.

>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops)
>> +			return 0;
>> +

These should not be 0 though.

>> +		/* 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));
>> +	}
>> +	return 0;

This one is correct.

>> +}
> 
> All returns are 0, always successful?

hmmm.. I am sending after reworking the return code of this function.

> 
> 
> 
> 


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

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 16:44, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
> 
>> +/**
>> + * 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_err("unable to find thermal zones\n");
>> +		return 0;
> 
> return 0? This is success?

This case is success because there should be systems without thermal DT
entries.

> 
>> +	}
>> +
>> +	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 %ld\n",
>> +			       PTR_ERR(tz));
>> +			return 0;
>> +		}
>> +
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops)
>> +			return 0;
>> +
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
> 
> kmemdup instead of alloc/memcpy
> 

OK.

>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops)
>> +			return 0;
>> +

These should not be 0 though.

>> +		/* 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));
>> +	}
>> +	return 0;

This one is correct.

>> +}
> 
> All returns are 0, always successful?

hmmm.. I am sending after reworking the return code of this function.

> 
> 
> 
> 


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

Re: [lm-sensors] [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 16:44, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
> 
>> +/**
>> + * 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_err("unable to find thermal zones\n");
>> +		return 0;
> 
> return 0? This is success?

This case is success because there should be systems without thermal DT
entries.

> 
>> +	}
>> +
>> +	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 %ld\n",
>> +			       PTR_ERR(tz));
>> +			return 0;
>> +		}
>> +
>> +		ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +		if (!ops)
>> +			return 0;
>> +
>> +		memcpy(ops, &of_thermal_ops, sizeof(*ops));
> 
> kmemdup instead of alloc/memcpy
> 

OK.

>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!ops)
>> +			return 0;
>> +

These should not be 0 though.

>> +		/* 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));
>> +	}
>> +	return 0;

This one is correct.

>> +}
> 
> All returns are 0, always successful?

hmmm.. I am sending after reworking the return code of this function.

> 
> 
> 
> 


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

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:52 -0400, Eduardo Valentin wrote:
> On 18-09-2013 16:44, Joe Perches wrote:
> > On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
> > 
> >> +/**
> >> + * 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_err("unable to find thermal zones\n");
> >> +		return 0;
> > 
> > return 0? This is success?
> 
> This case is success because there should be systems without thermal DT
> entries.

Then the pr_err should be pr_notice/info or not there at all.

[]

> >> +		/* 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));

Should there should be a return -ERR here?

> hmmm.. I am sending after reworking the return code of this function.

thanks.

Re: [lm-sensors] [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:52 -0400, Eduardo Valentin wrote:
> On 18-09-2013 16:44, Joe Perches wrote:
> > On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
> > 
> >> +/**
> >> + * 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_err("unable to find thermal zones\n");
> >> +		return 0;
> > 
> > return 0? This is success?
> 
> This case is success because there should be systems without thermal DT
> entries.

Then the pr_err should be pr_notice/info or not there at all.

[]

> >> +		/* 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));

Should there should be a return -ERR here?

> hmmm.. I am sending after reworking the return code of this function.

thanks.


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

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 17:00, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:52 -0400, Eduardo Valentin wrote:
>> On 18-09-2013 16:44, Joe Perches wrote:
>>> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
>>>
>>>> +/**
>>>> + * 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_err("unable to find thermal zones\n");
>>>> +		return 0;
>>>
>>> return 0? This is success?
>>
>> This case is success because there should be systems without thermal DT
>> entries.
> 
> Then the pr_err should be pr_notice/info or not there at all.

Yeah, done in v5.

> 
> []
> 
>>>> +		/* 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));
> 
> Should there should be a return -ERR here?
> 

well, no, there might be other correct thermal zones in DT that needs
parsing.

>> hmmm.. I am sending after reworking the return code of this function.
> 
> thanks.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


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

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 17:00, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:52 -0400, Eduardo Valentin wrote:
>> On 18-09-2013 16:44, Joe Perches wrote:
>>> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
>>>
>>>> +/**
>>>> + * 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_err("unable to find thermal zones\n");
>>>> +		return 0;
>>>
>>> return 0? This is success?
>>
>> This case is success because there should be systems without thermal DT
>> entries.
> 
> Then the pr_err should be pr_notice/info or not there at all.

Yeah, done in v5.

> 
> []
> 
>>>> +		/* 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));
> 
> Should there should be a return -ERR here?
> 

well, no, there might be other correct thermal zones in DT that needs
parsing.

>> hmmm.. I am sending after reworking the return code of this function.
> 
> thanks.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


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

Re: [lm-sensors] [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 17:00, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:52 -0400, Eduardo Valentin wrote:
>> On 18-09-2013 16:44, Joe Perches wrote:
>>> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
>>>
>>>> +/**
>>>> + * 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_err("unable to find thermal zones\n");
>>>> +		return 0;
>>>
>>> return 0? This is success?
>>
>> This case is success because there should be systems without thermal DT
>> entries.
> 
> Then the pr_err should be pr_notice/info or not there at all.

Yeah, done in v5.

> 
> []
> 
>>>> +		/* 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));
> 
> Should there should be a return -ERR here?
> 

well, no, there might be other correct thermal zones in DT that needs
parsing.

>> hmmm.. I am sending after reworking the return code of this function.
> 
> thanks.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


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

[PATCHv5 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 757 +++++++++++++++++++++
 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, 1339 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
---

Hello guys,

I've got couple of review suggestions by Joe P., so I am resending v5, as they were
minor changes. I've replaced kzalloc/memcpy by kmemdup and improved the error
code reporting in the init function of the parser.

Thanks Joe!

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..81365d8
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,757 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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)
+			return -ENOMEM;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp)
+			return -ENOMEM;
+
+		/* 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));
+	}
+
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

[PATCHv5 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 757 +++++++++++++++++++++
 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, 1339 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
---

Hello guys,

I've got couple of review suggestions by Joe P., so I am resending v5, as they were
minor changes. I've replaced kzalloc/memcpy by kmemdup and improved the error
code reporting in the init function of the parser.

Thanks Joe!

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..81365d8
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,757 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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)
+			return -ENOMEM;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp)
+			return -ENOMEM;
+
+		/* 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));
+	}
+
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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] [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 ++++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 757 +++++++++++++++++++++
 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, 1339 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
---

Hello guys,

I've got couple of review suggestions by Joe P., so I am resending v5, as they were
minor changes. I've replaced kzalloc/memcpy by kmemdup and improved the error
code reporting in the init function of the parser.

Thanks Joe!

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..81365d8
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,757 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np = sensor_np &&
+		    sensor_specs.args[0] = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return 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)
+			return -ENOMEM;
+
+		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
+		if (!tzp)
+			return -ENOMEM;
+
+		/* 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));
+	}
+
+	return 0;
+}
+
+/**
+ * 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;
+	struct __thermal_zone *tz;
+
+	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);
+		tz = zone->devdata;
+		kfree(tz->tbps);
+		kfree(tz->trips);
+		kfree(tz);
+	}
+}
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

Re: [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:57 -0400, 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.
[]
> +int __init of_parse_thermal_zones(void)
> +{
> +	struct device_node *np, *child;
> +	struct __thermal_zone *tz;
> +	struct thermal_zone_device_ops *ops;
[]
> +		if (!ops)
> +			return -ENOMEM;
> +
> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!tzp)
> +			return -ENOMEM;

leaking memory when ops && !tpz

> +
> +		/* 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));
> +	}

Still leaking memory if !zone no?

> +
> +	return 0;
> +}

Re: [lm-sensors] [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:57 -0400, 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.
[]
> +int __init of_parse_thermal_zones(void)
> +{
> +	struct device_node *np, *child;
> +	struct __thermal_zone *tz;
> +	struct thermal_zone_device_ops *ops;
[]
> +		if (!ops)
> +			return -ENOMEM;
> +
> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> +		if (!tzp)
> +			return -ENOMEM;

leaking memory when ops && !tpz

> +
> +		/* 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));
> +	}

Still leaking memory if !zone no?

> +
> +	return 0;
> +}



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

Re: [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 17:04, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:57 -0400, 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.
> []
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +	struct device_node *np, *child;
>> +	struct __thermal_zone *tz;
>> +	struct thermal_zone_device_ops *ops;
> []
>> +		if (!ops)
>> +			return -ENOMEM;
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!tzp)
>> +			return -ENOMEM;
> 
> leaking memory when ops && !tpz

Yeah, and if !ops too. I am reposting with proper kfreeing. I will be
rolling back the added thermal zones when there is an OOM situation too.

> 
>> +
>> +		/* 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));
>> +	}
> 
> Still leaking memory if !zone no?

yeah. Will free them too.
> 
>> +
>> +	return 0;
>> +}
> 
> 
> 
> 


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

Re: [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 17:04, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:57 -0400, 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.
> []
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +	struct device_node *np, *child;
>> +	struct __thermal_zone *tz;
>> +	struct thermal_zone_device_ops *ops;
> []
>> +		if (!ops)
>> +			return -ENOMEM;
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!tzp)
>> +			return -ENOMEM;
> 
> leaking memory when ops && !tpz

Yeah, and if !ops too. I am reposting with proper kfreeing. I will be
rolling back the added thermal zones when there is an OOM situation too.

> 
>> +
>> +		/* 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));
>> +	}
> 
> Still leaking memory if !zone no?

yeah. Will free them too.
> 
>> +
>> +	return 0;
>> +}
> 
> 
> 
> 


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

Re: [lm-sensors] [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 18-09-2013 17:04, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:57 -0400, 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.
> []
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +	struct device_node *np, *child;
>> +	struct __thermal_zone *tz;
>> +	struct thermal_zone_device_ops *ops;
> []
>> +		if (!ops)
>> +			return -ENOMEM;
>> +
>> +		tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +		if (!tzp)
>> +			return -ENOMEM;
> 
> leaking memory when ops && !tpz

Yeah, and if !ops too. I am reposting with proper kfreeing. I will be
rolling back the added thermal zones when there is an OOM situation too.

> 
>> +
>> +		/* 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));
>> +	}
> 
> Still leaking memory if !zone no?

yeah. Will free them too.
> 
>> +
>> +	return 0;
>> +}
> 
> 
> 
> 


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

[PATCHv6 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
 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, 1357 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

---

Hello all,

Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.

Here is a version with a refactored init function without leaks in the failure
patch. I also added a couple of comments to better understand the intention of
that function. Besides, when there are no memory available, the function
rolls back what ever thermal zones have been added.

Thanks,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..a32f393
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,775 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+}
+
+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 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

[PATCHv6 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
 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, 1357 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

---

Hello all,

Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.

Here is a version with a refactored init function without leaks in the failure
patch. I also added a couple of comments to better understand the intention of
that function. Besides, when there are no memory available, the function
rolls back what ever thermal zones have been added.

Thanks,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..a32f393
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,775 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np == sensor_np &&
+		    sensor_specs.args[0] == 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+}
+
+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 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[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>
---
 .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
 drivers/thermal/Kconfig                            |  13 +
 drivers/thermal/Makefile                           |   1 +
 drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
 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, 1357 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

---

Hello all,

Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.

Here is a version with a refactored init function without leaks in the failure
patch. I also added a couple of comments to better understand the intention of
that function. Besides, when there are no memory available, the function
rolls back what ever thermal zones have been added.

Thanks,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 0000000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* 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 attachments: 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.
+
+* Sensor devices
+
+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. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:	Used to provide sensor device specific information
+			while referring to it. Must be at least 1, 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. 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 level of cooling.
+
+Required property:
+- cooling-min-level:	A unsigned integer indicating the smallest
+			cooling level accepted. Typically 0.
+- cooling-max-level:	An unsigned integer indicating the largest
+			cooling level accepted.
+- #cooling-cells:	Used to provide cooling device specific information
+			while referring to it. Must be at least 2, in order
+			to specify minimum and maximum cooling level used
+			in the reference. See Cooling device attachments 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:		the trip temperature level, in milliCelsius.
+- hysteresis:		a (low) hysteresis value on 'temperature'. This is a
+			relative value, in milliCelsius.
+- type:			the trip type. Here is the type mapping:
+	THERMAL_TRIP_ACTIVE	0:	A trip point to enable active cooling
+	THERMAL_TRIP_PASSIVE	1:	A trip point to enable passive cooling
+	THERMAL_TRIP_HOT	2:	A trip point to notify emergency
+	THERMAL_TRIP_CRITICAL	3:	Hardware not reliable.
+
+Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
+
+* Cooling device attachments
+
+The cooling device attachments 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 parameters,
+			referring to which cooling device is used in this
+			binding. The required parameters are: the minimum
+			cooling level and the maximum cooling level used
+			in this attach.
+- trip:			A phandle of a trip point node within the same thermal
+			zone.
+
+Optional property:
+- contribution:		The cooling contribution to the thermal zone of the
+			referred cooling device at the referred trip point.
+			The contribution is a value from 0 to 100. The sum
+			of all cooling contributions within a thermal zone
+			must never exceed 100.
+
+Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
+limit parameters means:
+(i)   - minimum level allowed for minimum cooling level used in the reference.
+(ii)  - maximum level allowed for maximum cooling level used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+
+* Thermal zones
+
+The thermal-zone node is the node containing all the required info
+for describing a thermal zone, including its cdev 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 attachments.
+
+Required properties:
+- passive-delay:	The maximum number of milliseconds to wait between polls
+			when performing passive cooling.
+- polling-delay:	The maximum number of milliseconds to wait between polls
+			when checking this thermal zone.
+- sensors:		A list of sensor phandles and their parameters. The
+			required parameter is the sensor id, in order to
+			identify internal sensors when the sensor IC features
+			several sensing units.
+- trips:		A sub-node containing several trip point nodes required
+			to describe the thermal zone.
+- cooling-attachments	A sub-node containing several cooling device attaches
+			nodes, used to describe the relation between trips
+			and cooling devices.
+
+Optional property:
+- coefficients:		An array of integers (one signed cell) containing
+			coefficients to compose a linear relation between
+			the sensors described in the sensors property.
+			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 (passive-delay); 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.
+
+* 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-level = <0>;
+		cooling-max-level = <3>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+	...
+};
+
+&i2c1 {
+	...
+	fan0: fan@0x48 {
+		...
+		cooling-min-level = <0>;
+		cooling-max-level = <9>;
+		#cooling-cells = <2>; /* min followed by max */
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0     0>;
+
+        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-attachments {
+		attach0 {
+			trip = <&cpu-alert0>;
+			cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+		};
+		attach1 {
+			trip = <&cpu-alert1>;
+			cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+		};
+		attach2 {
+			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, is used to remove the heat out of the thermal
+zone 'cpu-thermal' using its cooling levels 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 level.
+The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
+passive cooling device, using all its cooling levels 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 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+gpu-thermal: gpu-thermal {
+	passive-delay = <120>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* each zone within the SoC may have its own cooling */
+		...
+	};
+};
+
+dsp-thermal: dsp-thermal {
+	passive-delay = <50>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		/* 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
+#sensor-cells property and using the first parameter 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 attachments.
+
+
+(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 {
+		...
+		#sensor-cells = <1>;
+	};
+};
+
+bandgap0: bandgap@0x0000ED00 {
+	...
+	#sensor-cells = <1>;
+};
+
+cpu-thermal: cpu-thermal {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        sensors = <&bandgap0	0>,
+		  <&adc		0>;
+
+		/* hotspot = 100 * bandgap - 120 * adc + 484 */
+	coefficients = 		<100	-120	484>;
+
+        trips {
+		...
+        };
+
+	cooling-attachments {
+		...
+	};
+};
+
+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:
+	passive-delay = <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 */
+        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 {
+		...
+		#sensor-cells = <1>; /* sensor internal ID */
+	};
+};
+
+batt-thermal {
+	passive-delay = <500>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+	/* sensor       ID */
+	sensors = <&adc-dummy     4>;
+
+	trips {
+		...
+	};
+
+	cooling-attachments {
+		...
+	};
+};
+
+board-thermal: board-thermal {
+	passive-delay = <1000>; /* milliseconds */
+	polling-delay = <2500>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&adc-dummy     0>,
+		  <&adc-dummy     1>,
+		  <&adc-dymmy     2>;
+			/*
+			 * 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-attachments {
+		attach0 {
+			trip = <&cpu-trip>;
+			cooling-device = <&cpu0 0 2>;
+			contribution = <55>;
+		};
+		attach1 {
+			trip = <&gpu-trip>;
+			cooling-device = <&gpu0 0 2>;
+			contribution = <20>;
+		};
+		attach2 {
+			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..a32f393
--- /dev/null
+++ b/drivers/thermal/of-thermal.c
@@ -0,0 +1,775 @@
+/*
+ *  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 level used at this trip point
+ * @max: maximum cooling level 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;
+
+		/* For now, thermal framework supports only 1 sensor per zone */
+		ret = of_parse_phandle_with_args(child, "sensors",
+						 "#sensor-cells",
+						 0, &sensor_specs);
+		if (ret)
+			continue;
+
+		if (sensor_specs.args_count < 1)
+			continue;
+
+		if (sensor_specs.np = sensor_np &&
+		    sensor_specs.args[0] = 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 attachment data
+ * @np: DT node containing a cooling-attachment node
+ * @__tbp: data structure to be filled with cooling attachment info
+ * @trips: array of thermal zone trip points
+ * @ntrips: number of trip points inside trips.
+ *
+ * This function parses a cooling-attachment 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, "usage", &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;
+}
+
+/**
+ * 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 = of_property_read_u32(np, "type", &prop);
+	if (ret < 0) {
+		pr_err("missing type property\n");
+		return ret;
+	}
+	trip->type = prop;
+
+	/* Required for cooling attachment 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.
+ *
+ * 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, *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, "passive-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing passive_delay property\n");
+		return ERR_PTR(ret);
+	}
+	tz->passive_delay = prop;
+
+	ret = of_property_read_u32(np, "polling-delay", &prop);
+	if (ret < 0) {
+		pr_err("missing polling_delay property\n");
+		return ERR_PTR(ret);
+	}
+	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);
+	tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
+	if (!tz->trips)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_trip(gchild, &tz->trips[i++]);
+
+	of_node_put(child);
+
+	/* cooling-attachments */
+	child = of_get_child_by_name(np, "cooling-attachments");
+
+	/* cooling-attachments provided */
+	if (!child)
+		goto finish;
+
+	tz->num_tbps = of_get_child_count(child);
+	tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
+	if (!tz->tbps)
+		return ERR_PTR(-ENOMEM);
+	i = 0;
+	for_each_child_of_node(child, gchild)
+		thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
+						tz->trips, tz->ntrips);
+
+finish:
+	tz->mode = THERMAL_DEVICE_DISABLED;
+
+	return tz;
+}
+
+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 8a94300..a733241 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..6dd6ccd
--- /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		0
+#define THERMAL_TRIP_PASSIVE		1
+#define THERMAL_TRIP_HOT		2
+#define THERMAL_TRIP_CRITICAL		3
+
+/* 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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Mark Rutland]

Hi Eduardo,

Apologies for having taken so long to get back you on this.

I have several comments on the binding and the way it's parsed.

On Wed, Sep 18, 2013 at 10:35:36PM +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>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
>  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, 1357 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
> 
> ---
> 
> Hello all,
> 
> Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.
> 
> Here is a version with a refactored init function without leaks in the failure
> patch. I also added a couple of comments to better understand the intention of
> that function. Besides, when there are no memory available, the function
> rolls back what ever thermal zones have been added.
> 
> Thanks,
> 
> Eduardo
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..6664533
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,498 @@
> +* 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 attachments: used to describe links between trip points and
> +cooling devices;

I think "attachments" sounds a bit odd, though I don't have a better
naming suggestion.

> +- thermal zones: used to describe thermal data within the hardware;
> +
> +It follows a description of each type of these device tree nodes.
> +
> +* Sensor devices
> +
> +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. Temperature sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #sensor-cells:       Used to provide sensor device specific information
> +                       while referring to it. Must be at least 1, 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.

I don't see why this needs to be at least one cell -- if an IC only has
one temperature sensor it should be fine for this to be zero and have no
ambiguity.

It may make sense to call these thermal sensor devices, there are plenty
of other sensors we might want to describe in the dt for other purposes,
and we can impose some consistency if we remove the ambiguity.

> +
> +* 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. 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 level of cooling.
> +
> +Required property:
> +- cooling-min-level:   A unsigned integer indicating the smallest
> +                       cooling level accepted. Typically 0.
> +- cooling-max-level:   An unsigned integer indicating the largest
> +                       cooling level accepted.

I'm not sure what a "cooling level" means. It seems a bit abstract. Is
this binding specific?

How does this relate to cooling-cells? These seem to be a fixed size.

> +- #cooling-cells:      Used to provide cooling device specific information
> +                       while referring to it. Must be at least 2, in order
> +                       to specify minimum and maximum cooling level used
> +                       in the reference. See Cooling device attachments section
> +                       below for more details on how consumers refer to
> +                       cooling devices.

Are these cooling cells always expected to cover min and max, and are
min and max always expected to take the same number of cells? The above
cooling-*-level properties imply they each take up one cell.

Does #cooling-cells = <3> make sense?. If this covers additional
information (e.g. which fan on a multi-fan controller), how does the OS
determine which cells are min and max, and how do these relate to
cooling-level-min and cooling-level-max?

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

I'm still not sure on this, as it sounds like embedding policy into the
DT, rather than a description of the hardware. I realise we need to
prevent devices burning out, so describing the max acceptable
temperature and possibly a preferred range makes sense, but do we need
this level of flexibility? Maybe we do.

> +
> +Required properties:
> +- temperature:         the trip temperature level, in milliCelsius.

Preferably, s/milliCelsius/millicelsius/ over the document.

Given that we have signed values elsewhere, is this signed or unsigned?

> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
> +                       relative value, in milliCelsius.
> +- type:                        the trip type. Here is the type mapping:
> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active cooling
> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable passive cooling
> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
> +
> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.

Why not use a string for this? We do so for other type parameters in
other bindings (see dr_mode in
Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
PHYs, etc).

> +
> +* Cooling device attachments
> +
> +The cooling device attachments 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 parameters,
> +                       referring to which cooling device is used in this
> +                       binding. The required parameters are: the minimum
> +                       cooling level and the maximum cooling level used
> +                       in this attach.

Might this be a list in general? The code doesn't have to support that
yet.

It would be nice to have a name for the cells after a phandle which
describe the cooling device's configuration. You've called them
parameters here, but it probably makes sense to call them a
cooling-specifier (following clock-specifier and interrupt-specifier).

> +- trip:                        A phandle of a trip point node within the same thermal
> +                       zone.
> +
> +Optional property:
> +- contribution:                The cooling contribution to the thermal zone of the
> +                       referred cooling device at the referred trip point.
> +                       The contribution is a value from 0 to 100. The sum
> +                       of all cooling contributions within a thermal zone
> +                       must never exceed 100.

This is a bit arbitrary. Couldn't we sum all contributions to find the
total automatically, so this could be a simpler ratio?

> +
> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
> +limit parameters means:
> +(i)   - minimum level allowed for minimum cooling level used in the reference.
> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> +
> +* Thermal zones
> +
> +The thermal-zone node is the node containing all the required info
> +for describing a thermal zone, including its cdev 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 attachments.

s/cdev/cooling device/ ?

> +
> +Required properties:
> +- passive-delay:       The maximum number of milliseconds to wait between polls
> +                       when performing passive cooling.
> +- polling-delay:       The maximum number of milliseconds to wait between polls
> +                       when checking this thermal zone.

How about polling-delay-passive, polling-delay-active? I'm still not

> +- sensors:             A list of sensor phandles and their parameters. The
> +                       required parameter is the sensor id, in order to
> +                       identify internal sensors when the sensor IC features
> +                       several sensing units.

As mentioned above, I'm not sure you even need that one cell.

- sensors:                A list of sensor phandle + thermal-sensor-specifier
                          cells describing the sensors monitoring the thermal
			  zone.

> +- trips:               A sub-node containing several trip point nodes required
> +                       to describe the thermal zone.
> +- cooling-attachments  A sub-node containing several cooling device attaches
> +                       nodes, used to describe the relation between trips
> +                       and cooling devices.
> +
> +Optional property:
> +- coefficients:                An array of integers (one signed cell) containing
> +                       coefficients to compose a linear relation between
> +                       the sensors described in the sensors property.
> +                       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.

What is the end result of this? Presumably this is meant to result in an
estimate of the average temperature of the thermal zone, rather than an
arbitrary value? This should be mentioned.

This doesn't seem to be used the in the code below...

> +
> +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 (passive-delay); 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.

I'm not sure what you mean by this, could you elaborate?

I guess you mean that the delays should be chosen to account for said
max dT/dt, such that a device can't unexpectedly cross several trip
boundaries between polls?

> +
> +* 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-level = <0>;
> +               cooling-max-level = <3>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };

What do those min and max mean in this context? What do the values in
the range [0,3] correspond to?

I'm not sure it makes sense to describe passive cooling in this way --
the precise way an OS does less work on a device is fundamentally tied
to the design of the OS (it might be able to rate-limit requests, it
might be able to clock the device down, it might only be able to turn
the device off).

I'm not sure there is anything we can describe for passive cooling
(beyond the thermal limits the OS should attempt to stick to).

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

What do min and max mean here for the fan?

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

How do the thermal zones get probed?

> +       passive-delay = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        sensors = <&bandgap0     0>;
> +
> +        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-attachments {
> +               attach0 {
> +                       trip = <&cpu-alert0>;
> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +               };
> +               attach1 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +               };
> +               attach2 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device =
> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
> +               };
> +       };

Was there a good reason for splitting trips and attachment?

> +};
> +
> +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, is used to remove the heat out of the thermal
> +zone 'cpu-thermal' using its cooling levels 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 level.
> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
> +passive cooling device, using all its cooling levels at trip point 'cpu-alert1',
> +which is a trip point at 100C.
> +

[...]

> +(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 {
> +               ...
> +               #sensor-cells = <1>;
> +       };
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +       passive-delay = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        sensors = <&bandgap0   0>,
> +                 <&adc         0>;
> +
> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
> +       coefficients =          <100    -120    484>;

Aha, so these are signed. This *must* be mentioned in the documentation.
The types of all properties should be described in their definition.

[...]

> +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");

This is the first instance of "thermal-zones" in this patch. Presumably
this is the container for thermal zones that allows them to be probed
(answering my question above). This *must* be described in the binding.

> +       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;
> +
> +               /* For now, thermal framework supports only 1 sensor per zone */
> +               ret = of_parse_phandle_with_args(child, "sensors",
> +                                                "#sensor-cells",
> +                                                0, &sensor_specs);
> +               if (ret)
> +                       continue;
> +
> +               if (sensor_specs.args_count < 1)
> +                       continue;

Why? I fail to see why a single sensor *must* have some configuration cells.

> +
> +               if (sensor_specs.np == sensor_np &&
> +                   sensor_specs.args[0] == 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);

[...]

> +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, "usage", &prop);

That wasn't described in the binding. Should this be reading the
"contribution" property?

> +       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];

Ah, so the first two cells are meant to be min and max, not any
arbitrary cells. Why is this necessary?

> +       } else {
> +               pr_err("wrong reference to cooling device, missing limits\n");
> +       }
> +
> +end:
> +       of_node_put(trip);
> +
> +       return ret;
> +}
> +
> +/**
> + * 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 = of_property_read_u32(np, "type", &prop);
> +       if (ret < 0) {
> +               pr_err("missing type property\n");
> +               return ret;
> +       }
> +       trip->type = prop;

No sanity checking?

I'd prefer a string and a table from string to Linux internal ID. Others
may have differing opinions.

> +
> +       /* Required for cooling attachment 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.
> + *
> + * 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, *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, "passive-delay", &prop);
> +       if (ret < 0) {
> +               pr_err("missing passive_delay property\n");

Inconsistent '-' and '_' between the parsing and the error.

> +               return ERR_PTR(ret);
> +       }
> +       tz->passive_delay = prop;
> +
> +       ret = of_property_read_u32(np, "polling-delay", &prop);
> +       if (ret < 0) {
> +               pr_err("missing polling_delay property\n");

Same here.

> +               return ERR_PTR(ret);
> +       }
> +       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);

What if there are no children, or this fails (returning zero)?

> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);

Here kzalloc could return ZERO_SIZE_PTR ((void*) 16). So the check below
isn't sufficient to stop us continuing if the node has no children. We
should check tz->ntrips above before calling kzalloc.

> +       if (!tz->trips)
> +               return ERR_PTR(-ENOMEM);
> +       i = 0;
> +       for_each_child_of_node(child, gchild)
> +               thermal_of_populate_trip(gchild, &tz->trips[i++]);

What if this fails for a child node?

> +
> +       of_node_put(child);
> +
> +       /* cooling-attachments */
> +       child = of_get_child_by_name(np, "cooling-attachments");
> +
> +       /* cooling-attachments provided */
> +       if (!child)
> +               goto finish;
> +
> +       tz->num_tbps = of_get_child_count(child);
> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
> +       if (!tz->tbps)
> +               return ERR_PTR(-ENOMEM);
> +       i = 0;
> +       for_each_child_of_node(child, gchild)
> +               thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
> +                                               tz->trips, tz->ntrips);
> +
> +finish:
> +       tz->mode = THERMAL_DEVICE_DISABLED;
> +
> +       return tz;
> +}

What about all that useless data we may have just allocated memory for?

[...]

> +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;

So each child of thermal-zones must be a thermal zone (we can't embed
other nodes of information)?

> +
> +               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;
> +}

Cheers,
Mark.

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Mark Rutland]

Hi Eduardo,

Apologies for having taken so long to get back you on this.

I have several comments on the binding and the way it's parsed.

On Wed, Sep 18, 2013 at 10:35:36PM +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>
> ---
>  .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>  drivers/thermal/Kconfig                            |  13 +
>  drivers/thermal/Makefile                           |   1 +
>  drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
>  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, 1357 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
> 
> ---
> 
> Hello all,
> 
> Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.
> 
> Here is a version with a refactored init function without leaks in the failure
> patch. I also added a couple of comments to better understand the intention of
> that function. Besides, when there are no memory available, the function
> rolls back what ever thermal zones have been added.
> 
> Thanks,
> 
> Eduardo
> 
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> new file mode 100644
> index 0000000..6664533
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -0,0 +1,498 @@
> +* 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 attachments: used to describe links between trip points and
> +cooling devices;

I think "attachments" sounds a bit odd, though I don't have a better
naming suggestion.

> +- thermal zones: used to describe thermal data within the hardware;
> +
> +It follows a description of each type of these device tree nodes.
> +
> +* Sensor devices
> +
> +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. Temperature sensor devices may
> +control one or more internal sensors.
> +
> +Required property:
> +- #sensor-cells:       Used to provide sensor device specific information
> +                       while referring to it. Must be at least 1, 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.

I don't see why this needs to be at least one cell -- if an IC only has
one temperature sensor it should be fine for this to be zero and have no
ambiguity.

It may make sense to call these thermal sensor devices, there are plenty
of other sensors we might want to describe in the dt for other purposes,
and we can impose some consistency if we remove the ambiguity.

> +
> +* 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. 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 level of cooling.
> +
> +Required property:
> +- cooling-min-level:   A unsigned integer indicating the smallest
> +                       cooling level accepted. Typically 0.
> +- cooling-max-level:   An unsigned integer indicating the largest
> +                       cooling level accepted.

I'm not sure what a "cooling level" means. It seems a bit abstract. Is
this binding specific?

How does this relate to cooling-cells? These seem to be a fixed size.

> +- #cooling-cells:      Used to provide cooling device specific information
> +                       while referring to it. Must be at least 2, in order
> +                       to specify minimum and maximum cooling level used
> +                       in the reference. See Cooling device attachments section
> +                       below for more details on how consumers refer to
> +                       cooling devices.

Are these cooling cells always expected to cover min and max, and are
min and max always expected to take the same number of cells? The above
cooling-*-level properties imply they each take up one cell.

Does #cooling-cells = <3> make sense?. If this covers additional
information (e.g. which fan on a multi-fan controller), how does the OS
determine which cells are min and max, and how do these relate to
cooling-level-min and cooling-level-max?

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

I'm still not sure on this, as it sounds like embedding policy into the
DT, rather than a description of the hardware. I realise we need to
prevent devices burning out, so describing the max acceptable
temperature and possibly a preferred range makes sense, but do we need
this level of flexibility? Maybe we do.

> +
> +Required properties:
> +- temperature:         the trip temperature level, in milliCelsius.

Preferably, s/milliCelsius/millicelsius/ over the document.

Given that we have signed values elsewhere, is this signed or unsigned?

> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
> +                       relative value, in milliCelsius.
> +- type:                        the trip type. Here is the type mapping:
> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active cooling
> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable passive cooling
> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
> +
> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.

Why not use a string for this? We do so for other type parameters in
other bindings (see dr_mode in
Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
PHYs, etc).

> +
> +* Cooling device attachments
> +
> +The cooling device attachments 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 parameters,
> +                       referring to which cooling device is used in this
> +                       binding. The required parameters are: the minimum
> +                       cooling level and the maximum cooling level used
> +                       in this attach.

Might this be a list in general? The code doesn't have to support that
yet.

It would be nice to have a name for the cells after a phandle which
describe the cooling device's configuration. You've called them
parameters here, but it probably makes sense to call them a
cooling-specifier (following clock-specifier and interrupt-specifier).

> +- trip:                        A phandle of a trip point node within the same thermal
> +                       zone.
> +
> +Optional property:
> +- contribution:                The cooling contribution to the thermal zone of the
> +                       referred cooling device at the referred trip point.
> +                       The contribution is a value from 0 to 100. The sum
> +                       of all cooling contributions within a thermal zone
> +                       must never exceed 100.

This is a bit arbitrary. Couldn't we sum all contributions to find the
total automatically, so this could be a simpler ratio?

> +
> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
> +limit parameters means:
> +(i)   - minimum level allowed for minimum cooling level used in the reference.
> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
> +
> +* Thermal zones
> +
> +The thermal-zone node is the node containing all the required info
> +for describing a thermal zone, including its cdev 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 attachments.

s/cdev/cooling device/ ?

> +
> +Required properties:
> +- passive-delay:       The maximum number of milliseconds to wait between polls
> +                       when performing passive cooling.
> +- polling-delay:       The maximum number of milliseconds to wait between polls
> +                       when checking this thermal zone.

How about polling-delay-passive, polling-delay-active? I'm still not

> +- sensors:             A list of sensor phandles and their parameters. The
> +                       required parameter is the sensor id, in order to
> +                       identify internal sensors when the sensor IC features
> +                       several sensing units.

As mentioned above, I'm not sure you even need that one cell.

- sensors:                A list of sensor phandle + thermal-sensor-specifier
                          cells describing the sensors monitoring the thermal
			  zone.

> +- trips:               A sub-node containing several trip point nodes required
> +                       to describe the thermal zone.
> +- cooling-attachments  A sub-node containing several cooling device attaches
> +                       nodes, used to describe the relation between trips
> +                       and cooling devices.
> +
> +Optional property:
> +- coefficients:                An array of integers (one signed cell) containing
> +                       coefficients to compose a linear relation between
> +                       the sensors described in the sensors property.
> +                       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.

What is the end result of this? Presumably this is meant to result in an
estimate of the average temperature of the thermal zone, rather than an
arbitrary value? This should be mentioned.

This doesn't seem to be used the in the code below...

> +
> +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 (passive-delay); 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.

I'm not sure what you mean by this, could you elaborate?

I guess you mean that the delays should be chosen to account for said
max dT/dt, such that a device can't unexpectedly cross several trip
boundaries between polls?

> +
> +* 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-level = <0>;
> +               cooling-max-level = <3>;
> +               #cooling-cells = <2>; /* min followed by max */
> +       };

What do those min and max mean in this context? What do the values in
the range [0,3] correspond to?

I'm not sure it makes sense to describe passive cooling in this way --
the precise way an OS does less work on a device is fundamentally tied
to the design of the OS (it might be able to rate-limit requests, it
might be able to clock the device down, it might only be able to turn
the device off).

I'm not sure there is anything we can describe for passive cooling
(beyond the thermal limits the OS should attempt to stick to).

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

What do min and max mean here for the fan?

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

How do the thermal zones get probed?

> +       passive-delay = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        sensors = <&bandgap0     0>;
> +
> +        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-attachments {
> +               attach0 {
> +                       trip = <&cpu-alert0>;
> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
> +               };
> +               attach1 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
> +               };
> +               attach2 {
> +                       trip = <&cpu-alert1>;
> +                       cooling-device > +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
> +               };
> +       };

Was there a good reason for splitting trips and attachment?

> +};
> +
> +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, is used to remove the heat out of the thermal
> +zone 'cpu-thermal' using its cooling levels 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 level.
> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
> +passive cooling device, using all its cooling levels at trip point 'cpu-alert1',
> +which is a trip point at 100C.
> +

[...]

> +(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 {
> +               ...
> +               #sensor-cells = <1>;
> +       };
> +};
> +
> +bandgap0: bandgap@0x0000ED00 {
> +       ...
> +       #sensor-cells = <1>;
> +};
> +
> +cpu-thermal: cpu-thermal {
> +       passive-delay = <250>; /* milliseconds */
> +       polling-delay = <1000>; /* milliseconds */
> +
> +               /* sensor       ID */
> +        sensors = <&bandgap0   0>,
> +                 <&adc         0>;
> +
> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
> +       coefficients =          <100    -120    484>;

Aha, so these are signed. This *must* be mentioned in the documentation.
The types of all properties should be described in their definition.

[...]

> +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");

This is the first instance of "thermal-zones" in this patch. Presumably
this is the container for thermal zones that allows them to be probed
(answering my question above). This *must* be described in the binding.

> +       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;
> +
> +               /* For now, thermal framework supports only 1 sensor per zone */
> +               ret = of_parse_phandle_with_args(child, "sensors",
> +                                                "#sensor-cells",
> +                                                0, &sensor_specs);
> +               if (ret)
> +                       continue;
> +
> +               if (sensor_specs.args_count < 1)
> +                       continue;

Why? I fail to see why a single sensor *must* have some configuration cells.

> +
> +               if (sensor_specs.np = sensor_np &&
> +                   sensor_specs.args[0] = 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);

[...]

> +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, "usage", &prop);

That wasn't described in the binding. Should this be reading the
"contribution" property?

> +       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];

Ah, so the first two cells are meant to be min and max, not any
arbitrary cells. Why is this necessary?

> +       } else {
> +               pr_err("wrong reference to cooling device, missing limits\n");
> +       }
> +
> +end:
> +       of_node_put(trip);
> +
> +       return ret;
> +}
> +
> +/**
> + * 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 = of_property_read_u32(np, "type", &prop);
> +       if (ret < 0) {
> +               pr_err("missing type property\n");
> +               return ret;
> +       }
> +       trip->type = prop;

No sanity checking?

I'd prefer a string and a table from string to Linux internal ID. Others
may have differing opinions.

> +
> +       /* Required for cooling attachment 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.
> + *
> + * 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, *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, "passive-delay", &prop);
> +       if (ret < 0) {
> +               pr_err("missing passive_delay property\n");

Inconsistent '-' and '_' between the parsing and the error.

> +               return ERR_PTR(ret);
> +       }
> +       tz->passive_delay = prop;
> +
> +       ret = of_property_read_u32(np, "polling-delay", &prop);
> +       if (ret < 0) {
> +               pr_err("missing polling_delay property\n");

Same here.

> +               return ERR_PTR(ret);
> +       }
> +       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);

What if there are no children, or this fails (returning zero)?

> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);

Here kzalloc could return ZERO_SIZE_PTR ((void*) 16). So the check below
isn't sufficient to stop us continuing if the node has no children. We
should check tz->ntrips above before calling kzalloc.

> +       if (!tz->trips)
> +               return ERR_PTR(-ENOMEM);
> +       i = 0;
> +       for_each_child_of_node(child, gchild)
> +               thermal_of_populate_trip(gchild, &tz->trips[i++]);

What if this fails for a child node?

> +
> +       of_node_put(child);
> +
> +       /* cooling-attachments */
> +       child = of_get_child_by_name(np, "cooling-attachments");
> +
> +       /* cooling-attachments provided */
> +       if (!child)
> +               goto finish;
> +
> +       tz->num_tbps = of_get_child_count(child);
> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
> +       if (!tz->tbps)
> +               return ERR_PTR(-ENOMEM);
> +       i = 0;
> +       for_each_child_of_node(child, gchild)
> +               thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
> +                                               tz->trips, tz->ntrips);
> +
> +finish:
> +       tz->mode = THERMAL_DEVICE_DISABLED;
> +
> +       return tz;
> +}

What about all that useless data we may have just allocated memory for?

[...]

> +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;

So each child of thermal-zones must be a thermal zone (we can't embed
other nodes of information)?

> +
> +               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;
> +}

Cheers,
Mark.

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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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



On 23-09-2013 06:40, Mark Rutland wrote:
> Hi Eduardo,
> 

Hi Mark,

> Apologies for having taken so long to get back you on this.
> 

Well, at least we are keeping it up somehow. I just would like to have
an agreement, at least for the binding part, as I mentioned before.

> I have several comments on the binding and the way it's parsed.

OK. I will try to clarify that.

> 
> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
>>  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, 1357 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
>>
>> ---
>>
>> Hello all,
>>
>> Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.
>>
>> Here is a version with a refactored init function without leaks in the failure
>> patch. I also added a couple of comments to better understand the intention of
>> that function. Besides, when there are no memory available, the function
>> rolls back what ever thermal zones have been added.
>>
>> Thanks,
>>
>> Eduardo
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..6664533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,498 @@
>> +* 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 attachments: used to describe links between trip points and
>> +cooling devices;
> 
> I think "attachments" sounds a bit odd, though I don't have a better
> naming suggestion.

I understand. But I also could not find a better naming. We use the term
'cooling binding'. However, while rewriting and rereading this binding
document  I realized that the 'binding' term could be confused between
'cooling binding' and 'device tree binding'. So I chose to use another
name and 'attachments' as the best I could come out with :-). I am open
to suggestions here, if you have something better.

> 
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
>> +
>> +* Sensor devices
>> +
>> +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. Temperature sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #sensor-cells:       Used to provide sensor device specific information
>> +                       while referring to it. Must be at least 1, 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.
> 
> I don't see why this needs to be at least one cell -- if an IC only has
> one temperature sensor it should be fine for this to be zero and have no
> ambiguity.

Well, idea was to have all these entries uniform. Besides, making sure
one has added a #sensor-cells entry to a device tree node seams to be
sign that the writer of that node really wants it to be a temperature
sensor used within this type of binding.

> 
> It may make sense to call these thermal sensor devices, there are plenty
> of other sensors we might want to describe in the dt for other purposes,
> and we can impose some consistency if we remove the ambiguity.

Sounds fair to me.

> 
>> +
>> +* 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. 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 level of cooling.
>> +
>> +Required property:
>> +- cooling-min-level:   A unsigned integer indicating the smallest
>> +                       cooling level accepted. Typically 0.
>> +- cooling-max-level:   An unsigned integer indicating the largest
>> +                       cooling level accepted.
> 
> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
> this binding specific?

It is just a state to describe the level of cooling provided. I tried to
explained it in the above paragraph, but based on your comment, it was
not enough :-).

A fan device may come with three different speeds. Then it would be seen
as having three cooling levels. Similarly, a cpu may come with four
operating points (predefined pairs of voltage and frequency set), then
it would be seen as having four cooling levels. Pretty straight forward.

> 
> How does this relate to cooling-cells? These seem to be a fixed size.
> 

The cooling cells was simply to say which levels would be used. E.g. If
a cpu has 10 different operating points, at a certain trip point, the
designer may choose only the 6th until the 10th operating point
available to cool off the thermal zone.

>> +- #cooling-cells:      Used to provide cooling device specific information
>> +                       while referring to it. Must be at least 2, in order
>> +                       to specify minimum and maximum cooling level used
>> +                       in the reference. See Cooling device attachments section
>> +                       below for more details on how consumers refer to
>> +                       cooling devices.
> 
> Are these cooling cells always expected to cover min and max, and are
> min and max always expected to take the same number of cells? The above
> cooling-*-level properties imply they each take up one cell.

Yes, they take only one cell. And yes, so far I see only one need so
far, to describe min and max level used while referring to the cooling
device.

> 
> Does #cooling-cells = <3> make sense?. If this covers additional
> information (e.g. which fan on a multi-fan controller), how does the OS
> determine which cells are min and max, and how do these relate to
> cooling-level-min and cooling-level-max?

Well, I haven't seen such case. But would make sense to me, yes. Not
that we would be using though.

> 
>> +
>> +* 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.
> 
> I'm still not sure on this, as it sounds like embedding policy into the
> DT, rather than a description of the hardware. I realise we need to

Why?

> prevent devices burning out, so describing the max acceptable
> temperature and possibly a preferred range makes sense, but do we need
> this level of flexibility? Maybe we do.
> 

Can you please be more specific? Any counter example on how to be less
flexible? I believe this shall give a good level of flexibility. Nothing
less than needed, and nothing that can open for abusing the notation.

>> +
>> +Required properties:
>> +- temperature:         the trip temperature level, in milliCelsius.
> 
> Preferably, s/milliCelsius/millicelsius/ over the document.
> 

No issues.

> Given that we have signed values elsewhere, is this signed or unsigned?


Signed. But withing the current code implementation, and design too, we
are concerned with high positive temperatures, not low negative
temperatures.

> 
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +                       relative value, in milliCelsius.
>> +- type:                        the trip type. Here is the type mapping:
>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active cooling
>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable passive cooling
>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>> +
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
> 
> Why not use a string for this? We do so for other type parameters in
> other bindings (see dr_mode in
> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
> PHYs, etc).

I think this is a matter of taste. I am not sure I see the advantage of
changing this to string constants. If it is the case of having better
readability, I would say we do not loose readability while using macros,
that is descriptive enough.

> 
>> +
>> +* Cooling device attachments
>> +
>> +The cooling device attachments 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 parameters,
>> +                       referring to which cooling device is used in this
>> +                       binding. The required parameters are: the minimum
>> +                       cooling level and the maximum cooling level used
>> +                       in this attach.
> 
> Might this be a list in general? The code doesn't have to support that
> yet.

Well, I thought of having a list at first, but then we would loose the
'contribution' property, which is specific to a cooling device, not to a
list of cooling devices.

> 
> It would be nice to have a name for the cells after a phandle which
> describe the cooling device's configuration. You've called them
> parameters here, but it probably makes sense to call them a
> cooling-specifier (following clock-specifier and interrupt-specifier).

I think I do not follow this suggestion properly. Can you please give an
example? The parameters I was referring to was just the min and max
cooling levels.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +                       zone.
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +                       referred cooling device at the referred trip point.
>> +                       The contribution is a value from 0 to 100. The sum
>> +                       of all cooling contributions within a thermal zone
>> +                       must never exceed 100.
> 
> This is a bit arbitrary. Couldn't we sum all contributions to find the
> total automatically, so this could be a simpler ratio?

Well, both representations do the job. I fail to see the advantage
between one and another.

> 
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit parameters means:
>> +(i)   - minimum level allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zones
>> +
>> +The thermal-zone node is the node containing all the required info
>> +for describing a thermal zone, including its cdev 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 attachments.
> 
> s/cdev/cooling device/ ?

Yes.

> 
>> +
>> +Required properties:
>> +- passive-delay:       The maximum number of milliseconds to wait between polls
>> +                       when performing passive cooling.
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +                       when checking this thermal zone.
> 
> How about polling-delay-passive, polling-delay-active? I'm still not

I am ok with the name suggestion

> 
>> +- sensors:             A list of sensor phandles and their parameters. The
>> +                       required parameter is the sensor id, in order to
>> +                       identify internal sensors when the sensor IC features
>> +                       several sensing units.
> 
> As mentioned above, I'm not sure you even need that one cell.

To make then uniform, as mentioned. Can you please give an example of
existing similar case, in which we simply avoid using #.*-cells?

> 
> - sensors:                A list of sensor phandle + thermal-sensor-specifier
>                           cells describing the sensors monitoring the thermal
> 			  zone.

I see your suggestion.

> 
>> +- trips:               A sub-node containing several trip point nodes required
>> +                       to describe the thermal zone.
>> +- cooling-attachments  A sub-node containing several cooling device attaches
>> +                       nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +                       coefficients to compose a linear relation between
>> +                       the sensors described in the sensors property.
>> +                       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.
> 
> What is the end result of this? Presumably this is meant to result in an
> estimate of the average temperature of the thermal zone, rather than an
> arbitrary value? This should be mentioned.

Well not exactly an average, but at least a linear relation, as already
mentioned. Not only that, but with the above property, one can use also
one single sensor + offset, which is a very common use case.

> 
> This doesn't seem to be used the in the code below...

It is in the TODO list. But you are right, it is not implemented.

> 
>> +
>> +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 (passive-delay); 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.
> 
> I'm not sure what you mean by this, could you elaborate?
> 
> I guess you mean that the delays should be chosen to account for said
> max dT/dt, such that a device can't unexpectedly cross several trip
> boundaries between polls?

Yes, that is exactly what I meant. And that is why I have been saying
that I see these polling values are part of hardware description. Worst
case is when device unexpectedly cross several trip boundaries between
polls without the system seeing, but also reaches temperature ranges
that compromise silicon lifetime or internal structures.

These is highly bound to maximum power delta that the circuitry may be
exposed to.

> 
>> +
>> +* 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-level = <0>;
>> +               cooling-max-level = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> 
> What do those min and max mean in this context? What do the values in
> the range [0,3] correspond to?

In the case the CPU is DVFS-capable, which is pretty common case these
days, they represent that the referred cpu has four possible operating
points. In this case, 0 means the maximum operating point, 3 means the
minimum operating point.

> 
> I'm not sure it makes sense to describe passive cooling in this way --
> the precise way an OS does less work on a device is fundamentally tied
> to the design of the OS (it might be able to rate-limit requests, it
> might be able to clock the device down, it might only be able to turn
> the device off).

No, this is not about the work the OS capability of doing work on a CPU.
This is more tied to the frequency and voltage available on a CPU. That
is, the hardware capability of cooling itself, in this case.

> 
> I'm not sure there is anything we can describe for passive cooling
> (beyond the thermal limits the OS should attempt to stick to).
> 

I am not sure what you mean here, same level of cooling applies for a
cpu capable of doing dvfs, for instance.

>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-level = <0>;
>> +               cooling-max-level = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> 
> What do min and max mean here for the fan?

speeds

> 
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
> 
> How do the thermal zones get probed?

Regarding the implementation for Linux, I proposed a function that
parses all of them, when the thermal framework is initialized. They will
be represented as thermal zone devices in the thermal framework. But
they will only be enabled when the sensor drivers register themselves to
the framework.

> 
>> +       passive-delay = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        sensors = <&bandgap0     0>;
>> +
>> +        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-attachments {
>> +               attach0 {
>> +                       trip = <&cpu-alert0>;
>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +               };
>> +               attach1 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +               };
>> +               attach2 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device =
>> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +               };
>> +       };
> 
> Was there a good reason for splitting trips and attachment?

Same reason I mentioned for not having a list of cooling devices in each
attachment, we could loose information specific to the attachment trip,
cooling device.

> 
>> +};
>> +
>> +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, is used to remove the heat out of the thermal
>> +zone 'cpu-thermal' using its cooling levels 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 level.
>> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
>> +passive cooling device, using all its cooling levels at trip point 'cpu-alert1',
>> +which is a trip point at 100C.
>> +
> 
> [...]
> 
>> +(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 {
>> +               ...
>> +               #sensor-cells = <1>;
>> +       };
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       passive-delay = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        sensors = <&bandgap0   0>,
>> +                 <&adc         0>;
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +       coefficients =          <100    -120    484>;
> 
> Aha, so these are signed. This *must* be mentioned in the documentation.
> The types of all properties should be described in their definition.
> 

OK.


> [...]
> 
>> +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");
> 
> This is the first instance of "thermal-zones" in this patch. Presumably
> this is the container for thermal zones that allows them to be probed
> (answering my question above). This *must* be described in the binding.

Hmm.. I am not sure I follow you properly. Are you asking me to mention
implementation details in the binding document (how thermal zones are
probed)?

> 
>> +       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;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "sensors",
>> +                                                "#sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count < 1)
>> +                       continue;
> 
> Why? I fail to see why a single sensor *must* have some configuration cells.

I guess by now you know my answer :-). Idea was to have all of them
uniform, but if you have an existing example that have this property
optional, then I can consider it.

> 
>> +
>> +               if (sensor_specs.np == sensor_np &&
>> +                   sensor_specs.args[0] == 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);
> 
> [...]
> 
>> +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, "usage", &prop);
> 
> That wasn't described in the binding. Should this be reading the
> "contribution" property?

Yes, this is my bad, it is supposed to be 'contribution'.

> 
>> +       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];
> 
> Ah, so the first two cells are meant to be min and max, not any
> arbitrary cells. Why is this necessary?

Same example I answered above, one cooling device that has 10 levels of
cooling can be used at trip point at 100C only from 6th to 10th cooling
level. And on different trip point, from 4th to 5th, and so on so forth...

> 
>> +       } else {
>> +               pr_err("wrong reference to cooling device, missing limits\n");
>> +       }
>> +
>> +end:
>> +       of_node_put(trip);
>> +
>> +       return ret;
>> +}
>> +
>> +/**
>> + * 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 = of_property_read_u32(np, "type", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing type property\n");
>> +               return ret;
>> +       }
>> +       trip->type = prop;
> 
> No sanity checking?
> 

Yes, I can added it.

> I'd prefer a string and a table from string to Linux internal ID. Others
> may have differing opinions.

I just fail to see any advantage of using string constants, as I already
mentioned.

> 
>> +
>> +       /* Required for cooling attachment 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.
>> + *
>> + * 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, *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, "passive-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing passive_delay property\n");
> 
> Inconsistent '-' and '_' between the parsing and the error.

Right! I will fix the message errors.

> 
>> +               return ERR_PTR(ret);
>> +       }
>> +       tz->passive_delay = prop;
>> +
>> +       ret = of_property_read_u32(np, "polling-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling_delay property\n");
> 
> Same here.


ok.

> 
>> +               return ERR_PTR(ret);
>> +       }
>> +       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);
> 
> What if there are no children, or this fails (returning zero)?

OK. I can add the check for zero children.

> 
>> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
> 
> Here kzalloc could return ZERO_SIZE_PTR ((void*) 16). So the check below
> isn't sufficient to stop us continuing if the node has no children. We
> should check tz->ntrips above before calling kzalloc.

got it. adding the check for zero children above.

> 
>> +       if (!tz->trips)
>> +               return ERR_PTR(-ENOMEM);
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               thermal_of_populate_trip(gchild, &tz->trips[i++]);
> 
> What if this fails for a child node?

I will add a check to avoid continuing. There is no sense to me to
continue with a child that is wrongly described.

> 
>> +
>> +       of_node_put(child);
>> +
>> +       /* cooling-attachments */
>> +       child = of_get_child_by_name(np, "cooling-attachments");
>> +
>> +       /* cooling-attachments provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->num_tbps = of_get_child_count(child);
>> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +       if (!tz->tbps)
>> +               return ERR_PTR(-ENOMEM);
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +                                               tz->trips, tz->ntrips);
>> +
>> +finish:
>> +       tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +       return tz;
>> +}
> 
> What about all that useless data we may have just allocated memory for?

Which useless data? The allocated data is used to hold the parsed data
which in turn is used to make the thermal zone device work properly.
They are freed when the thermal framework is unloaded, in which each
thermal zone device is unregistered and all related data is freed, see
the end of the file.

> 
> [...]
> 
>> +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;
> 
> So each child of thermal-zones must be a thermal zone (we can't embed
> other nodes of information)?

Yes, each child is a thermal zone. Well, I don't see which other
information you would embed in it.

> 
>> +
>> +               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;
>> +}
> 
> Cheers,
> Mark.


All best,

Eduardo
> 
> 


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

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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



On 23-09-2013 06:40, Mark Rutland wrote:
> Hi Eduardo,
> 

Hi Mark,

> Apologies for having taken so long to get back you on this.
> 

Well, at least we are keeping it up somehow. I just would like to have
an agreement, at least for the binding part, as I mentioned before.

> I have several comments on the binding and the way it's parsed.

OK. I will try to clarify that.

> 
> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>> ---
>>  .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>  drivers/thermal/Kconfig                            |  13 +
>>  drivers/thermal/Makefile                           |   1 +
>>  drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
>>  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, 1357 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
>>
>> ---
>>
>> Hello all,
>>
>> Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.
>>
>> Here is a version with a refactored init function without leaks in the failure
>> patch. I also added a couple of comments to better understand the intention of
>> that function. Besides, when there are no memory available, the function
>> rolls back what ever thermal zones have been added.
>>
>> Thanks,
>>
>> Eduardo
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..6664533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,498 @@
>> +* 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 attachments: used to describe links between trip points and
>> +cooling devices;
> 
> I think "attachments" sounds a bit odd, though I don't have a better
> naming suggestion.

I understand. But I also could not find a better naming. We use the term
'cooling binding'. However, while rewriting and rereading this binding
document  I realized that the 'binding' term could be confused between
'cooling binding' and 'device tree binding'. So I chose to use another
name and 'attachments' as the best I could come out with :-). I am open
to suggestions here, if you have something better.

> 
>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
>> +
>> +* Sensor devices
>> +
>> +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. Temperature sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #sensor-cells:       Used to provide sensor device specific information
>> +                       while referring to it. Must be at least 1, 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.
> 
> I don't see why this needs to be at least one cell -- if an IC only has
> one temperature sensor it should be fine for this to be zero and have no
> ambiguity.

Well, idea was to have all these entries uniform. Besides, making sure
one has added a #sensor-cells entry to a device tree node seams to be
sign that the writer of that node really wants it to be a temperature
sensor used within this type of binding.

> 
> It may make sense to call these thermal sensor devices, there are plenty
> of other sensors we might want to describe in the dt for other purposes,
> and we can impose some consistency if we remove the ambiguity.

Sounds fair to me.

> 
>> +
>> +* 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. 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 level of cooling.
>> +
>> +Required property:
>> +- cooling-min-level:   A unsigned integer indicating the smallest
>> +                       cooling level accepted. Typically 0.
>> +- cooling-max-level:   An unsigned integer indicating the largest
>> +                       cooling level accepted.
> 
> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
> this binding specific?

It is just a state to describe the level of cooling provided. I tried to
explained it in the above paragraph, but based on your comment, it was
not enough :-).

A fan device may come with three different speeds. Then it would be seen
as having three cooling levels. Similarly, a cpu may come with four
operating points (predefined pairs of voltage and frequency set), then
it would be seen as having four cooling levels. Pretty straight forward.

> 
> How does this relate to cooling-cells? These seem to be a fixed size.
> 

The cooling cells was simply to say which levels would be used. E.g. If
a cpu has 10 different operating points, at a certain trip point, the
designer may choose only the 6th until the 10th operating point
available to cool off the thermal zone.

>> +- #cooling-cells:      Used to provide cooling device specific information
>> +                       while referring to it. Must be at least 2, in order
>> +                       to specify minimum and maximum cooling level used
>> +                       in the reference. See Cooling device attachments section
>> +                       below for more details on how consumers refer to
>> +                       cooling devices.
> 
> Are these cooling cells always expected to cover min and max, and are
> min and max always expected to take the same number of cells? The above
> cooling-*-level properties imply they each take up one cell.

Yes, they take only one cell. And yes, so far I see only one need so
far, to describe min and max level used while referring to the cooling
device.

> 
> Does #cooling-cells = <3> make sense?. If this covers additional
> information (e.g. which fan on a multi-fan controller), how does the OS
> determine which cells are min and max, and how do these relate to
> cooling-level-min and cooling-level-max?

Well, I haven't seen such case. But would make sense to me, yes. Not
that we would be using though.

> 
>> +
>> +* 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.
> 
> I'm still not sure on this, as it sounds like embedding policy into the
> DT, rather than a description of the hardware. I realise we need to

Why?

> prevent devices burning out, so describing the max acceptable
> temperature and possibly a preferred range makes sense, but do we need
> this level of flexibility? Maybe we do.
> 

Can you please be more specific? Any counter example on how to be less
flexible? I believe this shall give a good level of flexibility. Nothing
less than needed, and nothing that can open for abusing the notation.

>> +
>> +Required properties:
>> +- temperature:         the trip temperature level, in milliCelsius.
> 
> Preferably, s/milliCelsius/millicelsius/ over the document.
> 

No issues.

> Given that we have signed values elsewhere, is this signed or unsigned?


Signed. But withing the current code implementation, and design too, we
are concerned with high positive temperatures, not low negative
temperatures.

> 
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +                       relative value, in milliCelsius.
>> +- type:                        the trip type. Here is the type mapping:
>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active cooling
>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable passive cooling
>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>> +
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
> 
> Why not use a string for this? We do so for other type parameters in
> other bindings (see dr_mode in
> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
> PHYs, etc).

I think this is a matter of taste. I am not sure I see the advantage of
changing this to string constants. If it is the case of having better
readability, I would say we do not loose readability while using macros,
that is descriptive enough.

> 
>> +
>> +* Cooling device attachments
>> +
>> +The cooling device attachments 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 parameters,
>> +                       referring to which cooling device is used in this
>> +                       binding. The required parameters are: the minimum
>> +                       cooling level and the maximum cooling level used
>> +                       in this attach.
> 
> Might this be a list in general? The code doesn't have to support that
> yet.

Well, I thought of having a list at first, but then we would loose the
'contribution' property, which is specific to a cooling device, not to a
list of cooling devices.

> 
> It would be nice to have a name for the cells after a phandle which
> describe the cooling device's configuration. You've called them
> parameters here, but it probably makes sense to call them a
> cooling-specifier (following clock-specifier and interrupt-specifier).

I think I do not follow this suggestion properly. Can you please give an
example? The parameters I was referring to was just the min and max
cooling levels.

> 
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +                       zone.
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +                       referred cooling device at the referred trip point.
>> +                       The contribution is a value from 0 to 100. The sum
>> +                       of all cooling contributions within a thermal zone
>> +                       must never exceed 100.
> 
> This is a bit arbitrary. Couldn't we sum all contributions to find the
> total automatically, so this could be a simpler ratio?

Well, both representations do the job. I fail to see the advantage
between one and another.

> 
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit parameters means:
>> +(i)   - minimum level allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zones
>> +
>> +The thermal-zone node is the node containing all the required info
>> +for describing a thermal zone, including its cdev 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 attachments.
> 
> s/cdev/cooling device/ ?

Yes.

> 
>> +
>> +Required properties:
>> +- passive-delay:       The maximum number of milliseconds to wait between polls
>> +                       when performing passive cooling.
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +                       when checking this thermal zone.
> 
> How about polling-delay-passive, polling-delay-active? I'm still not

I am ok with the name suggestion

> 
>> +- sensors:             A list of sensor phandles and their parameters. The
>> +                       required parameter is the sensor id, in order to
>> +                       identify internal sensors when the sensor IC features
>> +                       several sensing units.
> 
> As mentioned above, I'm not sure you even need that one cell.

To make then uniform, as mentioned. Can you please give an example of
existing similar case, in which we simply avoid using #.*-cells?

> 
> - sensors:                A list of sensor phandle + thermal-sensor-specifier
>                           cells describing the sensors monitoring the thermal
> 			  zone.

I see your suggestion.

> 
>> +- trips:               A sub-node containing several trip point nodes required
>> +                       to describe the thermal zone.
>> +- cooling-attachments  A sub-node containing several cooling device attaches
>> +                       nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +                       coefficients to compose a linear relation between
>> +                       the sensors described in the sensors property.
>> +                       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.
> 
> What is the end result of this? Presumably this is meant to result in an
> estimate of the average temperature of the thermal zone, rather than an
> arbitrary value? This should be mentioned.

Well not exactly an average, but at least a linear relation, as already
mentioned. Not only that, but with the above property, one can use also
one single sensor + offset, which is a very common use case.

> 
> This doesn't seem to be used the in the code below...

It is in the TODO list. But you are right, it is not implemented.

> 
>> +
>> +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 (passive-delay); 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.
> 
> I'm not sure what you mean by this, could you elaborate?
> 
> I guess you mean that the delays should be chosen to account for said
> max dT/dt, such that a device can't unexpectedly cross several trip
> boundaries between polls?

Yes, that is exactly what I meant. And that is why I have been saying
that I see these polling values are part of hardware description. Worst
case is when device unexpectedly cross several trip boundaries between
polls without the system seeing, but also reaches temperature ranges
that compromise silicon lifetime or internal structures.

These is highly bound to maximum power delta that the circuitry may be
exposed to.

> 
>> +
>> +* 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-level = <0>;
>> +               cooling-max-level = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> 
> What do those min and max mean in this context? What do the values in
> the range [0,3] correspond to?

In the case the CPU is DVFS-capable, which is pretty common case these
days, they represent that the referred cpu has four possible operating
points. In this case, 0 means the maximum operating point, 3 means the
minimum operating point.

> 
> I'm not sure it makes sense to describe passive cooling in this way --
> the precise way an OS does less work on a device is fundamentally tied
> to the design of the OS (it might be able to rate-limit requests, it
> might be able to clock the device down, it might only be able to turn
> the device off).

No, this is not about the work the OS capability of doing work on a CPU.
This is more tied to the frequency and voltage available on a CPU. That
is, the hardware capability of cooling itself, in this case.

> 
> I'm not sure there is anything we can describe for passive cooling
> (beyond the thermal limits the OS should attempt to stick to).
> 

I am not sure what you mean here, same level of cooling applies for a
cpu capable of doing dvfs, for instance.

>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-level = <0>;
>> +               cooling-max-level = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> 
> What do min and max mean here for the fan?

speeds

> 
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
> 
> How do the thermal zones get probed?

Regarding the implementation for Linux, I proposed a function that
parses all of them, when the thermal framework is initialized. They will
be represented as thermal zone devices in the thermal framework. But
they will only be enabled when the sensor drivers register themselves to
the framework.

> 
>> +       passive-delay = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        sensors = <&bandgap0     0>;
>> +
>> +        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-attachments {
>> +               attach0 {
>> +                       trip = <&cpu-alert0>;
>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +               };
>> +               attach1 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +               };
>> +               attach2 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device =
>> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +               };
>> +       };
> 
> Was there a good reason for splitting trips and attachment?

Same reason I mentioned for not having a list of cooling devices in each
attachment, we could loose information specific to the attachment trip,
cooling device.

> 
>> +};
>> +
>> +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, is used to remove the heat out of the thermal
>> +zone 'cpu-thermal' using its cooling levels 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 level.
>> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
>> +passive cooling device, using all its cooling levels at trip point 'cpu-alert1',
>> +which is a trip point at 100C.
>> +
> 
> [...]
> 
>> +(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 {
>> +               ...
>> +               #sensor-cells = <1>;
>> +       };
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
>> +       passive-delay = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        sensors = <&bandgap0   0>,
>> +                 <&adc         0>;
>> +
>> +               /* hotspot = 100 * bandgap - 120 * adc + 484 */
>> +       coefficients =          <100    -120    484>;
> 
> Aha, so these are signed. This *must* be mentioned in the documentation.
> The types of all properties should be described in their definition.
> 

OK.


> [...]
> 
>> +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");
> 
> This is the first instance of "thermal-zones" in this patch. Presumably
> this is the container for thermal zones that allows them to be probed
> (answering my question above). This *must* be described in the binding.

Hmm.. I am not sure I follow you properly. Are you asking me to mention
implementation details in the binding document (how thermal zones are
probed)?

> 
>> +       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;
>> +
>> +               /* For now, thermal framework supports only 1 sensor per zone */
>> +               ret = of_parse_phandle_with_args(child, "sensors",
>> +                                                "#sensor-cells",
>> +                                                0, &sensor_specs);
>> +               if (ret)
>> +                       continue;
>> +
>> +               if (sensor_specs.args_count < 1)
>> +                       continue;
> 
> Why? I fail to see why a single sensor *must* have some configuration cells.

I guess by now you know my answer :-). Idea was to have all of them
uniform, but if you have an existing example that have this property
optional, then I can consider it.

> 
>> +
>> +               if (sensor_specs.np == sensor_np &&
>> +                   sensor_specs.args[0] == 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);
> 
> [...]
> 
>> +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, "usage", &prop);
> 
> That wasn't described in the binding. Should this be reading the
> "contribution" property?

Yes, this is my bad, it is supposed to be 'contribution'.

> 
>> +       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];
> 
> Ah, so the first two cells are meant to be min and max, not any
> arbitrary cells. Why is this necessary?

Same example I answered above, one cooling device that has 10 levels of
cooling can be used at trip point at 100C only from 6th to 10th cooling
level. And on different trip point, from 4th to 5th, and so on so forth...

> 
>> +       } else {
>> +               pr_err("wrong reference to cooling device, missing limits\n");
>> +       }
>> +
>> +end:
>> +       of_node_put(trip);
>> +
>> +       return ret;
>> +}
>> +
>> +/**
>> + * 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 = of_property_read_u32(np, "type", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing type property\n");
>> +               return ret;
>> +       }
>> +       trip->type = prop;
> 
> No sanity checking?
> 

Yes, I can added it.

> I'd prefer a string and a table from string to Linux internal ID. Others
> may have differing opinions.

I just fail to see any advantage of using string constants, as I already
mentioned.

> 
>> +
>> +       /* Required for cooling attachment 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.
>> + *
>> + * 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, *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, "passive-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing passive_delay property\n");
> 
> Inconsistent '-' and '_' between the parsing and the error.

Right! I will fix the message errors.

> 
>> +               return ERR_PTR(ret);
>> +       }
>> +       tz->passive_delay = prop;
>> +
>> +       ret = of_property_read_u32(np, "polling-delay", &prop);
>> +       if (ret < 0) {
>> +               pr_err("missing polling_delay property\n");
> 
> Same here.


ok.

> 
>> +               return ERR_PTR(ret);
>> +       }
>> +       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);
> 
> What if there are no children, or this fails (returning zero)?

OK. I can add the check for zero children.

> 
>> +       tz->trips = kzalloc(tz->ntrips * sizeof(*tz->trips), GFP_KERNEL);
> 
> Here kzalloc could return ZERO_SIZE_PTR ((void*) 16). So the check below
> isn't sufficient to stop us continuing if the node has no children. We
> should check tz->ntrips above before calling kzalloc.

got it. adding the check for zero children above.

> 
>> +       if (!tz->trips)
>> +               return ERR_PTR(-ENOMEM);
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               thermal_of_populate_trip(gchild, &tz->trips[i++]);
> 
> What if this fails for a child node?

I will add a check to avoid continuing. There is no sense to me to
continue with a child that is wrongly described.

> 
>> +
>> +       of_node_put(child);
>> +
>> +       /* cooling-attachments */
>> +       child = of_get_child_by_name(np, "cooling-attachments");
>> +
>> +       /* cooling-attachments provided */
>> +       if (!child)
>> +               goto finish;
>> +
>> +       tz->num_tbps = of_get_child_count(child);
>> +       tz->tbps = kzalloc(tz->num_tbps * sizeof(*tz->tbps), GFP_KERNEL);
>> +       if (!tz->tbps)
>> +               return ERR_PTR(-ENOMEM);
>> +       i = 0;
>> +       for_each_child_of_node(child, gchild)
>> +               thermal_of_populate_bind_params(gchild, &tz->tbps[i++],
>> +                                               tz->trips, tz->ntrips);
>> +
>> +finish:
>> +       tz->mode = THERMAL_DEVICE_DISABLED;
>> +
>> +       return tz;
>> +}
> 
> What about all that useless data we may have just allocated memory for?

Which useless data? The allocated data is used to hold the parsed data
which in turn is used to make the thermal zone device work properly.
They are freed when the thermal framework is unloaded, in which each
thermal zone device is unregistered and all related data is freed, see
the end of the file.

> 
> [...]
> 
>> +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;
> 
> So each child of thermal-zones must be a thermal zone (we can't embed
> other nodes of information)?

Yes, each child is a thermal zone. Well, I don't see which other
information you would embed in it.

> 
>> +
>> +               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;
>> +}
> 
> Cheers,
> Mark.


All best,

Eduardo
> 
> 


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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/23/2013 06:40 PM, Mark Rutland wrote:
> Hi Eduardo,
>
> Apologies for having taken so long to get back you on this.
>
> I have several comments on the binding and the way it's parsed.
>
> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>> ---
>>   .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>   drivers/thermal/Kconfig                            |  13 +
>>   drivers/thermal/Makefile                           |   1 +
>>   drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
>>   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, 1357 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
>>
>> ---
>>
>> Hello all,
>>
>> Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.
>>
>> Here is a version with a refactored init function without leaks in the failure
>> patch. I also added a couple of comments to better understand the intention of
>> that function. Besides, when there are no memory available, the function
>> rolls back what ever thermal zones have been added.
>>
>> Thanks,
>>
>> Eduardo
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..6664533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,498 @@
>> +* 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 attachments: used to describe links between trip points and
>> +cooling devices;
> I think "attachments" sounds a bit odd, though I don't have a better
> naming suggestion.

"map" or "mapping" is better?

>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
>> +
>> +* Sensor devices
>> +
>> +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. Temperature sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #sensor-cells:       Used to provide sensor device specific information
>> +                       while referring to it. Must be at least 1, 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.
> I don't see why this needs to be at least one cell -- if an IC only has
> one temperature sensor it should be fine for this to be zero and have no
> ambiguity.
>
> It may make sense to call these thermal sensor devices, there are plenty
> of other sensors we might want to describe in the dt for other purposes,
> and we can impose some consistency if we remove the ambiguity.
>
>> +
>> +* 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. 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 level of cooling.
>> +
>> +Required property:
>> +- cooling-min-level:   A unsigned integer indicating the smallest
>> +                       cooling level accepted. Typically 0.
>> +- cooling-max-level:   An unsigned integer indicating the largest
>> +                       cooling level accepted.
> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
> this binding specific?

It means cooling ability of a cooling device, such as speed of a fan.
But it is better to use cooling-min/max-state I think, because the 
thermal management code is using "cooling state", concepts in dt and c 
should be identical.

> How does this relate to cooling-cells? These seem to be a fixed size.

I also think cooling-cells is redundant.

>> +- #cooling-cells:      Used to provide cooling device specific information
>> +                       while referring to it. Must be at least 2, in order
>> +                       to specify minimum and maximum cooling level used
>> +                       in the reference. See Cooling device attachments section
>> +                       below for more details on how consumers refer to
>> +                       cooling devices.
> Are these cooling cells always expected to cover min and max, and are
> min and max always expected to take the same number of cells? The above
> cooling-*-level properties imply they each take up one cell.
>
> Does #cooling-cells = <3> make sense?. If this covers additional
> information (e.g. which fan on a multi-fan controller), how does the OS
> determine which cells are min and max, and how do these relate to
> cooling-level-min and cooling-level-max?
>
>> +
>> +* 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.
> I'm still not sure on this, as it sounds like embedding policy into the
> DT, rather than a description of the hardware. I realise we need to
> prevent devices burning out, so describing the max acceptable
> temperature and possibly a preferred range makes sense, but do we need
> this level of flexibility? Maybe we do.
>
Putting platform data into dt is acceptable, right?
In a narrow sense, trip points are platform data, but in a broad sense, 
both trip point itself and its corresponding cooling device are all 
platform data.

>> +
>> +Required properties:
>> +- temperature:         the trip temperature level, in milliCelsius.
> Preferably, s/milliCelsius/millicelsius/ over the document.
>
> Given that we have signed values elsewhere, is this signed or unsigned?
>
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +                       relative value, in milliCelsius.
>> +- type:                        the trip type. Here is the type mapping:
>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active cooling
>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable passive cooling
>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>> +
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
> Why not use a string for this? We do so for other type parameters in
> other bindings (see dr_mode in
> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
> PHYs, etc).
>
>> +
>> +* Cooling device attachments
>> +
>> +The cooling device attachments 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 parameters,
>> +                       referring to which cooling device is used in this
>> +                       binding. The required parameters are: the minimum
>> +                       cooling level and the maximum cooling level used
>> +                       in this attach.
> Might this be a list in general? The code doesn't have to support that
> yet.
>
> It would be nice to have a name for the cells after a phandle which
> describe the cooling device's configuration. You've called them
> parameters here, but it probably makes sense to call them a
> cooling-specifier (following clock-specifier and interrupt-specifier).
>
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +                       zone.
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +                       referred cooling device at the referred trip point.
>> +                       The contribution is a value from 0 to 100. The sum
>> +                       of all cooling contributions within a thermal zone
>> +                       must never exceed 100.
> This is a bit arbitrary. Couldn't we sum all contributions to find the
> total automatically, so this could be a simpler ratio?
>
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit parameters means:
>> +(i)   - minimum level allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zones
>> +
>> +The thermal-zone node is the node containing all the required info
>> +for describing a thermal zone, including its cdev 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 attachments.
> s/cdev/cooling device/ ?
>
>> +
>> +Required properties:
>> +- passive-delay:       The maximum number of milliseconds to wait between polls
>> +                       when performing passive cooling.
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +                       when checking this thermal zone.
> How about polling-delay-passive, polling-delay-active? I'm still not
>
>> +- sensors:             A list of sensor phandles and their parameters. The
>> +                       required parameter is the sensor id, in order to
>> +                       identify internal sensors when the sensor IC features
>> +                       several sensing units.
> As mentioned above, I'm not sure you even need that one cell.
>
> - sensors:                A list of sensor phandle + thermal-sensor-specifier
>                            cells describing the sensors monitoring the thermal
> 			  zone.
>
>> +- trips:               A sub-node containing several trip point nodes required
>> +                       to describe the thermal zone.
>> +- cooling-attachments  A sub-node containing several cooling device attaches
>> +                       nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +                       coefficients to compose a linear relation between
>> +                       the sensors described in the sensors property.
>> +                       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.
> What is the end result of this? Presumably this is meant to result in an
> estimate of the average temperature of the thermal zone, rather than an
> arbitrary value? This should be mentioned.
>
> This doesn't seem to be used the in the code below...
>
>> +
>> +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 (passive-delay); 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.
> I'm not sure what you mean by this, could you elaborate?
>
> I guess you mean that the delays should be chosen to account for said
> max dT/dt, such that a device can't unexpectedly cross several trip
> boundaries between polls?
>
>> +
>> +* 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-level = <0>;
>> +               cooling-max-level = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> What do those min and max mean in this context? What do the values in
> the range [0,3] correspond to?
>
> I'm not sure it makes sense to describe passive cooling in this way --
> the precise way an OS does less work on a device is fundamentally tied
> to the design of the OS (it might be able to rate-limit requests, it
> might be able to clock the device down, it might only be able to turn
> the device off).
>
> I'm not sure there is anything we can describe for passive cooling
> (beyond the thermal limits the OS should attempt to stick to).
>
>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-level = <0>;
>> +               cooling-max-level = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> What do min and max mean here for the fan?
>
It means the speed level of a fan. Even if a fan can run at a continuous 
speed range, but when it is controlled under thermal management 
framework, it can only run at discrete speeds.
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
> How do the thermal zones get probed?
>
>> +       passive-delay = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        sensors = <&bandgap0     0>;
>> +
>> +        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-attachments {
>> +               attach0 {
>> +                       trip = <&cpu-alert0>;
>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +               };
>> +               attach1 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +               };
>> +               attach2 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device =
>> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +               };
>> +       };
> Was there a good reason for splitting trips and attachment?

This is for adding/removing cooling device dynamically.

>> +};
>> +
>> +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, is used to remove the heat out of the thermal
>> +zone 'cpu-thermal' using its cooling levels 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 level.
>> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
>> +passive cooling device, using all its cooling levels at trip point 'cpu-alert1',
>> +which is a trip point at 100C.
>> +
>

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/23/2013 06:40 PM, Mark Rutland wrote:
> Hi Eduardo,
>
> Apologies for having taken so long to get back you on this.
>
> I have several comments on the binding and the way it's parsed.
>
> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>> ---
>>   .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>   drivers/thermal/Kconfig                            |  13 +
>>   drivers/thermal/Makefile                           |   1 +
>>   drivers/thermal/of-thermal.c                       | 775 +++++++++++++++++++++
>>   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, 1357 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
>>
>> ---
>>
>> Hello all,
>>
>> Thanks Joe Perches for the effort of reviewing this code, I really appreciate it.
>>
>> Here is a version with a refactored init function without leaks in the failure
>> patch. I also added a couple of comments to better understand the intention of
>> that function. Besides, when there are no memory available, the function
>> rolls back what ever thermal zones have been added.
>>
>> Thanks,
>>
>> Eduardo
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
>> new file mode 100644
>> index 0000000..6664533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -0,0 +1,498 @@
>> +* 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 attachments: used to describe links between trip points and
>> +cooling devices;
> I think "attachments" sounds a bit odd, though I don't have a better
> naming suggestion.

"map" or "mapping" is better?

>> +- thermal zones: used to describe thermal data within the hardware;
>> +
>> +It follows a description of each type of these device tree nodes.
>> +
>> +* Sensor devices
>> +
>> +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. Temperature sensor devices may
>> +control one or more internal sensors.
>> +
>> +Required property:
>> +- #sensor-cells:       Used to provide sensor device specific information
>> +                       while referring to it. Must be at least 1, 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.
> I don't see why this needs to be at least one cell -- if an IC only has
> one temperature sensor it should be fine for this to be zero and have no
> ambiguity.
>
> It may make sense to call these thermal sensor devices, there are plenty
> of other sensors we might want to describe in the dt for other purposes,
> and we can impose some consistency if we remove the ambiguity.
>
>> +
>> +* 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. 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 level of cooling.
>> +
>> +Required property:
>> +- cooling-min-level:   A unsigned integer indicating the smallest
>> +                       cooling level accepted. Typically 0.
>> +- cooling-max-level:   An unsigned integer indicating the largest
>> +                       cooling level accepted.
> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
> this binding specific?

It means cooling ability of a cooling device, such as speed of a fan.
But it is better to use cooling-min/max-state I think, because the 
thermal management code is using "cooling state", concepts in dt and c 
should be identical.

> How does this relate to cooling-cells? These seem to be a fixed size.

I also think cooling-cells is redundant.

>> +- #cooling-cells:      Used to provide cooling device specific information
>> +                       while referring to it. Must be at least 2, in order
>> +                       to specify minimum and maximum cooling level used
>> +                       in the reference. See Cooling device attachments section
>> +                       below for more details on how consumers refer to
>> +                       cooling devices.
> Are these cooling cells always expected to cover min and max, and are
> min and max always expected to take the same number of cells? The above
> cooling-*-level properties imply they each take up one cell.
>
> Does #cooling-cells = <3> make sense?. If this covers additional
> information (e.g. which fan on a multi-fan controller), how does the OS
> determine which cells are min and max, and how do these relate to
> cooling-level-min and cooling-level-max?
>
>> +
>> +* 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.
> I'm still not sure on this, as it sounds like embedding policy into the
> DT, rather than a description of the hardware. I realise we need to
> prevent devices burning out, so describing the max acceptable
> temperature and possibly a preferred range makes sense, but do we need
> this level of flexibility? Maybe we do.
>
Putting platform data into dt is acceptable, right?
In a narrow sense, trip points are platform data, but in a broad sense, 
both trip point itself and its corresponding cooling device are all 
platform data.

>> +
>> +Required properties:
>> +- temperature:         the trip temperature level, in milliCelsius.
> Preferably, s/milliCelsius/millicelsius/ over the document.
>
> Given that we have signed values elsewhere, is this signed or unsigned?
>
>> +- hysteresis:          a (low) hysteresis value on 'temperature'. This is a
>> +                       relative value, in milliCelsius.
>> +- type:                        the trip type. Here is the type mapping:
>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active cooling
>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable passive cooling
>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>> +
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of these consts.
> Why not use a string for this? We do so for other type parameters in
> other bindings (see dr_mode in
> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
> PHYs, etc).
>
>> +
>> +* Cooling device attachments
>> +
>> +The cooling device attachments 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 parameters,
>> +                       referring to which cooling device is used in this
>> +                       binding. The required parameters are: the minimum
>> +                       cooling level and the maximum cooling level used
>> +                       in this attach.
> Might this be a list in general? The code doesn't have to support that
> yet.
>
> It would be nice to have a name for the cells after a phandle which
> describe the cooling device's configuration. You've called them
> parameters here, but it probably makes sense to call them a
> cooling-specifier (following clock-specifier and interrupt-specifier).
>
>> +- trip:                        A phandle of a trip point node within the same thermal
>> +                       zone.
>> +
>> +Optional property:
>> +- contribution:                The cooling contribution to the thermal zone of the
>> +                       referred cooling device at the referred trip point.
>> +                       The contribution is a value from 0 to 100. The sum
>> +                       of all cooling contributions within a thermal zone
>> +                       must never exceed 100.
> This is a bit arbitrary. Couldn't we sum all contributions to find the
> total automatically, so this could be a simpler ratio?
>
>> +
>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the cooling-device phandle
>> +limit parameters means:
>> +(i)   - minimum level allowed for minimum cooling level used in the reference.
>> +(ii)  - maximum level allowed for maximum cooling level used in the reference.
>> +Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
>> +
>> +* Thermal zones
>> +
>> +The thermal-zone node is the node containing all the required info
>> +for describing a thermal zone, including its cdev 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 attachments.
> s/cdev/cooling device/ ?
>
>> +
>> +Required properties:
>> +- passive-delay:       The maximum number of milliseconds to wait between polls
>> +                       when performing passive cooling.
>> +- polling-delay:       The maximum number of milliseconds to wait between polls
>> +                       when checking this thermal zone.
> How about polling-delay-passive, polling-delay-active? I'm still not
>
>> +- sensors:             A list of sensor phandles and their parameters. The
>> +                       required parameter is the sensor id, in order to
>> +                       identify internal sensors when the sensor IC features
>> +                       several sensing units.
> As mentioned above, I'm not sure you even need that one cell.
>
> - sensors:                A list of sensor phandle + thermal-sensor-specifier
>                            cells describing the sensors monitoring the thermal
> 			  zone.
>
>> +- trips:               A sub-node containing several trip point nodes required
>> +                       to describe the thermal zone.
>> +- cooling-attachments  A sub-node containing several cooling device attaches
>> +                       nodes, used to describe the relation between trips
>> +                       and cooling devices.
>> +
>> +Optional property:
>> +- coefficients:                An array of integers (one signed cell) containing
>> +                       coefficients to compose a linear relation between
>> +                       the sensors described in the sensors property.
>> +                       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.
> What is the end result of this? Presumably this is meant to result in an
> estimate of the average temperature of the thermal zone, rather than an
> arbitrary value? This should be mentioned.
>
> This doesn't seem to be used the in the code below...
>
>> +
>> +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 (passive-delay); 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.
> I'm not sure what you mean by this, could you elaborate?
>
> I guess you mean that the delays should be chosen to account for said
> max dT/dt, such that a device can't unexpectedly cross several trip
> boundaries between polls?
>
>> +
>> +* 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-level = <0>;
>> +               cooling-max-level = <3>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> What do those min and max mean in this context? What do the values in
> the range [0,3] correspond to?
>
> I'm not sure it makes sense to describe passive cooling in this way --
> the precise way an OS does less work on a device is fundamentally tied
> to the design of the OS (it might be able to rate-limit requests, it
> might be able to clock the device down, it might only be able to turn
> the device off).
>
> I'm not sure there is anything we can describe for passive cooling
> (beyond the thermal limits the OS should attempt to stick to).
>
>> +       ...
>> +};
>> +
>> +&i2c1 {
>> +       ...
>> +       fan0: fan@0x48 {
>> +               ...
>> +               cooling-min-level = <0>;
>> +               cooling-max-level = <9>;
>> +               #cooling-cells = <2>; /* min followed by max */
>> +       };
> What do min and max mean here for the fan?
>
It means the speed level of a fan. Even if a fan can run at a continuous 
speed range, but when it is controlled under thermal management 
framework, it can only run at discrete speeds.
>> +};
>> +
>> +bandgap0: bandgap@0x0000ED00 {
>> +       ...
>> +       #sensor-cells = <1>;
>> +};
>> +
>> +cpu-thermal: cpu-thermal {
> How do the thermal zones get probed?
>
>> +       passive-delay = <250>; /* milliseconds */
>> +       polling-delay = <1000>; /* milliseconds */
>> +
>> +               /* sensor       ID */
>> +        sensors = <&bandgap0     0>;
>> +
>> +        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-attachments {
>> +               attach0 {
>> +                       trip = <&cpu-alert0>;
>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>> +               };
>> +               attach1 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>> +               };
>> +               attach2 {
>> +                       trip = <&cpu-alert1>;
>> +                       cooling-device >> +                               <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
>> +               };
>> +       };
> Was there a good reason for splitting trips and attachment?

This is for adding/removing cooling device dynamically.

>> +};
>> +
>> +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, is used to remove the heat out of the thermal
>> +zone 'cpu-thermal' using its cooling levels 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 level.
>> +The cpu@0 device is also linked to the same thermal zone, 'cpu-thermal', as a
>> +passive cooling device, using all its cooling levels at trip point 'cpu-alert1',
>> +which is a trip point at 100C.
>> +
>




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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

Zhang,

I appreciate your interest. I am replying a couple of your comments.
Please also check my answers to Mark's queries on other email thread.

On 24-09-2013 04:11, Hongbo Zhang wrote:
> On 09/23/2013 06:40 PM, Mark Rutland wrote:
>> Hi Eduardo,
>>
>> Apologies for having taken so long to get back you on this.
>>
>> I have several comments on the binding and the way it's parsed.
>>
>> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>>> ---
>>>   .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>>   drivers/thermal/Kconfig                            |  13 +
>>>   drivers/thermal/Makefile                           |   1 +
>>>   drivers/thermal/of-thermal.c                       | 775
>>> +++++++++++++++++++++
>>>   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, 1357 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
>>>
>>> ---
>>>
>>> Hello all,
>>>
>>> Thanks Joe Perches for the effort of reviewing this code, I really
>>> appreciate it.
>>>
>>> Here is a version with a refactored init function without leaks in
>>> the failure
>>> patch. I also added a couple of comments to better understand the
>>> intention of
>>> that function. Besides, when there are no memory available, the function
>>> rolls back what ever thermal zones have been added.
>>>
>>> Thanks,
>>>
>>> Eduardo
>>>
>>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
>>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>>> new file mode 100644
>>> index 0000000..6664533
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>>> @@ -0,0 +1,498 @@
>>> +* 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 attachments: used to describe links between trip points and
>>> +cooling devices;
>> I think "attachments" sounds a bit odd, though I don't have a better
>> naming suggestion.
> 
> "map" or "mapping" is better?

Well,  yeah, that could work.

> 
>>> +- thermal zones: used to describe thermal data within the hardware;
>>> +
>>> +It follows a description of each type of these device tree nodes.
>>> +
>>> +* Sensor devices
>>> +
>>> +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. Temperature sensor
>>> devices may
>>> +control one or more internal sensors.
>>> +
>>> +Required property:
>>> +- #sensor-cells:       Used to provide sensor device specific
>>> information
>>> +                       while referring to it. Must be at least 1, 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.
>> I don't see why this needs to be at least one cell -- if an IC only has
>> one temperature sensor it should be fine for this to be zero and have no
>> ambiguity.
>>
>> It may make sense to call these thermal sensor devices, there are plenty
>> of other sensors we might want to describe in the dt for other purposes,
>> and we can impose some consistency if we remove the ambiguity.
>>
>>> +
>>> +* 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. 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 level of cooling.
>>> +
>>> +Required property:
>>> +- cooling-min-level:   A unsigned integer indicating the smallest
>>> +                       cooling level accepted. Typically 0.
>>> +- cooling-max-level:   An unsigned integer indicating the largest
>>> +                       cooling level accepted.
>> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
>> this binding specific?
> 
> It means cooling ability of a cooling device, such as speed of a fan.
> But it is better to use cooling-min/max-state I think, because the
> thermal management code is using "cooling state", concepts in dt and c
> should be identical.

I think the idea is just to be clear. Just because the thermal
management implementation uses a terminology, it does not necessarily
mean it is best fit for describing in device tree bindings. But I dont
really have strong opinion on level or state at this point.

> 
>> How does this relate to cooling-cells? These seem to be a fixed size.
> 
> I also think cooling-cells is redundant.

Cooling cells is not redundant, please check my explanation on the other
thread. It is required to determine which level/states are used while
binding.

> 
>>> +- #cooling-cells:      Used to provide cooling device specific
>>> information
>>> +                       while referring to it. Must be at least 2, in
>>> order
>>> +                       to specify minimum and maximum cooling level
>>> used
>>> +                       in the reference. See Cooling device
>>> attachments section
>>> +                       below for more details on how consumers refer to
>>> +                       cooling devices.
>> Are these cooling cells always expected to cover min and max, and are
>> min and max always expected to take the same number of cells? The above
>> cooling-*-level properties imply they each take up one cell.
>>
>> Does #cooling-cells = <3> make sense?. If this covers additional
>> information (e.g. which fan on a multi-fan controller), how does the OS
>> determine which cells are min and max, and how do these relate to
>> cooling-level-min and cooling-level-max?
>>
>>> +
>>> +* 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.
>> I'm still not sure on this, as it sounds like embedding policy into the
>> DT, rather than a description of the hardware. I realise we need to
>> prevent devices burning out, so describing the max acceptable
>> temperature and possibly a preferred range makes sense, but do we need
>> this level of flexibility? Maybe we do.
>>
> Putting platform data into dt is acceptable, right?
> In a narrow sense, trip points are platform data, but in a broad sense,
> both trip point itself and its corresponding cooling device are all
> platform data.
> 

I think Mark needs to elaborate a bit more to clarify why he sees this
as embedding policy into DT. And I believe it is fine to pass platform
data, as long as it represents hardware and it is  not representing policy.

>>> +
>>> +Required properties:
>>> +- temperature:         the trip temperature level, in milliCelsius.
>> Preferably, s/milliCelsius/millicelsius/ over the document.
>>
>> Given that we have signed values elsewhere, is this signed or unsigned?
>>
>>> +- hysteresis:          a (low) hysteresis value on 'temperature'.
>>> This is a
>>> +                       relative value, in milliCelsius.
>>> +- type:                        the trip type. Here is the type mapping:
>>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active
>>> cooling
>>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable
>>> passive cooling
>>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>>> +
>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>> these consts.
>> Why not use a string for this? We do so for other type parameters in
>> other bindings (see dr_mode in
>> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
>> PHYs, etc).
>>
>>> +
>>> +* Cooling device attachments
>>> +
>>> +The cooling device attachments 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
>>> parameters,
>>> +                       referring to which cooling device is used in
>>> this
>>> +                       binding. The required parameters are: the
>>> minimum
>>> +                       cooling level and the maximum cooling level used
>>> +                       in this attach.
>> Might this be a list in general? The code doesn't have to support that
>> yet.
>>
>> It would be nice to have a name for the cells after a phandle which
>> describe the cooling device's configuration. You've called them
>> parameters here, but it probably makes sense to call them a
>> cooling-specifier (following clock-specifier and interrupt-specifier).
>>
>>> +- trip:                        A phandle of a trip point node within
>>> the same thermal
>>> +                       zone.
>>> +
>>> +Optional property:
>>> +- contribution:                The cooling contribution to the
>>> thermal zone of the
>>> +                       referred cooling device at the referred trip
>>> point.
>>> +                       The contribution is a value from 0 to 100.
>>> The sum
>>> +                       of all cooling contributions within a thermal
>>> zone
>>> +                       must never exceed 100.
>> This is a bit arbitrary. Couldn't we sum all contributions to find the
>> total automatically, so this could be a simpler ratio?
>>
>>> +
>>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the
>>> cooling-device phandle
>>> +limit parameters means:
>>> +(i)   - minimum level allowed for minimum cooling level used in the
>>> reference.
>>> +(ii)  - maximum level allowed for maximum cooling level used in the
>>> reference.
>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>> this constant.
>>> +
>>> +* Thermal zones
>>> +
>>> +The thermal-zone node is the node containing all the required info
>>> +for describing a thermal zone, including its cdev 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 attachments.
>> s/cdev/cooling device/ ?
>>
>>> +
>>> +Required properties:
>>> +- passive-delay:       The maximum number of milliseconds to wait
>>> between polls
>>> +                       when performing passive cooling.
>>> +- polling-delay:       The maximum number of milliseconds to wait
>>> between polls
>>> +                       when checking this thermal zone.
>> How about polling-delay-passive, polling-delay-active? I'm still not
>>
>>> +- sensors:             A list of sensor phandles and their
>>> parameters. The
>>> +                       required parameter is the sensor id, in order to
>>> +                       identify internal sensors when the sensor IC
>>> features
>>> +                       several sensing units.
>> As mentioned above, I'm not sure you even need that one cell.
>>
>> - sensors:                A list of sensor phandle +
>> thermal-sensor-specifier
>>                            cells describing the sensors monitoring the
>> thermal
>>               zone.
>>
>>> +- trips:               A sub-node containing several trip point
>>> nodes required
>>> +                       to describe the thermal zone.
>>> +- cooling-attachments  A sub-node containing several cooling device
>>> attaches
>>> +                       nodes, used to describe the relation between
>>> trips
>>> +                       and cooling devices.
>>> +
>>> +Optional property:
>>> +- coefficients:                An array of integers (one signed
>>> cell) containing
>>> +                       coefficients to compose a linear relation
>>> between
>>> +                       the sensors described in the sensors property.
>>> +                       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.
>> What is the end result of this? Presumably this is meant to result in an
>> estimate of the average temperature of the thermal zone, rather than an
>> arbitrary value? This should be mentioned.
>>
>> This doesn't seem to be used the in the code below...
>>
>>> +
>>> +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 (passive-delay); 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.
>> I'm not sure what you mean by this, could you elaborate?
>>
>> I guess you mean that the delays should be chosen to account for said
>> max dT/dt, such that a device can't unexpectedly cross several trip
>> boundaries between polls?
>>
>>> +
>>> +* 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-level = <0>;
>>> +               cooling-max-level = <3>;
>>> +               #cooling-cells = <2>; /* min followed by max */
>>> +       };
>> What do those min and max mean in this context? What do the values in
>> the range [0,3] correspond to?
>>
>> I'm not sure it makes sense to describe passive cooling in this way --
>> the precise way an OS does less work on a device is fundamentally tied
>> to the design of the OS (it might be able to rate-limit requests, it
>> might be able to clock the device down, it might only be able to turn
>> the device off).
>>
>> I'm not sure there is anything we can describe for passive cooling
>> (beyond the thermal limits the OS should attempt to stick to).
>>
>>> +       ...
>>> +};
>>> +
>>> +&i2c1 {
>>> +       ...
>>> +       fan0: fan@0x48 {
>>> +               ...
>>> +               cooling-min-level = <0>;
>>> +               cooling-max-level = <9>;
>>> +               #cooling-cells = <2>; /* min followed by max */
>>> +       };
>> What do min and max mean here for the fan?
>>
> It means the speed level of a fan. Even if a fan can run at a continuous
> speed range, but when it is controlled under thermal management
> framework, it can only run at discrete speeds.


Please, an important point here, this is not about thermal framework
requirement. But how we describe hardware. As you mentioned, even if
there are fan devices out there that uses continuous speed range, there
other devices, even fan devices or cpu frequency steps for instance,
that are discrete. Again, *this is not a thermal framework requirement*.

>>> +};
>>> +
>>> +bandgap0: bandgap@0x0000ED00 {
>>> +       ...
>>> +       #sensor-cells = <1>;
>>> +};
>>> +
>>> +cpu-thermal: cpu-thermal {
>> How do the thermal zones get probed?
>>
>>> +       passive-delay = <250>; /* milliseconds */
>>> +       polling-delay = <1000>; /* milliseconds */
>>> +
>>> +               /* sensor       ID */
>>> +        sensors = <&bandgap0     0>;
>>> +
>>> +        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-attachments {
>>> +               attach0 {
>>> +                       trip = <&cpu-alert0>;
>>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>>> +               };
>>> +               attach1 {
>>> +                       trip = <&cpu-alert1>;
>>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>>> +               };
>>> +               attach2 {
>>> +                       trip = <&cpu-alert1>;
>>> +                       cooling-device =
>>> +                               <&cpu0 THERMAL_NO_LIMITS
>>> THERMAL_NO_LIMITS>;
>>> +               };
>>> +       };
>> Was there a good reason for splitting trips and attachment?
> 
> This is for adding/removing cooling device dynamically.

Well not really. I don't think this would prevent us of representing it
inside the trip point. It is, as I replied to Mark, because I wanted to
keep the flexibility to allow describing better properties related to
the cooling device while associated to a trip point alone, e.g.
'contribution'.

> 
>>> +};
>>> +
>>> +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, is used to remove the heat out of the
>>> thermal
>>> +zone 'cpu-thermal' using its cooling levels 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 level.
>>> +The cpu@0 device is also linked to the same thermal zone,
>>> 'cpu-thermal', as a
>>> +passive cooling device, using all its cooling levels at trip point
>>> 'cpu-alert1',
>>> +which is a trip point at 100C.
>>> +
>>
> 
> 
> 
> 
> 


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

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

Zhang,

I appreciate your interest. I am replying a couple of your comments.
Please also check my answers to Mark's queries on other email thread.

On 24-09-2013 04:11, Hongbo Zhang wrote:
> On 09/23/2013 06:40 PM, Mark Rutland wrote:
>> Hi Eduardo,
>>
>> Apologies for having taken so long to get back you on this.
>>
>> I have several comments on the binding and the way it's parsed.
>>
>> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>>> ---
>>>   .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>>   drivers/thermal/Kconfig                            |  13 +
>>>   drivers/thermal/Makefile                           |   1 +
>>>   drivers/thermal/of-thermal.c                       | 775
>>> +++++++++++++++++++++
>>>   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, 1357 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
>>>
>>> ---
>>>
>>> Hello all,
>>>
>>> Thanks Joe Perches for the effort of reviewing this code, I really
>>> appreciate it.
>>>
>>> Here is a version with a refactored init function without leaks in
>>> the failure
>>> patch. I also added a couple of comments to better understand the
>>> intention of
>>> that function. Besides, when there are no memory available, the function
>>> rolls back what ever thermal zones have been added.
>>>
>>> Thanks,
>>>
>>> Eduardo
>>>
>>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
>>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>>> new file mode 100644
>>> index 0000000..6664533
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>>> @@ -0,0 +1,498 @@
>>> +* 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 attachments: used to describe links between trip points and
>>> +cooling devices;
>> I think "attachments" sounds a bit odd, though I don't have a better
>> naming suggestion.
> 
> "map" or "mapping" is better?

Well,  yeah, that could work.

> 
>>> +- thermal zones: used to describe thermal data within the hardware;
>>> +
>>> +It follows a description of each type of these device tree nodes.
>>> +
>>> +* Sensor devices
>>> +
>>> +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. Temperature sensor
>>> devices may
>>> +control one or more internal sensors.
>>> +
>>> +Required property:
>>> +- #sensor-cells:       Used to provide sensor device specific
>>> information
>>> +                       while referring to it. Must be at least 1, 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.
>> I don't see why this needs to be at least one cell -- if an IC only has
>> one temperature sensor it should be fine for this to be zero and have no
>> ambiguity.
>>
>> It may make sense to call these thermal sensor devices, there are plenty
>> of other sensors we might want to describe in the dt for other purposes,
>> and we can impose some consistency if we remove the ambiguity.
>>
>>> +
>>> +* 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. 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 level of cooling.
>>> +
>>> +Required property:
>>> +- cooling-min-level:   A unsigned integer indicating the smallest
>>> +                       cooling level accepted. Typically 0.
>>> +- cooling-max-level:   An unsigned integer indicating the largest
>>> +                       cooling level accepted.
>> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
>> this binding specific?
> 
> It means cooling ability of a cooling device, such as speed of a fan.
> But it is better to use cooling-min/max-state I think, because the
> thermal management code is using "cooling state", concepts in dt and c
> should be identical.

I think the idea is just to be clear. Just because the thermal
management implementation uses a terminology, it does not necessarily
mean it is best fit for describing in device tree bindings. But I dont
really have strong opinion on level or state at this point.

> 
>> How does this relate to cooling-cells? These seem to be a fixed size.
> 
> I also think cooling-cells is redundant.

Cooling cells is not redundant, please check my explanation on the other
thread. It is required to determine which level/states are used while
binding.

> 
>>> +- #cooling-cells:      Used to provide cooling device specific
>>> information
>>> +                       while referring to it. Must be at least 2, in
>>> order
>>> +                       to specify minimum and maximum cooling level
>>> used
>>> +                       in the reference. See Cooling device
>>> attachments section
>>> +                       below for more details on how consumers refer to
>>> +                       cooling devices.
>> Are these cooling cells always expected to cover min and max, and are
>> min and max always expected to take the same number of cells? The above
>> cooling-*-level properties imply they each take up one cell.
>>
>> Does #cooling-cells = <3> make sense?. If this covers additional
>> information (e.g. which fan on a multi-fan controller), how does the OS
>> determine which cells are min and max, and how do these relate to
>> cooling-level-min and cooling-level-max?
>>
>>> +
>>> +* 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.
>> I'm still not sure on this, as it sounds like embedding policy into the
>> DT, rather than a description of the hardware. I realise we need to
>> prevent devices burning out, so describing the max acceptable
>> temperature and possibly a preferred range makes sense, but do we need
>> this level of flexibility? Maybe we do.
>>
> Putting platform data into dt is acceptable, right?
> In a narrow sense, trip points are platform data, but in a broad sense,
> both trip point itself and its corresponding cooling device are all
> platform data.
> 

I think Mark needs to elaborate a bit more to clarify why he sees this
as embedding policy into DT. And I believe it is fine to pass platform
data, as long as it represents hardware and it is  not representing policy.

>>> +
>>> +Required properties:
>>> +- temperature:         the trip temperature level, in milliCelsius.
>> Preferably, s/milliCelsius/millicelsius/ over the document.
>>
>> Given that we have signed values elsewhere, is this signed or unsigned?
>>
>>> +- hysteresis:          a (low) hysteresis value on 'temperature'.
>>> This is a
>>> +                       relative value, in milliCelsius.
>>> +- type:                        the trip type. Here is the type mapping:
>>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active
>>> cooling
>>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable
>>> passive cooling
>>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>>> +
>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>> these consts.
>> Why not use a string for this? We do so for other type parameters in
>> other bindings (see dr_mode in
>> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
>> PHYs, etc).
>>
>>> +
>>> +* Cooling device attachments
>>> +
>>> +The cooling device attachments 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
>>> parameters,
>>> +                       referring to which cooling device is used in
>>> this
>>> +                       binding. The required parameters are: the
>>> minimum
>>> +                       cooling level and the maximum cooling level used
>>> +                       in this attach.
>> Might this be a list in general? The code doesn't have to support that
>> yet.
>>
>> It would be nice to have a name for the cells after a phandle which
>> describe the cooling device's configuration. You've called them
>> parameters here, but it probably makes sense to call them a
>> cooling-specifier (following clock-specifier and interrupt-specifier).
>>
>>> +- trip:                        A phandle of a trip point node within
>>> the same thermal
>>> +                       zone.
>>> +
>>> +Optional property:
>>> +- contribution:                The cooling contribution to the
>>> thermal zone of the
>>> +                       referred cooling device at the referred trip
>>> point.
>>> +                       The contribution is a value from 0 to 100.
>>> The sum
>>> +                       of all cooling contributions within a thermal
>>> zone
>>> +                       must never exceed 100.
>> This is a bit arbitrary. Couldn't we sum all contributions to find the
>> total automatically, so this could be a simpler ratio?
>>
>>> +
>>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the
>>> cooling-device phandle
>>> +limit parameters means:
>>> +(i)   - minimum level allowed for minimum cooling level used in the
>>> reference.
>>> +(ii)  - maximum level allowed for maximum cooling level used in the
>>> reference.
>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>> this constant.
>>> +
>>> +* Thermal zones
>>> +
>>> +The thermal-zone node is the node containing all the required info
>>> +for describing a thermal zone, including its cdev 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 attachments.
>> s/cdev/cooling device/ ?
>>
>>> +
>>> +Required properties:
>>> +- passive-delay:       The maximum number of milliseconds to wait
>>> between polls
>>> +                       when performing passive cooling.
>>> +- polling-delay:       The maximum number of milliseconds to wait
>>> between polls
>>> +                       when checking this thermal zone.
>> How about polling-delay-passive, polling-delay-active? I'm still not
>>
>>> +- sensors:             A list of sensor phandles and their
>>> parameters. The
>>> +                       required parameter is the sensor id, in order to
>>> +                       identify internal sensors when the sensor IC
>>> features
>>> +                       several sensing units.
>> As mentioned above, I'm not sure you even need that one cell.
>>
>> - sensors:                A list of sensor phandle +
>> thermal-sensor-specifier
>>                            cells describing the sensors monitoring the
>> thermal
>>               zone.
>>
>>> +- trips:               A sub-node containing several trip point
>>> nodes required
>>> +                       to describe the thermal zone.
>>> +- cooling-attachments  A sub-node containing several cooling device
>>> attaches
>>> +                       nodes, used to describe the relation between
>>> trips
>>> +                       and cooling devices.
>>> +
>>> +Optional property:
>>> +- coefficients:                An array of integers (one signed
>>> cell) containing
>>> +                       coefficients to compose a linear relation
>>> between
>>> +                       the sensors described in the sensors property.
>>> +                       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.
>> What is the end result of this? Presumably this is meant to result in an
>> estimate of the average temperature of the thermal zone, rather than an
>> arbitrary value? This should be mentioned.
>>
>> This doesn't seem to be used the in the code below...
>>
>>> +
>>> +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 (passive-delay); 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.
>> I'm not sure what you mean by this, could you elaborate?
>>
>> I guess you mean that the delays should be chosen to account for said
>> max dT/dt, such that a device can't unexpectedly cross several trip
>> boundaries between polls?
>>
>>> +
>>> +* 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-level = <0>;
>>> +               cooling-max-level = <3>;
>>> +               #cooling-cells = <2>; /* min followed by max */
>>> +       };
>> What do those min and max mean in this context? What do the values in
>> the range [0,3] correspond to?
>>
>> I'm not sure it makes sense to describe passive cooling in this way --
>> the precise way an OS does less work on a device is fundamentally tied
>> to the design of the OS (it might be able to rate-limit requests, it
>> might be able to clock the device down, it might only be able to turn
>> the device off).
>>
>> I'm not sure there is anything we can describe for passive cooling
>> (beyond the thermal limits the OS should attempt to stick to).
>>
>>> +       ...
>>> +};
>>> +
>>> +&i2c1 {
>>> +       ...
>>> +       fan0: fan@0x48 {
>>> +               ...
>>> +               cooling-min-level = <0>;
>>> +               cooling-max-level = <9>;
>>> +               #cooling-cells = <2>; /* min followed by max */
>>> +       };
>> What do min and max mean here for the fan?
>>
> It means the speed level of a fan. Even if a fan can run at a continuous
> speed range, but when it is controlled under thermal management
> framework, it can only run at discrete speeds.


Please, an important point here, this is not about thermal framework
requirement. But how we describe hardware. As you mentioned, even if
there are fan devices out there that uses continuous speed range, there
other devices, even fan devices or cpu frequency steps for instance,
that are discrete. Again, *this is not a thermal framework requirement*.

>>> +};
>>> +
>>> +bandgap0: bandgap@0x0000ED00 {
>>> +       ...
>>> +       #sensor-cells = <1>;
>>> +};
>>> +
>>> +cpu-thermal: cpu-thermal {
>> How do the thermal zones get probed?
>>
>>> +       passive-delay = <250>; /* milliseconds */
>>> +       polling-delay = <1000>; /* milliseconds */
>>> +
>>> +               /* sensor       ID */
>>> +        sensors = <&bandgap0     0>;
>>> +
>>> +        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-attachments {
>>> +               attach0 {
>>> +                       trip = <&cpu-alert0>;
>>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>>> +               };
>>> +               attach1 {
>>> +                       trip = <&cpu-alert1>;
>>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>>> +               };
>>> +               attach2 {
>>> +                       trip = <&cpu-alert1>;
>>> +                       cooling-device =
>>> +                               <&cpu0 THERMAL_NO_LIMITS
>>> THERMAL_NO_LIMITS>;
>>> +               };
>>> +       };
>> Was there a good reason for splitting trips and attachment?
> 
> This is for adding/removing cooling device dynamically.

Well not really. I don't think this would prevent us of representing it
inside the trip point. It is, as I replied to Mark, because I wanted to
keep the flexibility to allow describing better properties related to
the cooling device while associated to a trip point alone, e.g.
'contribution'.

> 
>>> +};
>>> +
>>> +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, is used to remove the heat out of the
>>> thermal
>>> +zone 'cpu-thermal' using its cooling levels 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 level.
>>> +The cpu@0 device is also linked to the same thermal zone,
>>> 'cpu-thermal', as a
>>> +passive cooling device, using all its cooling levels at trip point
>>> 'cpu-alert1',
>>> +which is a trip point at 100C.
>>> +
>>
> 
> 
> 
> 
> 


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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/24/2013 11:50 PM, Eduardo Valentin wrote:
> Zhang,
>
> I appreciate your interest. I am replying a couple of your comments.
> Please also check my answers to Mark's queries on other email thread.
When I replied to Mark yesterday, I missed your mail replying him already.
I should check that mail and reply it for further concerns.
> On 24-09-2013 04:11, Hongbo Zhang wrote:
>> On 09/23/2013 06:40 PM, Mark Rutland wrote:
>>> Hi Eduardo,
>>>
>>> Apologies for having taken so long to get back you on this.
>>>
>>> I have several comments on the binding and the way it's parsed.
>>>
>>> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>>>> ---
>>>>    .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>>>    drivers/thermal/Kconfig                            |  13 +
>>>>    drivers/thermal/Makefile                           |   1 +
>>>>    drivers/thermal/of-thermal.c                       | 775
>>>> +++++++++++++++++++++
>>>>    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, 1357 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
>>>>
>>>> ---
>>>>
>>>> Hello all,
>>>>
>>>> Thanks Joe Perches for the effort of reviewing this code, I really
>>>> appreciate it.
>>>>
>>>> Here is a version with a refactored init function without leaks in
>>>> the failure
>>>> patch. I also added a couple of comments to better understand the
>>>> intention of
>>>> that function. Besides, when there are no memory available, the function
>>>> rolls back what ever thermal zones have been added.
>>>>
>>>> Thanks,
>>>>
>>>> Eduardo
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
>>>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>> new file mode 100644
>>>> index 0000000..6664533
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>> @@ -0,0 +1,498 @@
>>>> +* 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 attachments: used to describe links between trip points and
>>>> +cooling devices;
>>> I think "attachments" sounds a bit odd, though I don't have a better
>>> naming suggestion.
>> "map" or "mapping" is better?
> Well,  yeah, that could work.
:)
>>>> +- thermal zones: used to describe thermal data within the hardware;
>>>> +
>>>> +It follows a description of each type of these device tree nodes.
>>>> +
>>>> +* Sensor devices
>>>> +
>>>> +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. Temperature sensor
>>>> devices may
>>>> +control one or more internal sensors.
>>>> +
>>>> +Required property:
>>>> +- #sensor-cells:       Used to provide sensor device specific
>>>> information
>>>> +                       while referring to it. Must be at least 1, 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.
>>> I don't see why this needs to be at least one cell -- if an IC only has
>>> one temperature sensor it should be fine for this to be zero and have no
>>> ambiguity.
>>>
>>> It may make sense to call these thermal sensor devices, there are plenty
>>> of other sensors we might want to describe in the dt for other purposes,
>>> and we can impose some consistency if we remove the ambiguity.
>>>
>>>> +
>>>> +* 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. 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 level of cooling.
>>>> +
>>>> +Required property:
>>>> +- cooling-min-level:   A unsigned integer indicating the smallest
>>>> +                       cooling level accepted. Typically 0.
>>>> +- cooling-max-level:   An unsigned integer indicating the largest
>>>> +                       cooling level accepted.
>>> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
>>> this binding specific?
>> It means cooling ability of a cooling device, such as speed of a fan.
>> But it is better to use cooling-min/max-state I think, because the
>> thermal management code is using "cooling state", concepts in dt and c
>> should be identical.
> I think the idea is just to be clear. Just because the thermal
> management implementation uses a terminology, it does not necessarily
> mean it is best fit for describing in device tree bindings. But I dont
> really have strong opinion on level or state at this point.
>
>>> How does this relate to cooling-cells? These seem to be a fixed size.
>> I also think cooling-cells is redundant.
> Cooling cells is not redundant, please check my explanation on the other
> thread. It is required to determine which level/states are used while
> binding.
>
OK

>>>> +- #cooling-cells:      Used to provide cooling device specific
>>>> information
>>>> +                       while referring to it. Must be at least 2, in
>>>> order
>>>> +                       to specify minimum and maximum cooling level
>>>> used
>>>> +                       in the reference. See Cooling device
>>>> attachments section
>>>> +                       below for more details on how consumers refer to
>>>> +                       cooling devices.
>>> Are these cooling cells always expected to cover min and max, and are
>>> min and max always expected to take the same number of cells? The above
>>> cooling-*-level properties imply they each take up one cell.
>>>
>>> Does #cooling-cells = <3> make sense?. If this covers additional
>>> information (e.g. which fan on a multi-fan controller), how does the OS
>>> determine which cells are min and max, and how do these relate to
>>> cooling-level-min and cooling-level-max?
>>>
>>>> +
>>>> +* 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.
>>> I'm still not sure on this, as it sounds like embedding policy into the
>>> DT, rather than a description of the hardware. I realise we need to
>>> prevent devices burning out, so describing the max acceptable
>>> temperature and possibly a preferred range makes sense, but do we need
>>> this level of flexibility? Maybe we do.
>>>
>> Putting platform data into dt is acceptable, right?
>> In a narrow sense, trip points are platform data, but in a broad sense,
>> both trip point itself and its corresponding cooling device are all
>> platform data.
>>
> I think Mark needs to elaborate a bit more to clarify why he sees this
> as embedding policy into DT. And I believe it is fine to pass platform
> data, as long as it represents hardware and it is  not representing policy.
>
>>>> +
>>>> +Required properties:
>>>> +- temperature:         the trip temperature level, in milliCelsius.
>>> Preferably, s/milliCelsius/millicelsius/ over the document.
>>>
>>> Given that we have signed values elsewhere, is this signed or unsigned?
>>>
>>>> +- hysteresis:          a (low) hysteresis value on 'temperature'.
>>>> This is a
>>>> +                       relative value, in milliCelsius.
>>>> +- type:                        the trip type. Here is the type mapping:
>>>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active
>>>> cooling
>>>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable
>>>> passive cooling
>>>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>>>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>>>> +
>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>> these consts.
>>> Why not use a string for this? We do so for other type parameters in
>>> other bindings (see dr_mode in
>>> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
>>> PHYs, etc).
>>>
>>>> +
>>>> +* Cooling device attachments
>>>> +
>>>> +The cooling device attachments 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
>>>> parameters,
>>>> +                       referring to which cooling device is used in
>>>> this
>>>> +                       binding. The required parameters are: the
>>>> minimum
>>>> +                       cooling level and the maximum cooling level used
>>>> +                       in this attach.
>>> Might this be a list in general? The code doesn't have to support that
>>> yet.
>>>
>>> It would be nice to have a name for the cells after a phandle which
>>> describe the cooling device's configuration. You've called them
>>> parameters here, but it probably makes sense to call them a
>>> cooling-specifier (following clock-specifier and interrupt-specifier).
>>>
>>>> +- trip:                        A phandle of a trip point node within
>>>> the same thermal
>>>> +                       zone.
>>>> +
>>>> +Optional property:
>>>> +- contribution:                The cooling contribution to the
>>>> thermal zone of the
>>>> +                       referred cooling device at the referred trip
>>>> point.
>>>> +                       The contribution is a value from 0 to 100.
>>>> The sum
>>>> +                       of all cooling contributions within a thermal
>>>> zone
>>>> +                       must never exceed 100.
>>> This is a bit arbitrary. Couldn't we sum all contributions to find the
>>> total automatically, so this could be a simpler ratio?
>>>
>>>> +
>>>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the
>>>> cooling-device phandle
>>>> +limit parameters means:
>>>> +(i)   - minimum level allowed for minimum cooling level used in the
>>>> reference.
>>>> +(ii)  - maximum level allowed for maximum cooling level used in the
>>>> reference.
>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>> this constant.
>>>> +
>>>> +* Thermal zones
>>>> +
>>>> +The thermal-zone node is the node containing all the required info
>>>> +for describing a thermal zone, including its cdev 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 attachments.
>>> s/cdev/cooling device/ ?
>>>
>>>> +
>>>> +Required properties:
>>>> +- passive-delay:       The maximum number of milliseconds to wait
>>>> between polls
>>>> +                       when performing passive cooling.
>>>> +- polling-delay:       The maximum number of milliseconds to wait
>>>> between polls
>>>> +                       when checking this thermal zone.
>>> How about polling-delay-passive, polling-delay-active? I'm still not
>>>
>>>> +- sensors:             A list of sensor phandles and their
>>>> parameters. The
>>>> +                       required parameter is the sensor id, in order to
>>>> +                       identify internal sensors when the sensor IC
>>>> features
>>>> +                       several sensing units.
>>> As mentioned above, I'm not sure you even need that one cell.
>>>
>>> - sensors:                A list of sensor phandle +
>>> thermal-sensor-specifier
>>>                             cells describing the sensors monitoring the
>>> thermal
>>>                zone.
>>>
>>>> +- trips:               A sub-node containing several trip point
>>>> nodes required
>>>> +                       to describe the thermal zone.
>>>> +- cooling-attachments  A sub-node containing several cooling device
>>>> attaches
>>>> +                       nodes, used to describe the relation between
>>>> trips
>>>> +                       and cooling devices.
>>>> +
>>>> +Optional property:
>>>> +- coefficients:                An array of integers (one signed
>>>> cell) containing
>>>> +                       coefficients to compose a linear relation
>>>> between
>>>> +                       the sensors described in the sensors property.
>>>> +                       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.
>>> What is the end result of this? Presumably this is meant to result in an
>>> estimate of the average temperature of the thermal zone, rather than an
>>> arbitrary value? This should be mentioned.
>>>
>>> This doesn't seem to be used the in the code below...
>>>
>>>> +
>>>> +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 (passive-delay); 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.
>>> I'm not sure what you mean by this, could you elaborate?
>>>
>>> I guess you mean that the delays should be chosen to account for said
>>> max dT/dt, such that a device can't unexpectedly cross several trip
>>> boundaries between polls?
>>>
>>>> +
>>>> +* 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-level = <0>;
>>>> +               cooling-max-level = <3>;
>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>> +       };
>>> What do those min and max mean in this context? What do the values in
>>> the range [0,3] correspond to?
>>>
>>> I'm not sure it makes sense to describe passive cooling in this way --
>>> the precise way an OS does less work on a device is fundamentally tied
>>> to the design of the OS (it might be able to rate-limit requests, it
>>> might be able to clock the device down, it might only be able to turn
>>> the device off).
>>>
>>> I'm not sure there is anything we can describe for passive cooling
>>> (beyond the thermal limits the OS should attempt to stick to).
>>>
>>>> +       ...
>>>> +};
>>>> +
>>>> +&i2c1 {
>>>> +       ...
>>>> +       fan0: fan@0x48 {
>>>> +               ...
>>>> +               cooling-min-level = <0>;
>>>> +               cooling-max-level = <9>;
>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>> +       };
>>> What do min and max mean here for the fan?
>>>
>> It means the speed level of a fan. Even if a fan can run at a continuous
>> speed range, but when it is controlled under thermal management
>> framework, it can only run at discrete speeds.
>
> Please, an important point here, this is not about thermal framework
> requirement. But how we describe hardware. As you mentioned, even if
> there are fan devices out there that uses continuous speed range, there
> other devices, even fan devices or cpu frequency steps for instance,
> that are discrete. Again, *this is not a thermal framework requirement*.
>
>>>> +};
>>>> +
>>>> +bandgap0: bandgap@0x0000ED00 {
>>>> +       ...
>>>> +       #sensor-cells = <1>;
>>>> +};
>>>> +
>>>> +cpu-thermal: cpu-thermal {
>>> How do the thermal zones get probed?
>>>
>>>> +       passive-delay = <250>; /* milliseconds */
>>>> +       polling-delay = <1000>; /* milliseconds */
>>>> +
>>>> +               /* sensor       ID */
>>>> +        sensors = <&bandgap0     0>;
>>>> +
>>>> +        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-attachments {
>>>> +               attach0 {
>>>> +                       trip = <&cpu-alert0>;
>>>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>>>> +               };
>>>> +               attach1 {
>>>> +                       trip = <&cpu-alert1>;
>>>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>>>> +               };
>>>> +               attach2 {
>>>> +                       trip = <&cpu-alert1>;
>>>> +                       cooling-device =
>>>> +                               <&cpu0 THERMAL_NO_LIMITS
>>>> THERMAL_NO_LIMITS>;
>>>> +               };
>>>> +       };
>>> Was there a good reason for splitting trips and attachment?
>> This is for adding/removing cooling device dynamically.
> Well not really. I don't think this would prevent us of representing it
> inside the trip point. It is, as I replied to Mark, because I wanted to
> keep the flexibility to allow describing better properties related to
> the cooling device while associated to a trip point alone, e.g.
> 'contribution'.

Understand your purpose and explanation.
But this can also really help to add/remove cooling device freely, there 
were already drivers with separated files of thermal zone and cooling 
device.

>>>> +};
>>>> +
>>>> +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, is used to remove the heat out of the
>>>> thermal
>>>> +zone 'cpu-thermal' using its cooling levels 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 level.
>>>> +The cpu@0 device is also linked to the same thermal zone,
>>>> 'cpu-thermal', as a
>>>> +passive cooling device, using all its cooling levels at trip point
>>>> 'cpu-alert1',
>>>> +which is a trip point at 100C.
>>>> +
>>
>>
>>
>>
>

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/24/2013 11:50 PM, Eduardo Valentin wrote:
> Zhang,
>
> I appreciate your interest. I am replying a couple of your comments.
> Please also check my answers to Mark's queries on other email thread.
When I replied to Mark yesterday, I missed your mail replying him already.
I should check that mail and reply it for further concerns.
> On 24-09-2013 04:11, Hongbo Zhang wrote:
>> On 09/23/2013 06:40 PM, Mark Rutland wrote:
>>> Hi Eduardo,
>>>
>>> Apologies for having taken so long to get back you on this.
>>>
>>> I have several comments on the binding and the way it's parsed.
>>>
>>> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>>>> ---
>>>>    .../devicetree/bindings/thermal/thermal.txt        | 498 +++++++++++++
>>>>    drivers/thermal/Kconfig                            |  13 +
>>>>    drivers/thermal/Makefile                           |   1 +
>>>>    drivers/thermal/of-thermal.c                       | 775
>>>> +++++++++++++++++++++
>>>>    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, 1357 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
>>>>
>>>> ---
>>>>
>>>> Hello all,
>>>>
>>>> Thanks Joe Perches for the effort of reviewing this code, I really
>>>> appreciate it.
>>>>
>>>> Here is a version with a refactored init function without leaks in
>>>> the failure
>>>> patch. I also added a couple of comments to better understand the
>>>> intention of
>>>> that function. Besides, when there are no memory available, the function
>>>> rolls back what ever thermal zones have been added.
>>>>
>>>> Thanks,
>>>>
>>>> Eduardo
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
>>>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>> new file mode 100644
>>>> index 0000000..6664533
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>> @@ -0,0 +1,498 @@
>>>> +* 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 attachments: used to describe links between trip points and
>>>> +cooling devices;
>>> I think "attachments" sounds a bit odd, though I don't have a better
>>> naming suggestion.
>> "map" or "mapping" is better?
> Well,  yeah, that could work.
:)
>>>> +- thermal zones: used to describe thermal data within the hardware;
>>>> +
>>>> +It follows a description of each type of these device tree nodes.
>>>> +
>>>> +* Sensor devices
>>>> +
>>>> +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. Temperature sensor
>>>> devices may
>>>> +control one or more internal sensors.
>>>> +
>>>> +Required property:
>>>> +- #sensor-cells:       Used to provide sensor device specific
>>>> information
>>>> +                       while referring to it. Must be at least 1, 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.
>>> I don't see why this needs to be at least one cell -- if an IC only has
>>> one temperature sensor it should be fine for this to be zero and have no
>>> ambiguity.
>>>
>>> It may make sense to call these thermal sensor devices, there are plenty
>>> of other sensors we might want to describe in the dt for other purposes,
>>> and we can impose some consistency if we remove the ambiguity.
>>>
>>>> +
>>>> +* 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. 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 level of cooling.
>>>> +
>>>> +Required property:
>>>> +- cooling-min-level:   A unsigned integer indicating the smallest
>>>> +                       cooling level accepted. Typically 0.
>>>> +- cooling-max-level:   An unsigned integer indicating the largest
>>>> +                       cooling level accepted.
>>> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
>>> this binding specific?
>> It means cooling ability of a cooling device, such as speed of a fan.
>> But it is better to use cooling-min/max-state I think, because the
>> thermal management code is using "cooling state", concepts in dt and c
>> should be identical.
> I think the idea is just to be clear. Just because the thermal
> management implementation uses a terminology, it does not necessarily
> mean it is best fit for describing in device tree bindings. But I dont
> really have strong opinion on level or state at this point.
>
>>> How does this relate to cooling-cells? These seem to be a fixed size.
>> I also think cooling-cells is redundant.
> Cooling cells is not redundant, please check my explanation on the other
> thread. It is required to determine which level/states are used while
> binding.
>
OK

>>>> +- #cooling-cells:      Used to provide cooling device specific
>>>> information
>>>> +                       while referring to it. Must be at least 2, in
>>>> order
>>>> +                       to specify minimum and maximum cooling level
>>>> used
>>>> +                       in the reference. See Cooling device
>>>> attachments section
>>>> +                       below for more details on how consumers refer to
>>>> +                       cooling devices.
>>> Are these cooling cells always expected to cover min and max, and are
>>> min and max always expected to take the same number of cells? The above
>>> cooling-*-level properties imply they each take up one cell.
>>>
>>> Does #cooling-cells = <3> make sense?. If this covers additional
>>> information (e.g. which fan on a multi-fan controller), how does the OS
>>> determine which cells are min and max, and how do these relate to
>>> cooling-level-min and cooling-level-max?
>>>
>>>> +
>>>> +* 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.
>>> I'm still not sure on this, as it sounds like embedding policy into the
>>> DT, rather than a description of the hardware. I realise we need to
>>> prevent devices burning out, so describing the max acceptable
>>> temperature and possibly a preferred range makes sense, but do we need
>>> this level of flexibility? Maybe we do.
>>>
>> Putting platform data into dt is acceptable, right?
>> In a narrow sense, trip points are platform data, but in a broad sense,
>> both trip point itself and its corresponding cooling device are all
>> platform data.
>>
> I think Mark needs to elaborate a bit more to clarify why he sees this
> as embedding policy into DT. And I believe it is fine to pass platform
> data, as long as it represents hardware and it is  not representing policy.
>
>>>> +
>>>> +Required properties:
>>>> +- temperature:         the trip temperature level, in milliCelsius.
>>> Preferably, s/milliCelsius/millicelsius/ over the document.
>>>
>>> Given that we have signed values elsewhere, is this signed or unsigned?
>>>
>>>> +- hysteresis:          a (low) hysteresis value on 'temperature'.
>>>> This is a
>>>> +                       relative value, in milliCelsius.
>>>> +- type:                        the trip type. Here is the type mapping:
>>>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active
>>>> cooling
>>>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable
>>>> passive cooling
>>>> +       THERMAL_TRIP_HOT        2:      A trip point to notify emergency
>>>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>>>> +
>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>> these consts.
>>> Why not use a string for this? We do so for other type parameters in
>>> other bindings (see dr_mode in
>>> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for ethernet
>>> PHYs, etc).
>>>
>>>> +
>>>> +* Cooling device attachments
>>>> +
>>>> +The cooling device attachments 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
>>>> parameters,
>>>> +                       referring to which cooling device is used in
>>>> this
>>>> +                       binding. The required parameters are: the
>>>> minimum
>>>> +                       cooling level and the maximum cooling level used
>>>> +                       in this attach.
>>> Might this be a list in general? The code doesn't have to support that
>>> yet.
>>>
>>> It would be nice to have a name for the cells after a phandle which
>>> describe the cooling device's configuration. You've called them
>>> parameters here, but it probably makes sense to call them a
>>> cooling-specifier (following clock-specifier and interrupt-specifier).
>>>
>>>> +- trip:                        A phandle of a trip point node within
>>>> the same thermal
>>>> +                       zone.
>>>> +
>>>> +Optional property:
>>>> +- contribution:                The cooling contribution to the
>>>> thermal zone of the
>>>> +                       referred cooling device at the referred trip
>>>> point.
>>>> +                       The contribution is a value from 0 to 100.
>>>> The sum
>>>> +                       of all cooling contributions within a thermal
>>>> zone
>>>> +                       must never exceed 100.
>>> This is a bit arbitrary. Couldn't we sum all contributions to find the
>>> total automatically, so this could be a simpler ratio?
>>>
>>>> +
>>>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the
>>>> cooling-device phandle
>>>> +limit parameters means:
>>>> +(i)   - minimum level allowed for minimum cooling level used in the
>>>> reference.
>>>> +(ii)  - maximum level allowed for maximum cooling level used in the
>>>> reference.
>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>> this constant.
>>>> +
>>>> +* Thermal zones
>>>> +
>>>> +The thermal-zone node is the node containing all the required info
>>>> +for describing a thermal zone, including its cdev 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 attachments.
>>> s/cdev/cooling device/ ?
>>>
>>>> +
>>>> +Required properties:
>>>> +- passive-delay:       The maximum number of milliseconds to wait
>>>> between polls
>>>> +                       when performing passive cooling.
>>>> +- polling-delay:       The maximum number of milliseconds to wait
>>>> between polls
>>>> +                       when checking this thermal zone.
>>> How about polling-delay-passive, polling-delay-active? I'm still not
>>>
>>>> +- sensors:             A list of sensor phandles and their
>>>> parameters. The
>>>> +                       required parameter is the sensor id, in order to
>>>> +                       identify internal sensors when the sensor IC
>>>> features
>>>> +                       several sensing units.
>>> As mentioned above, I'm not sure you even need that one cell.
>>>
>>> - sensors:                A list of sensor phandle +
>>> thermal-sensor-specifier
>>>                             cells describing the sensors monitoring the
>>> thermal
>>>                zone.
>>>
>>>> +- trips:               A sub-node containing several trip point
>>>> nodes required
>>>> +                       to describe the thermal zone.
>>>> +- cooling-attachments  A sub-node containing several cooling device
>>>> attaches
>>>> +                       nodes, used to describe the relation between
>>>> trips
>>>> +                       and cooling devices.
>>>> +
>>>> +Optional property:
>>>> +- coefficients:                An array of integers (one signed
>>>> cell) containing
>>>> +                       coefficients to compose a linear relation
>>>> between
>>>> +                       the sensors described in the sensors property.
>>>> +                       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.
>>> What is the end result of this? Presumably this is meant to result in an
>>> estimate of the average temperature of the thermal zone, rather than an
>>> arbitrary value? This should be mentioned.
>>>
>>> This doesn't seem to be used the in the code below...
>>>
>>>> +
>>>> +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 (passive-delay); 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.
>>> I'm not sure what you mean by this, could you elaborate?
>>>
>>> I guess you mean that the delays should be chosen to account for said
>>> max dT/dt, such that a device can't unexpectedly cross several trip
>>> boundaries between polls?
>>>
>>>> +
>>>> +* 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-level = <0>;
>>>> +               cooling-max-level = <3>;
>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>> +       };
>>> What do those min and max mean in this context? What do the values in
>>> the range [0,3] correspond to?
>>>
>>> I'm not sure it makes sense to describe passive cooling in this way --
>>> the precise way an OS does less work on a device is fundamentally tied
>>> to the design of the OS (it might be able to rate-limit requests, it
>>> might be able to clock the device down, it might only be able to turn
>>> the device off).
>>>
>>> I'm not sure there is anything we can describe for passive cooling
>>> (beyond the thermal limits the OS should attempt to stick to).
>>>
>>>> +       ...
>>>> +};
>>>> +
>>>> +&i2c1 {
>>>> +       ...
>>>> +       fan0: fan@0x48 {
>>>> +               ...
>>>> +               cooling-min-level = <0>;
>>>> +               cooling-max-level = <9>;
>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>> +       };
>>> What do min and max mean here for the fan?
>>>
>> It means the speed level of a fan. Even if a fan can run at a continuous
>> speed range, but when it is controlled under thermal management
>> framework, it can only run at discrete speeds.
>
> Please, an important point here, this is not about thermal framework
> requirement. But how we describe hardware. As you mentioned, even if
> there are fan devices out there that uses continuous speed range, there
> other devices, even fan devices or cpu frequency steps for instance,
> that are discrete. Again, *this is not a thermal framework requirement*.
>
>>>> +};
>>>> +
>>>> +bandgap0: bandgap@0x0000ED00 {
>>>> +       ...
>>>> +       #sensor-cells = <1>;
>>>> +};
>>>> +
>>>> +cpu-thermal: cpu-thermal {
>>> How do the thermal zones get probed?
>>>
>>>> +       passive-delay = <250>; /* milliseconds */
>>>> +       polling-delay = <1000>; /* milliseconds */
>>>> +
>>>> +               /* sensor       ID */
>>>> +        sensors = <&bandgap0     0>;
>>>> +
>>>> +        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-attachments {
>>>> +               attach0 {
>>>> +                       trip = <&cpu-alert0>;
>>>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>>>> +               };
>>>> +               attach1 {
>>>> +                       trip = <&cpu-alert1>;
>>>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>>>> +               };
>>>> +               attach2 {
>>>> +                       trip = <&cpu-alert1>;
>>>> +                       cooling-device >>>> +                               <&cpu0 THERMAL_NO_LIMITS
>>>> THERMAL_NO_LIMITS>;
>>>> +               };
>>>> +       };
>>> Was there a good reason for splitting trips and attachment?
>> This is for adding/removing cooling device dynamically.
> Well not really. I don't think this would prevent us of representing it
> inside the trip point. It is, as I replied to Mark, because I wanted to
> keep the flexibility to allow describing better properties related to
> the cooling device while associated to a trip point alone, e.g.
> 'contribution'.

Understand your purpose and explanation.
But this can also really help to add/remove cooling device freely, there 
were already drivers with separated files of thermal zone and cooling 
device.

>>>> +};
>>>> +
>>>> +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, is used to remove the heat out of the
>>>> thermal
>>>> +zone 'cpu-thermal' using its cooling levels 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 level.
>>>> +The cpu@0 device is also linked to the same thermal zone,
>>>> 'cpu-thermal', as a
>>>> +passive cooling device, using all its cooling levels at trip point
>>>> 'cpu-alert1',
>>>> +which is a trip point at 100C.
>>>> +
>>
>>
>>
>>
>




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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 25-09-2013 01:39, Hongbo Zhang wrote:
> On 09/24/2013 11:50 PM, Eduardo Valentin wrote:
>> Zhang,
>>
>> I appreciate your interest. I am replying a couple of your comments.
>> Please also check my answers to Mark's queries on other email thread.
> When I replied to Mark yesterday, I missed your mail replying him already.
> I should check that mail and reply it for further concerns.
>> On 24-09-2013 04:11, Hongbo Zhang wrote:
>>> On 09/23/2013 06:40 PM, Mark Rutland wrote:
>>>> Hi Eduardo,
>>>>
>>>> Apologies for having taken so long to get back you on this.
>>>>
>>>> I have several comments on the binding and the way it's parsed.
>>>>
>>>> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>>>>> ---
>>>>>    .../devicetree/bindings/thermal/thermal.txt        | 498
>>>>> +++++++++++++
>>>>>    drivers/thermal/Kconfig                            |  13 +
>>>>>    drivers/thermal/Makefile                           |   1 +
>>>>>    drivers/thermal/of-thermal.c                       | 775
>>>>> +++++++++++++++++++++
>>>>>    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, 1357 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
>>>>>
>>>>> ---
>>>>>
>>>>> Hello all,
>>>>>
>>>>> Thanks Joe Perches for the effort of reviewing this code, I really
>>>>> appreciate it.
>>>>>
>>>>> Here is a version with a refactored init function without leaks in
>>>>> the failure
>>>>> patch. I also added a couple of comments to better understand the
>>>>> intention of
>>>>> that function. Besides, when there are no memory available, the
>>>>> function
>>>>> rolls back what ever thermal zones have been added.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eduardo
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
>>>>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>>> new file mode 100644
>>>>> index 0000000..6664533
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>>> @@ -0,0 +1,498 @@
>>>>> +* 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 attachments: used to describe links between trip points and
>>>>> +cooling devices;
>>>> I think "attachments" sounds a bit odd, though I don't have a better
>>>> naming suggestion.
>>> "map" or "mapping" is better?
>> Well,  yeah, that could work.
> :)
>>>>> +- thermal zones: used to describe thermal data within the hardware;
>>>>> +
>>>>> +It follows a description of each type of these device tree nodes.
>>>>> +
>>>>> +* Sensor devices
>>>>> +
>>>>> +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. Temperature sensor
>>>>> devices may
>>>>> +control one or more internal sensors.
>>>>> +
>>>>> +Required property:
>>>>> +- #sensor-cells:       Used to provide sensor device specific
>>>>> information
>>>>> +                       while referring to it. Must be at least 1, 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.
>>>> I don't see why this needs to be at least one cell -- if an IC only has
>>>> one temperature sensor it should be fine for this to be zero and
>>>> have no
>>>> ambiguity.
>>>>
>>>> It may make sense to call these thermal sensor devices, there are
>>>> plenty
>>>> of other sensors we might want to describe in the dt for other
>>>> purposes,
>>>> and we can impose some consistency if we remove the ambiguity.
>>>>
>>>>> +
>>>>> +* 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. 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 level of cooling.
>>>>> +
>>>>> +Required property:
>>>>> +- cooling-min-level:   A unsigned integer indicating the smallest
>>>>> +                       cooling level accepted. Typically 0.
>>>>> +- cooling-max-level:   An unsigned integer indicating the largest
>>>>> +                       cooling level accepted.
>>>> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
>>>> this binding specific?
>>> It means cooling ability of a cooling device, such as speed of a fan.
>>> But it is better to use cooling-min/max-state I think, because the
>>> thermal management code is using "cooling state", concepts in dt and c
>>> should be identical.
>> I think the idea is just to be clear. Just because the thermal
>> management implementation uses a terminology, it does not necessarily
>> mean it is best fit for describing in device tree bindings. But I dont
>> really have strong opinion on level or state at this point.
>>
>>>> How does this relate to cooling-cells? These seem to be a fixed size.
>>> I also think cooling-cells is redundant.
>> Cooling cells is not redundant, please check my explanation on the other
>> thread. It is required to determine which level/states are used while
>> binding.
>>
> OK
> 
>>>>> +- #cooling-cells:      Used to provide cooling device specific
>>>>> information
>>>>> +                       while referring to it. Must be at least 2, in
>>>>> order
>>>>> +                       to specify minimum and maximum cooling level
>>>>> used
>>>>> +                       in the reference. See Cooling device
>>>>> attachments section
>>>>> +                       below for more details on how consumers
>>>>> refer to
>>>>> +                       cooling devices.
>>>> Are these cooling cells always expected to cover min and max, and are
>>>> min and max always expected to take the same number of cells? The above
>>>> cooling-*-level properties imply they each take up one cell.
>>>>
>>>> Does #cooling-cells = <3> make sense?. If this covers additional
>>>> information (e.g. which fan on a multi-fan controller), how does the OS
>>>> determine which cells are min and max, and how do these relate to
>>>> cooling-level-min and cooling-level-max?
>>>>
>>>>> +
>>>>> +* 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.
>>>> I'm still not sure on this, as it sounds like embedding policy into the
>>>> DT, rather than a description of the hardware. I realise we need to
>>>> prevent devices burning out, so describing the max acceptable
>>>> temperature and possibly a preferred range makes sense, but do we need
>>>> this level of flexibility? Maybe we do.
>>>>
>>> Putting platform data into dt is acceptable, right?
>>> In a narrow sense, trip points are platform data, but in a broad sense,
>>> both trip point itself and its corresponding cooling device are all
>>> platform data.
>>>
>> I think Mark needs to elaborate a bit more to clarify why he sees this
>> as embedding policy into DT. And I believe it is fine to pass platform
>> data, as long as it represents hardware and it is  not representing
>> policy.
>>
>>>>> +
>>>>> +Required properties:
>>>>> +- temperature:         the trip temperature level, in milliCelsius.
>>>> Preferably, s/milliCelsius/millicelsius/ over the document.
>>>>
>>>> Given that we have signed values elsewhere, is this signed or unsigned?
>>>>
>>>>> +- hysteresis:          a (low) hysteresis value on 'temperature'.
>>>>> This is a
>>>>> +                       relative value, in milliCelsius.
>>>>> +- type:                        the trip type. Here is the type
>>>>> mapping:
>>>>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active
>>>>> cooling
>>>>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable
>>>>> passive cooling
>>>>> +       THERMAL_TRIP_HOT        2:      A trip point to notify
>>>>> emergency
>>>>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>>>>> +
>>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>>> these consts.
>>>> Why not use a string for this? We do so for other type parameters in
>>>> other bindings (see dr_mode in
>>>> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for
>>>> ethernet
>>>> PHYs, etc).
>>>>
>>>>> +
>>>>> +* Cooling device attachments
>>>>> +
>>>>> +The cooling device attachments 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
>>>>> parameters,
>>>>> +                       referring to which cooling device is used in
>>>>> this
>>>>> +                       binding. The required parameters are: the
>>>>> minimum
>>>>> +                       cooling level and the maximum cooling level
>>>>> used
>>>>> +                       in this attach.
>>>> Might this be a list in general? The code doesn't have to support that
>>>> yet.
>>>>
>>>> It would be nice to have a name for the cells after a phandle which
>>>> describe the cooling device's configuration. You've called them
>>>> parameters here, but it probably makes sense to call them a
>>>> cooling-specifier (following clock-specifier and interrupt-specifier).
>>>>
>>>>> +- trip:                        A phandle of a trip point node within
>>>>> the same thermal
>>>>> +                       zone.
>>>>> +
>>>>> +Optional property:
>>>>> +- contribution:                The cooling contribution to the
>>>>> thermal zone of the
>>>>> +                       referred cooling device at the referred trip
>>>>> point.
>>>>> +                       The contribution is a value from 0 to 100.
>>>>> The sum
>>>>> +                       of all cooling contributions within a thermal
>>>>> zone
>>>>> +                       must never exceed 100.
>>>> This is a bit arbitrary. Couldn't we sum all contributions to find the
>>>> total automatically, so this could be a simpler ratio?
>>>>
>>>>> +
>>>>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the
>>>>> cooling-device phandle
>>>>> +limit parameters means:
>>>>> +(i)   - minimum level allowed for minimum cooling level used in the
>>>>> reference.
>>>>> +(ii)  - maximum level allowed for maximum cooling level used in the
>>>>> reference.
>>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>>> this constant.
>>>>> +
>>>>> +* Thermal zones
>>>>> +
>>>>> +The thermal-zone node is the node containing all the required info
>>>>> +for describing a thermal zone, including its cdev 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 attachments.
>>>> s/cdev/cooling device/ ?
>>>>
>>>>> +
>>>>> +Required properties:
>>>>> +- passive-delay:       The maximum number of milliseconds to wait
>>>>> between polls
>>>>> +                       when performing passive cooling.
>>>>> +- polling-delay:       The maximum number of milliseconds to wait
>>>>> between polls
>>>>> +                       when checking this thermal zone.
>>>> How about polling-delay-passive, polling-delay-active? I'm still not
>>>>
>>>>> +- sensors:             A list of sensor phandles and their
>>>>> parameters. The
>>>>> +                       required parameter is the sensor id, in
>>>>> order to
>>>>> +                       identify internal sensors when the sensor IC
>>>>> features
>>>>> +                       several sensing units.
>>>> As mentioned above, I'm not sure you even need that one cell.
>>>>
>>>> - sensors:                A list of sensor phandle +
>>>> thermal-sensor-specifier
>>>>                             cells describing the sensors monitoring the
>>>> thermal
>>>>                zone.
>>>>
>>>>> +- trips:               A sub-node containing several trip point
>>>>> nodes required
>>>>> +                       to describe the thermal zone.
>>>>> +- cooling-attachments  A sub-node containing several cooling device
>>>>> attaches
>>>>> +                       nodes, used to describe the relation between
>>>>> trips
>>>>> +                       and cooling devices.
>>>>> +
>>>>> +Optional property:
>>>>> +- coefficients:                An array of integers (one signed
>>>>> cell) containing
>>>>> +                       coefficients to compose a linear relation
>>>>> between
>>>>> +                       the sensors described in the sensors property.
>>>>> +                       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.
>>>> What is the end result of this? Presumably this is meant to result
>>>> in an
>>>> estimate of the average temperature of the thermal zone, rather than an
>>>> arbitrary value? This should be mentioned.
>>>>
>>>> This doesn't seem to be used the in the code below...
>>>>
>>>>> +
>>>>> +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 (passive-delay); 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.
>>>> I'm not sure what you mean by this, could you elaborate?
>>>>
>>>> I guess you mean that the delays should be chosen to account for said
>>>> max dT/dt, such that a device can't unexpectedly cross several trip
>>>> boundaries between polls?
>>>>
>>>>> +
>>>>> +* 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-level = <0>;
>>>>> +               cooling-max-level = <3>;
>>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>>> +       };
>>>> What do those min and max mean in this context? What do the values in
>>>> the range [0,3] correspond to?
>>>>
>>>> I'm not sure it makes sense to describe passive cooling in this way --
>>>> the precise way an OS does less work on a device is fundamentally tied
>>>> to the design of the OS (it might be able to rate-limit requests, it
>>>> might be able to clock the device down, it might only be able to turn
>>>> the device off).
>>>>
>>>> I'm not sure there is anything we can describe for passive cooling
>>>> (beyond the thermal limits the OS should attempt to stick to).
>>>>
>>>>> +       ...
>>>>> +};
>>>>> +
>>>>> +&i2c1 {
>>>>> +       ...
>>>>> +       fan0: fan@0x48 {
>>>>> +               ...
>>>>> +               cooling-min-level = <0>;
>>>>> +               cooling-max-level = <9>;
>>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>>> +       };
>>>> What do min and max mean here for the fan?
>>>>
>>> It means the speed level of a fan. Even if a fan can run at a continuous
>>> speed range, but when it is controlled under thermal management
>>> framework, it can only run at discrete speeds.
>>
>> Please, an important point here, this is not about thermal framework
>> requirement. But how we describe hardware. As you mentioned, even if
>> there are fan devices out there that uses continuous speed range, there
>> other devices, even fan devices or cpu frequency steps for instance,
>> that are discrete. Again, *this is not a thermal framework requirement*.
>>
>>>>> +};
>>>>> +
>>>>> +bandgap0: bandgap@0x0000ED00 {
>>>>> +       ...
>>>>> +       #sensor-cells = <1>;
>>>>> +};
>>>>> +
>>>>> +cpu-thermal: cpu-thermal {
>>>> How do the thermal zones get probed?
>>>>
>>>>> +       passive-delay = <250>; /* milliseconds */
>>>>> +       polling-delay = <1000>; /* milliseconds */
>>>>> +
>>>>> +               /* sensor       ID */
>>>>> +        sensors = <&bandgap0     0>;
>>>>> +
>>>>> +        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-attachments {
>>>>> +               attach0 {
>>>>> +                       trip = <&cpu-alert0>;
>>>>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>>>>> +               };
>>>>> +               attach1 {
>>>>> +                       trip = <&cpu-alert1>;
>>>>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>>>>> +               };
>>>>> +               attach2 {
>>>>> +                       trip = <&cpu-alert1>;
>>>>> +                       cooling-device =
>>>>> +                               <&cpu0 THERMAL_NO_LIMITS
>>>>> THERMAL_NO_LIMITS>;
>>>>> +               };
>>>>> +       };
>>>> Was there a good reason for splitting trips and attachment?
>>> This is for adding/removing cooling device dynamically.
>> Well not really. I don't think this would prevent us of representing it
>> inside the trip point. It is, as I replied to Mark, because I wanted to
>> keep the flexibility to allow describing better properties related to
>> the cooling device while associated to a trip point alone, e.g.
>> 'contribution'.
> 
> Understand your purpose and explanation.
> But this can also really help to add/remove cooling device freely, there
> were already drivers with separated files of thermal zone and cooling
> device.

Right. The idea is of course to probe cooling devices independently from
thermal zone devices, and also from thermal sensor devices. With this
series we will achieve that state.

Currently, thermal drivers have several responsibilities: control the
sensor, report the thermal zone requirements and probe cooling devices.

On top of this series, using device tree, cooling devices are supposed
to be probed based on their nodes. I have started to do this with the
cpufreq cooling device. And it is usable already. Thermal zone devices
will be probed by the of-thermal.c code. And thermal sensors will be
probed by their own driver, but they need to be registered to a thermal
zone, so that the zone gets enabled.

However, the specific point we are talking about, is more about how the
zone gets connected to the cooling device. But the probing of this
cooling device is not triggered by the node above, which is just
describing the connection. As I mentioned, the cooling device needs to
be probed based on the node that this connection points to, by means of
a phandle.

Just like regulators, or dma, or interrupts are mapped. Here the thermal
zone is a consumer, in a way, of the cooling device and of the sensor
device.

I hope this is clear in the documentation I am writing. Please let me
know if not.

> 
>>>>> +};
>>>>> +
>>>>> +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, is used to remove the heat out of the
>>>>> thermal
>>>>> +zone 'cpu-thermal' using its cooling levels 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 level.
>>>>> +The cpu@0 device is also linked to the same thermal zone,
>>>>> 'cpu-thermal', as a
>>>>> +passive cooling device, using all its cooling levels at trip point
>>>>> 'cpu-alert1',
>>>>> +which is a trip point at 100C.
>>>>> +
>>>
>>>
>>>
>>>
>>
> 
> 
> 
> 
> 


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

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 25-09-2013 01:39, Hongbo Zhang wrote:
> On 09/24/2013 11:50 PM, Eduardo Valentin wrote:
>> Zhang,
>>
>> I appreciate your interest. I am replying a couple of your comments.
>> Please also check my answers to Mark's queries on other email thread.
> When I replied to Mark yesterday, I missed your mail replying him already.
> I should check that mail and reply it for further concerns.
>> On 24-09-2013 04:11, Hongbo Zhang wrote:
>>> On 09/23/2013 06:40 PM, Mark Rutland wrote:
>>>> Hi Eduardo,
>>>>
>>>> Apologies for having taken so long to get back you on this.
>>>>
>>>> I have several comments on the binding and the way it's parsed.
>>>>
>>>> On Wed, Sep 18, 2013 at 10:35:36PM +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>
>>>>> ---
>>>>>    .../devicetree/bindings/thermal/thermal.txt        | 498
>>>>> +++++++++++++
>>>>>    drivers/thermal/Kconfig                            |  13 +
>>>>>    drivers/thermal/Makefile                           |   1 +
>>>>>    drivers/thermal/of-thermal.c                       | 775
>>>>> +++++++++++++++++++++
>>>>>    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, 1357 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
>>>>>
>>>>> ---
>>>>>
>>>>> Hello all,
>>>>>
>>>>> Thanks Joe Perches for the effort of reviewing this code, I really
>>>>> appreciate it.
>>>>>
>>>>> Here is a version with a refactored init function without leaks in
>>>>> the failure
>>>>> patch. I also added a couple of comments to better understand the
>>>>> intention of
>>>>> that function. Besides, when there are no memory available, the
>>>>> function
>>>>> rolls back what ever thermal zones have been added.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eduardo
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
>>>>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>>> new file mode 100644
>>>>> index 0000000..6664533
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>>>>> @@ -0,0 +1,498 @@
>>>>> +* 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 attachments: used to describe links between trip points and
>>>>> +cooling devices;
>>>> I think "attachments" sounds a bit odd, though I don't have a better
>>>> naming suggestion.
>>> "map" or "mapping" is better?
>> Well,  yeah, that could work.
> :)
>>>>> +- thermal zones: used to describe thermal data within the hardware;
>>>>> +
>>>>> +It follows a description of each type of these device tree nodes.
>>>>> +
>>>>> +* Sensor devices
>>>>> +
>>>>> +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. Temperature sensor
>>>>> devices may
>>>>> +control one or more internal sensors.
>>>>> +
>>>>> +Required property:
>>>>> +- #sensor-cells:       Used to provide sensor device specific
>>>>> information
>>>>> +                       while referring to it. Must be at least 1, 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.
>>>> I don't see why this needs to be at least one cell -- if an IC only has
>>>> one temperature sensor it should be fine for this to be zero and
>>>> have no
>>>> ambiguity.
>>>>
>>>> It may make sense to call these thermal sensor devices, there are
>>>> plenty
>>>> of other sensors we might want to describe in the dt for other
>>>> purposes,
>>>> and we can impose some consistency if we remove the ambiguity.
>>>>
>>>>> +
>>>>> +* 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. 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 level of cooling.
>>>>> +
>>>>> +Required property:
>>>>> +- cooling-min-level:   A unsigned integer indicating the smallest
>>>>> +                       cooling level accepted. Typically 0.
>>>>> +- cooling-max-level:   An unsigned integer indicating the largest
>>>>> +                       cooling level accepted.
>>>> I'm not sure what a "cooling level" means. It seems a bit abstract. Is
>>>> this binding specific?
>>> It means cooling ability of a cooling device, such as speed of a fan.
>>> But it is better to use cooling-min/max-state I think, because the
>>> thermal management code is using "cooling state", concepts in dt and c
>>> should be identical.
>> I think the idea is just to be clear. Just because the thermal
>> management implementation uses a terminology, it does not necessarily
>> mean it is best fit for describing in device tree bindings. But I dont
>> really have strong opinion on level or state at this point.
>>
>>>> How does this relate to cooling-cells? These seem to be a fixed size.
>>> I also think cooling-cells is redundant.
>> Cooling cells is not redundant, please check my explanation on the other
>> thread. It is required to determine which level/states are used while
>> binding.
>>
> OK
> 
>>>>> +- #cooling-cells:      Used to provide cooling device specific
>>>>> information
>>>>> +                       while referring to it. Must be at least 2, in
>>>>> order
>>>>> +                       to specify minimum and maximum cooling level
>>>>> used
>>>>> +                       in the reference. See Cooling device
>>>>> attachments section
>>>>> +                       below for more details on how consumers
>>>>> refer to
>>>>> +                       cooling devices.
>>>> Are these cooling cells always expected to cover min and max, and are
>>>> min and max always expected to take the same number of cells? The above
>>>> cooling-*-level properties imply they each take up one cell.
>>>>
>>>> Does #cooling-cells = <3> make sense?. If this covers additional
>>>> information (e.g. which fan on a multi-fan controller), how does the OS
>>>> determine which cells are min and max, and how do these relate to
>>>> cooling-level-min and cooling-level-max?
>>>>
>>>>> +
>>>>> +* 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.
>>>> I'm still not sure on this, as it sounds like embedding policy into the
>>>> DT, rather than a description of the hardware. I realise we need to
>>>> prevent devices burning out, so describing the max acceptable
>>>> temperature and possibly a preferred range makes sense, but do we need
>>>> this level of flexibility? Maybe we do.
>>>>
>>> Putting platform data into dt is acceptable, right?
>>> In a narrow sense, trip points are platform data, but in a broad sense,
>>> both trip point itself and its corresponding cooling device are all
>>> platform data.
>>>
>> I think Mark needs to elaborate a bit more to clarify why he sees this
>> as embedding policy into DT. And I believe it is fine to pass platform
>> data, as long as it represents hardware and it is  not representing
>> policy.
>>
>>>>> +
>>>>> +Required properties:
>>>>> +- temperature:         the trip temperature level, in milliCelsius.
>>>> Preferably, s/milliCelsius/millicelsius/ over the document.
>>>>
>>>> Given that we have signed values elsewhere, is this signed or unsigned?
>>>>
>>>>> +- hysteresis:          a (low) hysteresis value on 'temperature'.
>>>>> This is a
>>>>> +                       relative value, in milliCelsius.
>>>>> +- type:                        the trip type. Here is the type
>>>>> mapping:
>>>>> +       THERMAL_TRIP_ACTIVE     0:      A trip point to enable active
>>>>> cooling
>>>>> +       THERMAL_TRIP_PASSIVE    1:      A trip point to enable
>>>>> passive cooling
>>>>> +       THERMAL_TRIP_HOT        2:      A trip point to notify
>>>>> emergency
>>>>> +       THERMAL_TRIP_CRITICAL   3:      Hardware not reliable.
>>>>> +
>>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>>> these consts.
>>>> Why not use a string for this? We do so for other type parameters in
>>>> other bindings (see dr_mode in
>>>> Documentation/devicetree/bindings/usb/generic.txt, phy-mode for
>>>> ethernet
>>>> PHYs, etc).
>>>>
>>>>> +
>>>>> +* Cooling device attachments
>>>>> +
>>>>> +The cooling device attachments 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
>>>>> parameters,
>>>>> +                       referring to which cooling device is used in
>>>>> this
>>>>> +                       binding. The required parameters are: the
>>>>> minimum
>>>>> +                       cooling level and the maximum cooling level
>>>>> used
>>>>> +                       in this attach.
>>>> Might this be a list in general? The code doesn't have to support that
>>>> yet.
>>>>
>>>> It would be nice to have a name for the cells after a phandle which
>>>> describe the cooling device's configuration. You've called them
>>>> parameters here, but it probably makes sense to call them a
>>>> cooling-specifier (following clock-specifier and interrupt-specifier).
>>>>
>>>>> +- trip:                        A phandle of a trip point node within
>>>>> the same thermal
>>>>> +                       zone.
>>>>> +
>>>>> +Optional property:
>>>>> +- contribution:                The cooling contribution to the
>>>>> thermal zone of the
>>>>> +                       referred cooling device at the referred trip
>>>>> point.
>>>>> +                       The contribution is a value from 0 to 100.
>>>>> The sum
>>>>> +                       of all cooling contributions within a thermal
>>>>> zone
>>>>> +                       must never exceed 100.
>>>> This is a bit arbitrary. Couldn't we sum all contributions to find the
>>>> total automatically, so this could be a simpler ratio?
>>>>
>>>>> +
>>>>> +Note: Using the THERMAL_NO_LIMIT (-1L) constant in the
>>>>> cooling-device phandle
>>>>> +limit parameters means:
>>>>> +(i)   - minimum level allowed for minimum cooling level used in the
>>>>> reference.
>>>>> +(ii)  - maximum level allowed for maximum cooling level used in the
>>>>> reference.
>>>>> +Refer to include/dt-bindings/thermal/thermal.h for definition of
>>>>> this constant.
>>>>> +
>>>>> +* Thermal zones
>>>>> +
>>>>> +The thermal-zone node is the node containing all the required info
>>>>> +for describing a thermal zone, including its cdev 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 attachments.
>>>> s/cdev/cooling device/ ?
>>>>
>>>>> +
>>>>> +Required properties:
>>>>> +- passive-delay:       The maximum number of milliseconds to wait
>>>>> between polls
>>>>> +                       when performing passive cooling.
>>>>> +- polling-delay:       The maximum number of milliseconds to wait
>>>>> between polls
>>>>> +                       when checking this thermal zone.
>>>> How about polling-delay-passive, polling-delay-active? I'm still not
>>>>
>>>>> +- sensors:             A list of sensor phandles and their
>>>>> parameters. The
>>>>> +                       required parameter is the sensor id, in
>>>>> order to
>>>>> +                       identify internal sensors when the sensor IC
>>>>> features
>>>>> +                       several sensing units.
>>>> As mentioned above, I'm not sure you even need that one cell.
>>>>
>>>> - sensors:                A list of sensor phandle +
>>>> thermal-sensor-specifier
>>>>                             cells describing the sensors monitoring the
>>>> thermal
>>>>                zone.
>>>>
>>>>> +- trips:               A sub-node containing several trip point
>>>>> nodes required
>>>>> +                       to describe the thermal zone.
>>>>> +- cooling-attachments  A sub-node containing several cooling device
>>>>> attaches
>>>>> +                       nodes, used to describe the relation between
>>>>> trips
>>>>> +                       and cooling devices.
>>>>> +
>>>>> +Optional property:
>>>>> +- coefficients:                An array of integers (one signed
>>>>> cell) containing
>>>>> +                       coefficients to compose a linear relation
>>>>> between
>>>>> +                       the sensors described in the sensors property.
>>>>> +                       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.
>>>> What is the end result of this? Presumably this is meant to result
>>>> in an
>>>> estimate of the average temperature of the thermal zone, rather than an
>>>> arbitrary value? This should be mentioned.
>>>>
>>>> This doesn't seem to be used the in the code below...
>>>>
>>>>> +
>>>>> +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 (passive-delay); 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.
>>>> I'm not sure what you mean by this, could you elaborate?
>>>>
>>>> I guess you mean that the delays should be chosen to account for said
>>>> max dT/dt, such that a device can't unexpectedly cross several trip
>>>> boundaries between polls?
>>>>
>>>>> +
>>>>> +* 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-level = <0>;
>>>>> +               cooling-max-level = <3>;
>>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>>> +       };
>>>> What do those min and max mean in this context? What do the values in
>>>> the range [0,3] correspond to?
>>>>
>>>> I'm not sure it makes sense to describe passive cooling in this way --
>>>> the precise way an OS does less work on a device is fundamentally tied
>>>> to the design of the OS (it might be able to rate-limit requests, it
>>>> might be able to clock the device down, it might only be able to turn
>>>> the device off).
>>>>
>>>> I'm not sure there is anything we can describe for passive cooling
>>>> (beyond the thermal limits the OS should attempt to stick to).
>>>>
>>>>> +       ...
>>>>> +};
>>>>> +
>>>>> +&i2c1 {
>>>>> +       ...
>>>>> +       fan0: fan@0x48 {
>>>>> +               ...
>>>>> +               cooling-min-level = <0>;
>>>>> +               cooling-max-level = <9>;
>>>>> +               #cooling-cells = <2>; /* min followed by max */
>>>>> +       };
>>>> What do min and max mean here for the fan?
>>>>
>>> It means the speed level of a fan. Even if a fan can run at a continuous
>>> speed range, but when it is controlled under thermal management
>>> framework, it can only run at discrete speeds.
>>
>> Please, an important point here, this is not about thermal framework
>> requirement. But how we describe hardware. As you mentioned, even if
>> there are fan devices out there that uses continuous speed range, there
>> other devices, even fan devices or cpu frequency steps for instance,
>> that are discrete. Again, *this is not a thermal framework requirement*.
>>
>>>>> +};
>>>>> +
>>>>> +bandgap0: bandgap@0x0000ED00 {
>>>>> +       ...
>>>>> +       #sensor-cells = <1>;
>>>>> +};
>>>>> +
>>>>> +cpu-thermal: cpu-thermal {
>>>> How do the thermal zones get probed?
>>>>
>>>>> +       passive-delay = <250>; /* milliseconds */
>>>>> +       polling-delay = <1000>; /* milliseconds */
>>>>> +
>>>>> +               /* sensor       ID */
>>>>> +        sensors = <&bandgap0     0>;
>>>>> +
>>>>> +        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-attachments {
>>>>> +               attach0 {
>>>>> +                       trip = <&cpu-alert0>;
>>>>> +                       cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
>>>>> +               };
>>>>> +               attach1 {
>>>>> +                       trip = <&cpu-alert1>;
>>>>> +                       cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
>>>>> +               };
>>>>> +               attach2 {
>>>>> +                       trip = <&cpu-alert1>;
>>>>> +                       cooling-device =
>>>>> +                               <&cpu0 THERMAL_NO_LIMITS
>>>>> THERMAL_NO_LIMITS>;
>>>>> +               };
>>>>> +       };
>>>> Was there a good reason for splitting trips and attachment?
>>> This is for adding/removing cooling device dynamically.
>> Well not really. I don't think this would prevent us of representing it
>> inside the trip point. It is, as I replied to Mark, because I wanted to
>> keep the flexibility to allow describing better properties related to
>> the cooling device while associated to a trip point alone, e.g.
>> 'contribution'.
> 
> Understand your purpose and explanation.
> But this can also really help to add/remove cooling device freely, there
> were already drivers with separated files of thermal zone and cooling
> device.

Right. The idea is of course to probe cooling devices independently from
thermal zone devices, and also from thermal sensor devices. With this
series we will achieve that state.

Currently, thermal drivers have several responsibilities: control the
sensor, report the thermal zone requirements and probe cooling devices.

On top of this series, using device tree, cooling devices are supposed
to be probed based on their nodes. I have started to do this with the
cpufreq cooling device. And it is usable already. Thermal zone devices
will be probed by the of-thermal.c code. And thermal sensors will be
probed by their own driver, but they need to be registered to a thermal
zone, so that the zone gets enabled.

However, the specific point we are talking about, is more about how the
zone gets connected to the cooling device. But the probing of this
cooling device is not triggered by the node above, which is just
describing the connection. As I mentioned, the cooling device needs to
be probed based on the node that this connection points to, by means of
a phandle.

Just like regulators, or dma, or interrupts are mapped. Here the thermal
zone is a consumer, in a way, of the cooling device and of the sensor
device.

I hope this is clear in the documentation I am writing. Please let me
know if not.

> 
>>>>> +};
>>>>> +
>>>>> +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, is used to remove the heat out of the
>>>>> thermal
>>>>> +zone 'cpu-thermal' using its cooling levels 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 level.
>>>>> +The cpu@0 device is also linked to the same thermal zone,
>>>>> 'cpu-thermal', as a
>>>>> +passive cooling device, using all its cooling levels at trip point
>>>>> 'cpu-alert1',
>>>>> +which is a trip point at 100C.
>>>>> +
>>>
>>>
>>>
>>>
>>
> 
> 
> 
> 
> 


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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 23-09-2013 06:40, Mark Rutland wrote:
> 
> It would be nice to have a name for the cells after a phandle which
> describe the cooling device's configuration. You've called them
> parameters here, but it probably makes sense to call them a
> cooling-specifier (following clock-specifier and interrupt-specifier).

Maybe it was not very clear, and I am working on improving this, but
what I am proposing is simply to have:
 cooling-device = <&cdev min max>

where min and max are one cell unsigned values referring to minimum
cooling level and maximum cooling level, for this reference. Note that
'cdev' may have 10 levels, but in this reference we may use only from 6
to 10:
 cooling-device = <&cdev 6 10>;

I don't see a need to have a cooling-names for this case. And for now, I
also don't see why we would use other specifiers. But we can leave it
open for future extensions.

It does make sense to have thermal-sensor-names (using thermal-sensor as
per your suggestion). Because it makes clear where the sensor is in the
case of using several sensors in one zone. Just like in the example I
already gave:
> +cpu-thermal: cpu-thermal {
> +	polling-delay-passive = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +     thermal-sensors = <&bandgap0	0>,
> +		  	  <&adc		0>;
> +	thermal-sensors-names = "cpu", "pcb north";
> +
> +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
> +	coefficients = 		<100	-120	484>;
> +
> +        trips {
> +		...
> +        };
> +
> +	cooling-attachments {
> +		...
> +	};
> +};



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

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 23-09-2013 06:40, Mark Rutland wrote:
> 
> It would be nice to have a name for the cells after a phandle which
> describe the cooling device's configuration. You've called them
> parameters here, but it probably makes sense to call them a
> cooling-specifier (following clock-specifier and interrupt-specifier).

Maybe it was not very clear, and I am working on improving this, but
what I am proposing is simply to have:
 cooling-device = <&cdev min max>

where min and max are one cell unsigned values referring to minimum
cooling level and maximum cooling level, for this reference. Note that
'cdev' may have 10 levels, but in this reference we may use only from 6
to 10:
 cooling-device = <&cdev 6 10>;

I don't see a need to have a cooling-names for this case. And for now, I
also don't see why we would use other specifiers. But we can leave it
open for future extensions.

It does make sense to have thermal-sensor-names (using thermal-sensor as
per your suggestion). Because it makes clear where the sensor is in the
case of using several sensors in one zone. Just like in the example I
already gave:
> +cpu-thermal: cpu-thermal {
> +	polling-delay-passive = <250>; /* milliseconds */
> +	polling-delay = <1000>; /* milliseconds */
> +
> +		/* sensor       ID */
> +     thermal-sensors = <&bandgap0	0>,
> +		  	  <&adc		0>;
> +	thermal-sensors-names = "cpu", "pcb north";
> +
> +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
> +	coefficients = 		<100	-120	484>;
> +
> +        trips {
> +		...
> +        };
> +
> +	cooling-attachments {
> +		...
> +	};
> +};



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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Mark Rutland]

On Tue, Sep 24, 2013 at 10:33:19PM +0100, Eduardo Valentin wrote:
> On 23-09-2013 06:40, Mark Rutland wrote:
> > 
> > It would be nice to have a name for the cells after a phandle which
> > describe the cooling device's configuration. You've called them
> > parameters here, but it probably makes sense to call them a
> > cooling-specifier (following clock-specifier and interrupt-specifier).
> 
> Maybe it was not very clear, and I am working on improving this, but
> what I am proposing is simply to have:
>  cooling-device = <&cdev min max>
> 
> where min and max are one cell unsigned values referring to minimum
> cooling level and maximum cooling level, for this reference. Note that
> 'cdev' may have 10 levels, but in this reference we may use only from 6
> to 10:
>  cooling-device = <&cdev 6 10>;
> 
> I don't see a need to have a cooling-names for this case. And for now, I
> also don't see why we would use other specifiers. But we can leave it
> open for future extensions.

There seesm to be some confusion ehre, so let me clarify.  I was asking
for consistent terminology (i.e. "cooling-specifier" rather than
"parameters"), not *-names properties. Consistent terminology and style
makes binding far easier to read.

> 
> It does make sense to have thermal-sensor-names (using thermal-sensor as
> per your suggestion). Because it makes clear where the sensor is in the
> case of using several sensors in one zone. Just like in the example I
> already gave:

Is there a way this can be useful at run-time, or could this just be
achieved with comments in the dt?

> > +cpu-thermal: cpu-thermal {
> > +	polling-delay-passive = <250>; /* milliseconds */
> > +	polling-delay = <1000>; /* milliseconds */
> > +
> > +		/* sensor       ID */
> > +     thermal-sensors = <&bandgap0	0>,
> > +		  	  <&adc		0>;
> > +	thermal-sensors-names = "cpu", "pcb north";
> > +
> > +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
> > +	coefficients = 		<100	-120	484>;
> > +
> > +        trips {
> > +		...
> > +        };
> > +
> > +	cooling-attachments {
> > +		...
> > +	};
> > +};

Cheers,
Mark.

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Mark Rutland]

On Tue, Sep 24, 2013 at 10:33:19PM +0100, Eduardo Valentin wrote:
> On 23-09-2013 06:40, Mark Rutland wrote:
> > 
> > It would be nice to have a name for the cells after a phandle which
> > describe the cooling device's configuration. You've called them
> > parameters here, but it probably makes sense to call them a
> > cooling-specifier (following clock-specifier and interrupt-specifier).
> 
> Maybe it was not very clear, and I am working on improving this, but
> what I am proposing is simply to have:
>  cooling-device = <&cdev min max>
> 
> where min and max are one cell unsigned values referring to minimum
> cooling level and maximum cooling level, for this reference. Note that
> 'cdev' may have 10 levels, but in this reference we may use only from 6
> to 10:
>  cooling-device = <&cdev 6 10>;
> 
> I don't see a need to have a cooling-names for this case. And for now, I
> also don't see why we would use other specifiers. But we can leave it
> open for future extensions.

There seesm to be some confusion ehre, so let me clarify.  I was asking
for consistent terminology (i.e. "cooling-specifier" rather than
"parameters"), not *-names properties. Consistent terminology and style
makes binding far easier to read.

> 
> It does make sense to have thermal-sensor-names (using thermal-sensor as
> per your suggestion). Because it makes clear where the sensor is in the
> case of using several sensors in one zone. Just like in the example I
> already gave:

Is there a way this can be useful at run-time, or could this just be
achieved with comments in the dt?

> > +cpu-thermal: cpu-thermal {
> > +	polling-delay-passive = <250>; /* milliseconds */
> > +	polling-delay = <1000>; /* milliseconds */
> > +
> > +		/* sensor       ID */
> > +     thermal-sensors = <&bandgap0	0>,
> > +		  	  <&adc		0>;
> > +	thermal-sensors-names = "cpu", "pcb north";
> > +
> > +		/* hotspot = 100 * bandgap - 120 * adc + 484 */
> > +	coefficients = 		<100	-120	484>;
> > +
> > +        trips {
> > +		...
> > +        };
> > +
> > +	cooling-attachments {
> > +		...
> > +	};
> > +};

Cheers,
Mark.

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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>   
> [...]
> +
> +/***   sensor API   ***/
> +

You are introducing new concept here, the original framework and drivers 
cannot use this, right? any further plan to update original framework 
for this new feature?

> +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);
> +
> [...]
> +
> +/*
> + * Here are the thermal trip types. This must
> + * match with enum thermal_trip_type at
> + * include/linux/thermal.h
> + */
> +#define THERMAL_TRIP_ACTIVE		0
> +#define THERMAL_TRIP_PASSIVE		1
> +#define THERMAL_TRIP_HOT		2
> +#define THERMAL_TRIP_CRITICAL		3
> +

These macros seem duplicated with enum thermal_trip_type in thermal.h, 
do you have further plan to merge them?
Or by using string "active",  "passive" etc in the dts, then you can 
reuse the original enum definition.

> +/* On cooling devices upper and lower limits */
> +#define THERMAL_NO_LIMIT		(-1UL)
> +
> +#endif
> [...]

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>   
> [...]
> +
> +/***   sensor API   ***/
> +

You are introducing new concept here, the original framework and drivers 
cannot use this, right? any further plan to update original framework 
for this new feature?

> +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);
> +
> [...]
> +
> +/*
> + * Here are the thermal trip types. This must
> + * match with enum thermal_trip_type at
> + * include/linux/thermal.h
> + */
> +#define THERMAL_TRIP_ACTIVE		0
> +#define THERMAL_TRIP_PASSIVE		1
> +#define THERMAL_TRIP_HOT		2
> +#define THERMAL_TRIP_CRITICAL		3
> +

These macros seem duplicated with enum thermal_trip_type in thermal.h, 
do you have further plan to merge them?
Or by using string "active",  "passive" etc in the dts, then you can 
reuse the original enum definition.

> +/* On cooling devices upper and lower limits */
> +#define THERMAL_NO_LIMIT		(-1UL)
> +
> +#endif
> [...]

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>   
> [...]
> +
> +/***   sensor API   ***/
> +

You are introducing new concept here, the original framework and drivers 
cannot use this, right? any further plan to update original framework 
for this new feature?

> +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);
> +
> [...]
> +
> +/*
> + * Here are the thermal trip types. This must
> + * match with enum thermal_trip_type at
> + * include/linux/thermal.h
> + */
> +#define THERMAL_TRIP_ACTIVE		0
> +#define THERMAL_TRIP_PASSIVE		1
> +#define THERMAL_TRIP_HOT		2
> +#define THERMAL_TRIP_CRITICAL		3
> +

These macros seem duplicated with enum thermal_trip_type in thermal.h, 
do you have further plan to merge them?
Or by using string "active",  "passive" etc in the dts, then you can 
reuse the original enum definition.

> +/* On cooling devices upper and lower limits */
> +#define THERMAL_NO_LIMIT		(-1UL)
> +
> +#endif
> [...]



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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 25-09-2013 03:13, Hongbo Zhang wrote:
> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>   [...]
>> +
>> +/***   sensor API   ***/
>> +
> 
> You are introducing new concept here, the original framework and drivers
> cannot use this, right? any further plan to update original framework
> for this new feature?
> 

Well, not new as such. Just a specific way to register sensors to
thermal framework. What is really new is the fact that we really need to
have sensors decoupled from thermal zone devices, and today we have
these concepts pretty merged together.

To answer your question, for now I am more concerned with the bindings
definition. Once that is at least agreed, then we can follow up with the
migration of existing drivers. For now, there are two examples in this
series, first one is using one existing thermal driver, which is the TI
SoC thermal driver, and the second one is the hwmon drivers, which are
existing sensor drivers, but are not thermal drivers.

The plan forward, once this series is accepted is to migrate existing
drivers, yes, so that they can use device tree uniformly. Of course,
this needs help from driver authors.

My proposal will be to follow up this series with a two fold migration.
First step to change the existing thermal drivers to have both, the
current support and the device tree support. And second step, for those
who wish to, we could remove the old code containing thermal data and
have only dt support. Of course, this requires drivers authors input.



>> +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);
>> +
>> [...]
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE        0
>> +#define THERMAL_TRIP_PASSIVE        1
>> +#define THERMAL_TRIP_HOT        2
>> +#define THERMAL_TRIP_CRITICAL        3
>> +
> 
> These macros seem duplicated with enum thermal_trip_type in thermal.h,
> do you have further plan to merge them?
> Or by using string "active",  "passive" etc in the dts, then you can
> reuse the original enum definition.

I am changing this so that in DT we have string constants, and we keep a
map from string to enum, just like we have for phy-mode, as suggested by
Mark.

You can have a taste of it here:
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac

I will be reposting this version once we are done with this thread
discussion and I am finished with my current test.

If you have the time, I would appreciate if you could try the series on
your board, as I am don't have access to your hardware. It would be
really nice to see how this work is behaving in other environments then
the one I have.

Thanks for your interest in this work.

> 
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT        (-1UL)
>> +
>> +#endif
>> [...]
> 
> 
> 
> 


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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 25-09-2013 03:13, Hongbo Zhang wrote:
> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>   [...]
>> +
>> +/***   sensor API   ***/
>> +
> 
> You are introducing new concept here, the original framework and drivers
> cannot use this, right? any further plan to update original framework
> for this new feature?
> 

Well, not new as such. Just a specific way to register sensors to
thermal framework. What is really new is the fact that we really need to
have sensors decoupled from thermal zone devices, and today we have
these concepts pretty merged together.

To answer your question, for now I am more concerned with the bindings
definition. Once that is at least agreed, then we can follow up with the
migration of existing drivers. For now, there are two examples in this
series, first one is using one existing thermal driver, which is the TI
SoC thermal driver, and the second one is the hwmon drivers, which are
existing sensor drivers, but are not thermal drivers.

The plan forward, once this series is accepted is to migrate existing
drivers, yes, so that they can use device tree uniformly. Of course,
this needs help from driver authors.

My proposal will be to follow up this series with a two fold migration.
First step to change the existing thermal drivers to have both, the
current support and the device tree support. And second step, for those
who wish to, we could remove the old code containing thermal data and
have only dt support. Of course, this requires drivers authors input.



>> +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);
>> +
>> [...]
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE        0
>> +#define THERMAL_TRIP_PASSIVE        1
>> +#define THERMAL_TRIP_HOT        2
>> +#define THERMAL_TRIP_CRITICAL        3
>> +
> 
> These macros seem duplicated with enum thermal_trip_type in thermal.h,
> do you have further plan to merge them?
> Or by using string "active",  "passive" etc in the dts, then you can
> reuse the original enum definition.

I am changing this so that in DT we have string constants, and we keep a
map from string to enum, just like we have for phy-mode, as suggested by
Mark.

You can have a taste of it here:
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac

I will be reposting this version once we are done with this thread
discussion and I am finished with my current test.

If you have the time, I would appreciate if you could try the series on
your board, as I am don't have access to your hardware. It would be
really nice to see how this work is behaving in other environments then
the one I have.

Thanks for your interest in this work.

> 
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT        (-1UL)
>> +
>> +#endif
>> [...]
> 
> 
> 
> 


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

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 25-09-2013 03:13, Hongbo Zhang wrote:
> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>   [...]
>> +
>> +/***   sensor API   ***/
>> +
> 
> You are introducing new concept here, the original framework and drivers
> cannot use this, right? any further plan to update original framework
> for this new feature?
> 

Well, not new as such. Just a specific way to register sensors to
thermal framework. What is really new is the fact that we really need to
have sensors decoupled from thermal zone devices, and today we have
these concepts pretty merged together.

To answer your question, for now I am more concerned with the bindings
definition. Once that is at least agreed, then we can follow up with the
migration of existing drivers. For now, there are two examples in this
series, first one is using one existing thermal driver, which is the TI
SoC thermal driver, and the second one is the hwmon drivers, which are
existing sensor drivers, but are not thermal drivers.

The plan forward, once this series is accepted is to migrate existing
drivers, yes, so that they can use device tree uniformly. Of course,
this needs help from driver authors.

My proposal will be to follow up this series with a two fold migration.
First step to change the existing thermal drivers to have both, the
current support and the device tree support. And second step, for those
who wish to, we could remove the old code containing thermal data and
have only dt support. Of course, this requires drivers authors input.



>> +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);
>> +
>> [...]
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE        0
>> +#define THERMAL_TRIP_PASSIVE        1
>> +#define THERMAL_TRIP_HOT        2
>> +#define THERMAL_TRIP_CRITICAL        3
>> +
> 
> These macros seem duplicated with enum thermal_trip_type in thermal.h,
> do you have further plan to merge them?
> Or by using string "active",  "passive" etc in the dts, then you can
> reuse the original enum definition.

I am changing this so that in DT we have string constants, and we keep a
map from string to enum, just like we have for phy-mode, as suggested by
Mark.

You can have a taste of it here:
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac

I will be reposting this version once we are done with this thread
discussion and I am finished with my current test.

If you have the time, I would appreciate if you could try the series on
your board, as I am don't have access to your hardware. It would be
really nice to see how this work is behaving in other environments then
the one I have.

Thanks for your interest in this work.

> 
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT        (-1UL)
>> +
>> +#endif
>> [...]
> 
> 
> 
> 


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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/25/2013 10:15 PM, Eduardo Valentin wrote:
> On 25-09-2013 03:13, Hongbo Zhang wrote:
>> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>>    [...]
>>> +
>>> +/***   sensor API   ***/
>>> +
>> You are introducing new concept here, the original framework and drivers
>> cannot use this, right? any further plan to update original framework
>> for this new feature?
>>
> Well, not new as such. Just a specific way to register sensors to
> thermal framework. What is really new is the fact that we really need to
> have sensors decoupled from thermal zone devices, and today we have
> these concepts pretty merged together.
> To answer your question, for now I am more concerned with the bindings
> definition. Once that is at least agreed, then we can follow up with the
> migration of existing drivers. For now, there are two examples in this
> series, first one is using one existing thermal driver, which is the TI
> SoC thermal driver, and the second one is the hwmon drivers, which are
> existing sensor drivers, but are not thermal drivers.
>
> The plan forward, once this series is accepted is to migrate existing
> drivers, yes, so that they can use device tree uniformly. Of course,
> this needs help from driver authors.
>
> My proposal will be to follow up this series with a two fold migration.
> First step to change the existing thermal drivers to have both, the
> current support and the device tree support. And second step, for those
> who wish to, we could remove the old code containing thermal data and
> have only dt support. Of course, this requires drivers authors input.
>
>
>
>>> +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);
>>> +
>>> [...]
>>> +
>>> +/*
>>> + * Here are the thermal trip types. This must
>>> + * match with enum thermal_trip_type at
>>> + * include/linux/thermal.h
>>> + */
>>> +#define THERMAL_TRIP_ACTIVE        0
>>> +#define THERMAL_TRIP_PASSIVE        1
>>> +#define THERMAL_TRIP_HOT        2
>>> +#define THERMAL_TRIP_CRITICAL        3
>>> +
>> These macros seem duplicated with enum thermal_trip_type in thermal.h,
>> do you have further plan to merge them?
>> Or by using string "active",  "passive" etc in the dts, then you can
>> reuse the original enum definition.
> I am changing this so that in DT we have string constants, and we keep a
> map from string to enum, just like we have for phy-mode, as suggested by
> Mark.
>
> You can have a taste of it here:
> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac
>
> I will be reposting this version once we are done with this thread
> discussion and I am finished with my current test.
>
> If you have the time, I would appreciate if you could try the series on
> your board, as I am don't have access to your hardware. It would be
> really nice to see how this work is behaving in other environments then
> the one I have.

We have thermal management plan in next year, currently I don't have 
proper board to test this.
I would like to do it when I have time and board, but I will track these 
thermal treads.
>
> Thanks for your interest in this work.
>
>>> +/* On cooling devices upper and lower limits */
>>> +#define THERMAL_NO_LIMIT        (-1UL)
>>> +
>>> +#endif
>>> [...]
>>
>>
>>
>

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/25/2013 10:15 PM, Eduardo Valentin wrote:
> On 25-09-2013 03:13, Hongbo Zhang wrote:
>> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>>    [...]
>>> +
>>> +/***   sensor API   ***/
>>> +
>> You are introducing new concept here, the original framework and drivers
>> cannot use this, right? any further plan to update original framework
>> for this new feature?
>>
> Well, not new as such. Just a specific way to register sensors to
> thermal framework. What is really new is the fact that we really need to
> have sensors decoupled from thermal zone devices, and today we have
> these concepts pretty merged together.
> To answer your question, for now I am more concerned with the bindings
> definition. Once that is at least agreed, then we can follow up with the
> migration of existing drivers. For now, there are two examples in this
> series, first one is using one existing thermal driver, which is the TI
> SoC thermal driver, and the second one is the hwmon drivers, which are
> existing sensor drivers, but are not thermal drivers.
>
> The plan forward, once this series is accepted is to migrate existing
> drivers, yes, so that they can use device tree uniformly. Of course,
> this needs help from driver authors.
>
> My proposal will be to follow up this series with a two fold migration.
> First step to change the existing thermal drivers to have both, the
> current support and the device tree support. And second step, for those
> who wish to, we could remove the old code containing thermal data and
> have only dt support. Of course, this requires drivers authors input.
>
>
>
>>> +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);
>>> +
>>> [...]
>>> +
>>> +/*
>>> + * Here are the thermal trip types. This must
>>> + * match with enum thermal_trip_type at
>>> + * include/linux/thermal.h
>>> + */
>>> +#define THERMAL_TRIP_ACTIVE        0
>>> +#define THERMAL_TRIP_PASSIVE        1
>>> +#define THERMAL_TRIP_HOT        2
>>> +#define THERMAL_TRIP_CRITICAL        3
>>> +
>> These macros seem duplicated with enum thermal_trip_type in thermal.h,
>> do you have further plan to merge them?
>> Or by using string "active",  "passive" etc in the dts, then you can
>> reuse the original enum definition.
> I am changing this so that in DT we have string constants, and we keep a
> map from string to enum, just like we have for phy-mode, as suggested by
> Mark.
>
> You can have a taste of it here:
> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac
>
> I will be reposting this version once we are done with this thread
> discussion and I am finished with my current test.
>
> If you have the time, I would appreciate if you could try the series on
> your board, as I am don't have access to your hardware. It would be
> really nice to see how this work is behaving in other environments then
> the one I have.

We have thermal management plan in next year, currently I don't have 
proper board to test this.
I would like to do it when I have time and board, but I will track these 
thermal treads.
>
> Thanks for your interest in this work.
>
>>> +/* On cooling devices upper and lower limits */
>>> +#define THERMAL_NO_LIMIT        (-1UL)
>>> +
>>> +#endif
>>> [...]
>>
>>
>>
>

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Hongbo Zhang]

On 09/25/2013 10:15 PM, Eduardo Valentin wrote:
> On 25-09-2013 03:13, Hongbo Zhang wrote:
>> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>>    [...]
>>> +
>>> +/***   sensor API   ***/
>>> +
>> You are introducing new concept here, the original framework and drivers
>> cannot use this, right? any further plan to update original framework
>> for this new feature?
>>
> Well, not new as such. Just a specific way to register sensors to
> thermal framework. What is really new is the fact that we really need to
> have sensors decoupled from thermal zone devices, and today we have
> these concepts pretty merged together.
> To answer your question, for now I am more concerned with the bindings
> definition. Once that is at least agreed, then we can follow up with the
> migration of existing drivers. For now, there are two examples in this
> series, first one is using one existing thermal driver, which is the TI
> SoC thermal driver, and the second one is the hwmon drivers, which are
> existing sensor drivers, but are not thermal drivers.
>
> The plan forward, once this series is accepted is to migrate existing
> drivers, yes, so that they can use device tree uniformly. Of course,
> this needs help from driver authors.
>
> My proposal will be to follow up this series with a two fold migration.
> First step to change the existing thermal drivers to have both, the
> current support and the device tree support. And second step, for those
> who wish to, we could remove the old code containing thermal data and
> have only dt support. Of course, this requires drivers authors input.
>
>
>
>>> +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);
>>> +
>>> [...]
>>> +
>>> +/*
>>> + * Here are the thermal trip types. This must
>>> + * match with enum thermal_trip_type at
>>> + * include/linux/thermal.h
>>> + */
>>> +#define THERMAL_TRIP_ACTIVE        0
>>> +#define THERMAL_TRIP_PASSIVE        1
>>> +#define THERMAL_TRIP_HOT        2
>>> +#define THERMAL_TRIP_CRITICAL        3
>>> +
>> These macros seem duplicated with enum thermal_trip_type in thermal.h,
>> do you have further plan to merge them?
>> Or by using string "active",  "passive" etc in the dts, then you can
>> reuse the original enum definition.
> I am changing this so that in DT we have string constants, and we keep a
> map from string to enum, just like we have for phy-mode, as suggested by
> Mark.
>
> You can have a taste of it here:
> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&idsf16c27fc763495188fba7d6e17b9c986efc6ac
>
> I will be reposting this version once we are done with this thread
> discussion and I am finished with my current test.
>
> If you have the time, I would appreciate if you could try the series on
> your board, as I am don't have access to your hardware. It would be
> really nice to see how this work is behaving in other environments then
> the one I have.

We have thermal management plan in next year, currently I don't have 
proper board to test this.
I would like to do it when I have time and board, but I will track these 
thermal treads.
>
> Thanks for your interest in this work.
>
>>> +/* On cooling devices upper and lower limits */
>>> +#define THERMAL_NO_LIMIT        (-1UL)
>>> +
>>> +#endif
>>> [...]
>>
>>
>>
>




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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 08-10-2013 04:45, Hongbo Zhang wrote:
> On 09/25/2013 10:15 PM, Eduardo Valentin wrote:
>> On 25-09-2013 03:13, Hongbo Zhang wrote:
>>> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>>>    [...]
>>>> +
>>>> +/***   sensor API   ***/
>>>> +
>>> You are introducing new concept here, the original framework and drivers
>>> cannot use this, right? any further plan to update original framework
>>> for this new feature?
>>>
>> Well, not new as such. Just a specific way to register sensors to
>> thermal framework. What is really new is the fact that we really need to
>> have sensors decoupled from thermal zone devices, and today we have
>> these concepts pretty merged together.
>> To answer your question, for now I am more concerned with the bindings
>> definition. Once that is at least agreed, then we can follow up with the
>> migration of existing drivers. For now, there are two examples in this
>> series, first one is using one existing thermal driver, which is the TI
>> SoC thermal driver, and the second one is the hwmon drivers, which are
>> existing sensor drivers, but are not thermal drivers.
>>
>> The plan forward, once this series is accepted is to migrate existing
>> drivers, yes, so that they can use device tree uniformly. Of course,
>> this needs help from driver authors.
>>
>> My proposal will be to follow up this series with a two fold migration.
>> First step to change the existing thermal drivers to have both, the
>> current support and the device tree support. And second step, for those
>> who wish to, we could remove the old code containing thermal data and
>> have only dt support. Of course, this requires drivers authors input.
>>
>>
>>
>>>> +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);
>>>> +
>>>> [...]
>>>> +
>>>> +/*
>>>> + * Here are the thermal trip types. This must
>>>> + * match with enum thermal_trip_type at
>>>> + * include/linux/thermal.h
>>>> + */
>>>> +#define THERMAL_TRIP_ACTIVE        0
>>>> +#define THERMAL_TRIP_PASSIVE        1
>>>> +#define THERMAL_TRIP_HOT        2
>>>> +#define THERMAL_TRIP_CRITICAL        3
>>>> +
>>> These macros seem duplicated with enum thermal_trip_type in thermal.h,
>>> do you have further plan to merge them?
>>> Or by using string "active",  "passive" etc in the dts, then you can
>>> reuse the original enum definition.
>> I am changing this so that in DT we have string constants, and we keep a
>> map from string to enum, just like we have for phy-mode, as suggested by
>> Mark.
>>
>> You can have a taste of it here:
>> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac
>>
>>
>> I will be reposting this version once we are done with this thread
>> discussion and I am finished with my current test.
>>
>> If you have the time, I would appreciate if you could try the series on
>> your board, as I am don't have access to your hardware. It would be
>> really nice to see how this work is behaving in other environments then
>> the one I have.
> 
> We have thermal management plan in next year, currently I don't have
> proper board to test this.
> I would like to do it when I have time and board, but I will track these
> thermal treads.

OK Zhang, no worries then.

>>
>> Thanks for your interest in this work.
>>
>>>> +/* On cooling devices upper and lower limits */
>>>> +#define THERMAL_NO_LIMIT        (-1UL)
>>>> +
>>>> +#endif
>>>> [...]
>>>
>>>
>>>
>>
> 
> 
> 
> 
> 


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

Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 08-10-2013 04:45, Hongbo Zhang wrote:
> On 09/25/2013 10:15 PM, Eduardo Valentin wrote:
>> On 25-09-2013 03:13, Hongbo Zhang wrote:
>>> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>>>    [...]
>>>> +
>>>> +/***   sensor API   ***/
>>>> +
>>> You are introducing new concept here, the original framework and drivers
>>> cannot use this, right? any further plan to update original framework
>>> for this new feature?
>>>
>> Well, not new as such. Just a specific way to register sensors to
>> thermal framework. What is really new is the fact that we really need to
>> have sensors decoupled from thermal zone devices, and today we have
>> these concepts pretty merged together.
>> To answer your question, for now I am more concerned with the bindings
>> definition. Once that is at least agreed, then we can follow up with the
>> migration of existing drivers. For now, there are two examples in this
>> series, first one is using one existing thermal driver, which is the TI
>> SoC thermal driver, and the second one is the hwmon drivers, which are
>> existing sensor drivers, but are not thermal drivers.
>>
>> The plan forward, once this series is accepted is to migrate existing
>> drivers, yes, so that they can use device tree uniformly. Of course,
>> this needs help from driver authors.
>>
>> My proposal will be to follow up this series with a two fold migration.
>> First step to change the existing thermal drivers to have both, the
>> current support and the device tree support. And second step, for those
>> who wish to, we could remove the old code containing thermal data and
>> have only dt support. Of course, this requires drivers authors input.
>>
>>
>>
>>>> +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);
>>>> +
>>>> [...]
>>>> +
>>>> +/*
>>>> + * Here are the thermal trip types. This must
>>>> + * match with enum thermal_trip_type at
>>>> + * include/linux/thermal.h
>>>> + */
>>>> +#define THERMAL_TRIP_ACTIVE        0
>>>> +#define THERMAL_TRIP_PASSIVE        1
>>>> +#define THERMAL_TRIP_HOT        2
>>>> +#define THERMAL_TRIP_CRITICAL        3
>>>> +
>>> These macros seem duplicated with enum thermal_trip_type in thermal.h,
>>> do you have further plan to merge them?
>>> Or by using string "active",  "passive" etc in the dts, then you can
>>> reuse the original enum definition.
>> I am changing this so that in DT we have string constants, and we keep a
>> map from string to enum, just like we have for phy-mode, as suggested by
>> Mark.
>>
>> You can have a taste of it here:
>> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac
>>
>>
>> I will be reposting this version once we are done with this thread
>> discussion and I am finished with my current test.
>>
>> If you have the time, I would appreciate if you could try the series on
>> your board, as I am don't have access to your hardware. It would be
>> really nice to see how this work is behaving in other environments then
>> the one I have.
> 
> We have thermal management plan in next year, currently I don't have
> proper board to test this.
> I would like to do it when I have time and board, but I will track these
> thermal treads.

OK Zhang, no worries then.

>>
>> Thanks for your interest in this work.
>>
>>>> +/* On cooling devices upper and lower limits */
>>>> +#define THERMAL_NO_LIMIT        (-1UL)
>>>> +
>>>> +#endif
>>>> [...]
>>>
>>>
>>>
>>
> 
> 
> 
> 
> 


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

Re: [lm-sensors] [PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

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

On 08-10-2013 04:45, Hongbo Zhang wrote:
> On 09/25/2013 10:15 PM, Eduardo Valentin wrote:
>> On 25-09-2013 03:13, Hongbo Zhang wrote:
>>> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>>>    [...]
>>>> +
>>>> +/***   sensor API   ***/
>>>> +
>>> You are introducing new concept here, the original framework and drivers
>>> cannot use this, right? any further plan to update original framework
>>> for this new feature?
>>>
>> Well, not new as such. Just a specific way to register sensors to
>> thermal framework. What is really new is the fact that we really need to
>> have sensors decoupled from thermal zone devices, and today we have
>> these concepts pretty merged together.
>> To answer your question, for now I am more concerned with the bindings
>> definition. Once that is at least agreed, then we can follow up with the
>> migration of existing drivers. For now, there are two examples in this
>> series, first one is using one existing thermal driver, which is the TI
>> SoC thermal driver, and the second one is the hwmon drivers, which are
>> existing sensor drivers, but are not thermal drivers.
>>
>> The plan forward, once this series is accepted is to migrate existing
>> drivers, yes, so that they can use device tree uniformly. Of course,
>> this needs help from driver authors.
>>
>> My proposal will be to follow up this series with a two fold migration.
>> First step to change the existing thermal drivers to have both, the
>> current support and the device tree support. And second step, for those
>> who wish to, we could remove the old code containing thermal data and
>> have only dt support. Of course, this requires drivers authors input.
>>
>>
>>
>>>> +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);
>>>> +
>>>> [...]
>>>> +
>>>> +/*
>>>> + * Here are the thermal trip types. This must
>>>> + * match with enum thermal_trip_type at
>>>> + * include/linux/thermal.h
>>>> + */
>>>> +#define THERMAL_TRIP_ACTIVE        0
>>>> +#define THERMAL_TRIP_PASSIVE        1
>>>> +#define THERMAL_TRIP_HOT        2
>>>> +#define THERMAL_TRIP_CRITICAL        3
>>>> +
>>> These macros seem duplicated with enum thermal_trip_type in thermal.h,
>>> do you have further plan to merge them?
>>> Or by using string "active",  "passive" etc in the dts, then you can
>>> reuse the original enum definition.
>> I am changing this so that in DT we have string constants, and we keep a
>> map from string to enum, just like we have for phy-mode, as suggested by
>> Mark.
>>
>> You can have a taste of it here:
>> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac
>>
>>
>> I will be reposting this version once we are done with this thread
>> discussion and I am finished with my current test.
>>
>> If you have the time, I would appreciate if you could try the series on
>> your board, as I am don't have access to your hardware. It would be
>> really nice to see how this work is behaving in other environments then
>> the one I have.
> 
> We have thermal management plan in next year, currently I don't have
> proper board to test this.
> I would like to do it when I have time and board, but I will track these
> thermal treads.

OK Zhang, no worries then.

>>
>> Thanks for your interest in this work.
>>
>>>> +/* On cooling devices upper and lower limits */
>>>> +#define THERMAL_NO_LIMIT        (-1UL)
>>>> +
>>>> +#endif
>>>> [...]
>>>
>>>
>>>
>>
> 
> 
> 
> 
> 


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

[PATCH 07/16] thermal: ti-soc-thermal: use thermal DT infrastructure

[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-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/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..1d373ec 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, "#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

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

[PATCH 07/16] thermal: ti-soc-thermal: use thermal DT infrastructure

[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..1d373ec 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, "#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] [PATCH 07/16] thermal: ti-soc-thermal: use thermal DT infrastructure

[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..1d373ec 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, "#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

[PATCH 08/16] arm: dts: add omap4 CPU thermal data

[Eduardo Valentin]

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..dd69788
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		attach0 {
+			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

[PATCH 08/16] arm: dts: add omap4 CPU thermal data

[Eduardo Valentin]

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..dd69788
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		attach0 {
+			trip = <&cpu_alert0>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

[PATCH 08/16] arm: dts: add omap4 CPU thermal data

[Eduardo Valentin]

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..dd69788
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+        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-attachments {
+		attach0 {
+			trip = <&cpu_alert0>;
+			cooling-device =
+				<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

[lm-sensors] [PATCH 08/16] arm: dts: add omap4 CPU thermal data

[Eduardo Valentin]

VGhpcyBwYXRjaCBjaGFuZ2VzIGEgZHRzaSBmaWxlIHRvIGNvbnRhaW4gdGhlIHRoZXJtYWwgZGF0
YQpmb3IgTVBVIGRvbWFpbiBvbiBPTUFQNCBhbmQgbGF0ZXIgU29Dcy4gVGhpcyBkYXRhIHdpbGwK
ZW5hYmxlIHRoZSBwYXNzaXZlIGNvb2xpbmcgd2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlCmF0
IDEwMEMgYW5kIHRoZSBzeXN0ZW0gd2lsbCBkbyBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4K
ClRoaXMgdGhlcm1hbCBkYXRhIGNhbiBiZSByZXVzZWQgYWNyb3NzIFRJIFNvQyBkZXZpY2VzLgoK
Q2M6ICJCZW5vw650IENvdXNzb24iIDxiY291c3NvbkBiYXlsaWJyZS5jb20+CkNjOiBUb255IExp
bmRncmVuIDx0b255QGF0b21pZGUuY29tPgpDYzogUm9iIEhlcnJpbmcgPHJvYi5oZXJyaW5nQGNh
bHhlZGEuY29tPgpDYzogUGF3ZWwgTW9sbCA8cGF3ZWwubW9sbEBhcm0uY29tPgpDYzogTWFyayBS
dXRsYW5kIDxtYXJrLnJ1dGxhbmRAYXJtLmNvbT4KQ2M6IFN0ZXBoZW4gV2FycmVuIDxzd2FycmVu
QHd3d2RvdG9yZy5vcmc+CkNjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29t
PgpDYzogUnVzc2VsbCBLaW5nIDxsaW51eEBhcm0ubGludXgub3JnLnVrPgpDYzogbGludXgtb21h
cEB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnCkNjOiBsaW51
eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtl
cm5lbC5vcmcKU2lnbmVkLW9mZi1ieTogRWR1YXJkbyBWYWxlbnRpbiA8ZWR1YXJkby52YWxlbnRp
bkB0aS5jb20+Ci0tLQogYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQtY3B1LXRoZXJtYWwuZHRzaSB8
IDQxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgNDEg
aW5zZXJ0aW9ucygrKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGFyY2gvYXJtL2Jvb3QvZHRzL29tYXA0
LWNwdS10aGVybWFsLmR0c2kKCmRpZmYgLS1naXQgYS9hcmNoL2FybS9ib290L2R0cy9vbWFwNC1j
cHUtdGhlcm1hbC5kdHNpIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQtY3B1LXRoZXJtYWwuZHRz
aQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5kZDY5Nzg4Ci0tLSAvZGV2L251
bGwKKysrIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQtY3B1LXRoZXJtYWwuZHRzaQpAQCAtMCww
ICsxLDQxIEBACisvKgorICogRGV2aWNlIFRyZWUgU291cmNlIGZvciBPTUFQNC81IFNvQyBDUFUg
dGhlcm1hbAorICoKKyAqIENvcHlyaWdodCAoQykgMjAxMyBUZXhhcyBJbnN0cnVtZW50cyBJbmNv
cnBvcmF0ZWQgLSBodHRwOi8vd3d3LnRpLmNvbS8KKyAqIENvbnRhY3Q6IEVkdWFyZG8gVmFsZW50
aW4gPGVkdWFyZG8udmFsZW50aW5AdGkuY29tPgorICoKKyAqIFRoaXMgZmlsZSBpcyBsaWNlbnNl
ZCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiB2
ZXJzaW9uIDIuICBUaGlzIHByb2dyYW0gaXMgbGljZW5zZWQgImFzIGlzIiB3aXRob3V0IGFueSB3
YXJyYW50eSBvZiBhbnkKKyAqIGtpbmQsIHdoZXRoZXIgZXhwcmVzcyBvciBpbXBsaWVkLgorICov
CisKKyNpbmNsdWRlIDxkdC1iaW5kaW5ncy90aGVybWFsL3RoZXJtYWwuaD4KKworY3B1X3RoZXJt
YWw6IGNwdV90aGVybWFsIHsKKwlwYXNzaXZlLWRlbGF5ID0gPDI1MD47IC8qIG1pbGxpc2Vjb25k
cyAqLworCXBvbGxpbmctZGVsYXkgPSA8MTAwMD47IC8qIG1pbGxpc2Vjb25kcyAqLworCisJCS8q
IHNlbnNvciAgICAgICBJRCAqLworICAgICAgICBzZW5zb3JzID0gPCZiYW5kZ2FwICAgICAwPjsK
KworICAgICAgICB0cmlwcyB7CisgICAgICAgICAgICAgICAgY3B1X2FsZXJ0MDogY3B1X2FsZXJ0
IHsKKyAgICAgICAgICAgICAgICAgICAgICAgIHRlbXBlcmF0dXJlID0gPDEwMDAwMD47IC8qIG1p
bGxpQ2Vsc2l1cyAqLworICAgICAgICAgICAgICAgICAgICAgICAgaHlzdGVyZXNpcyA9IDwyMDAw
PjsgLyogbWlsbGlDZWxzaXVzICovCisgICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gPFRI
RVJNQUxfVFJJUF9QQVNTSVZFPjsKKyAgICAgICAgICAgICAgICB9OworICAgICAgICAgICAgICAg
IGNwdV9jcml0OiBjcHVfY3JpdCB7CisgICAgICAgICAgICAgICAgICAgICAgICB0ZW1wZXJhdHVy
ZSA9IDwxMjUwMDA+OyAvKiBtaWxsaUNlbHNpdXMgKi8KKyAgICAgICAgICAgICAgICAgICAgICAg
IGh5c3RlcmVzaXMgPSA8MjAwMD47IC8qIG1pbGxpQ2Vsc2l1cyAqLworICAgICAgICAgICAgICAg
ICAgICAgICAgdHlwZSA9IDxUSEVSTUFMX1RSSVBfQ1JJVElDQUw+OworICAgICAgICAgICAgICAg
IH07CisgICAgICAgIH07CisKKwljb29saW5nLWF0dGFjaG1lbnRzIHsKKwkJYXR0YWNoMCB7CisJ
CQl0cmlwID0gPCZjcHVfYWxlcnQwPjsKKwkJCWNvb2xpbmctZGV2aWNlID0KKwkJCQk8JmNwdTAg
VEhFUk1BTF9OT19MSU1JVCBUSEVSTUFMX05PX0xJTUlUPjsKKwkJfTsKKwl9OworfTsKLS0gCjEu
OC4yLjEuMzQyLmdmYTcyODVkCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3Jz
Lm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5z
b3Jz

[PATCH 09/16] arm: dts: add omap4430 thermal data

[Eduardo Valentin]

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..6987df9 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";
+
+		#sensor-cells = <1>;
 	};
 };
-- 
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

[PATCH 09/16] arm: dts: add omap4430 thermal data

[Eduardo Valentin]

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..6987df9 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";
+
+		#sensor-cells = <1>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[PATCH 09/16] arm: dts: add omap4430 thermal data

[Eduardo Valentin]

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..6987df9 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";
+
+		#sensor-cells = <1>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[lm-sensors] [PATCH 09/16] arm: dts: add omap4430 thermal data

[Eduardo Valentin]

VGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBkdHNpIGVudHJ5IG9uIG9tYXA0NDMwIHRvIGNvbnRhaW4K
dGhlIHRoZXJtYWwgZGF0YS4gVGhpcyBkYXRhIHdpbGwgZW5hYmxlIHRoZSBwYXNzaXZlCmNvb2xp
bmcgd2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlIGF0IDEwMEMgYW5kIHRoZQpzeXN0ZW0gd2ls
bCBkbyBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4KCkNjOiAiQmVub8OudCBDb3Vzc29uIiA8
YmNvdXNzb25AYmF5bGlicmUuY29tPgpDYzogVG9ueSBMaW5kZ3JlbiA8dG9ueUBhdG9taWRlLmNv
bT4KQ2M6IFJ1c3NlbGwgS2luZyA8bGludXhAYXJtLmxpbnV4Lm9yZy51az4KQ2M6IGxpbnV4LW9t
YXBAdmdlci5rZXJuZWwub3JnCkNjOiBkZXZpY2V0cmVlLWRpc2N1c3NAbGlzdHMub3psYWJzLm9y
ZwpDYzogbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCkNjOiBsaW51eC1rZXJu
ZWxAdmdlci5rZXJuZWwub3JnClNpZ25lZC1vZmYtYnk6IEVkdWFyZG8gVmFsZW50aW4gPGVkdWFy
ZG8udmFsZW50aW5AdGkuY29tPgotLS0KIGFyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kg
fCAxMCArKysrKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspLCAyIGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kgYi9h
cmNoL2FybS9ib290L2R0cy9vbWFwNDQzeC5kdHNpCmluZGV4IGJjZjQ1NWUuLjY5ODdkZjkgMTAw
NjQ0Ci0tLSBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0NDN4LmR0c2kKKysrIGIvYXJjaC9hcm0v
Ym9vdC9kdHMvb21hcDQ0M3guZHRzaQpAQCAtMTIsNyArMTIsNyBAQAogCiAvIHsKIAljcHVzIHsK
LQkJY3B1QDAgeworCQljcHUwOiBjcHVAMCB7CiAJCQkvKiBPTUFQNDQzeCB2YXJpYW50cyBPUFA1
MC1PUFBOVCAqLwogCQkJb3BlcmF0aW5nLXBvaW50cyA9IDwKIAkJCQkvKiBrSHogICAgdVYgKi8K
QEAgLTI1LDkgKzI1LDE1IEBACiAJCX07CiAJfTsKIAotCWJhbmRnYXAgeworCXRoZXJtYWwtem9u
ZXN7CisJCSNpbmNsdWRlICJvbWFwNC1jcHUtdGhlcm1hbC5kdHNpIgorCX07CisKKwliYW5kZ2Fw
OiBiYW5kZ2FwIHsKIAkJcmVnID0gPDB4NGEwMDIyNjAgMHg0CiAJCSAgICAgICAweDRhMDAyMzJD
IDB4ND47CiAJCWNvbXBhdGlibGUgPSAidGksb21hcDQ0MzAtYmFuZGdhcCI7CisKKwkJI3NlbnNv
ci1jZWxscyA9IDwxPjsKIAl9OwogfTsKLS0gCjEuOC4yLjEuMzQyLmdmYTcyODVkCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWls
aW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29y
cy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

[PATCH 10/16] arm: dts: add omap4460 thermal data

[Eduardo Valentin]

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..b6b9b83 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 */
+
+		#sensor-cells = <1>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[PATCH 10/16] arm: dts: add omap4460 thermal data

[Eduardo Valentin]

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..b6b9b83 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 */
+
+		#sensor-cells = <1>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[PATCH 10/16] arm: dts: add omap4460 thermal data

[Eduardo Valentin]

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..b6b9b83 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 */
+
+		#sensor-cells = <1>;
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[lm-sensors] [PATCH 10/16] arm: dts: add omap4460 thermal data

[Eduardo Valentin]

VGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBkdHNpIGVudHJ5IG9uIG9tYXA0NDYwIHRvIGNvbnRhaW4K
dGhlIHRoZXJtYWwgZGF0YS4gVGhpcyBkYXRhIHdpbGwgZW5hYmxlIHRoZSBwYXNzaXZlCmNvb2xp
bmcgd2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlIGF0IDEwMEMgYW5kIHRoZQpzeXN0ZW0gd2ls
bCBkbyBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4KCkNjOiAiQmVub8OudCBDb3Vzc29uIiA8
YmNvdXNzb25AYmF5bGlicmUuY29tPgpDYzogVG9ueSBMaW5kZ3JlbiA8dG9ueUBhdG9taWRlLmNv
bT4KQ2M6IFJvYiBIZXJyaW5nIDxyb2IuaGVycmluZ0BjYWx4ZWRhLmNvbT4KQ2M6IFBhd2VsIE1v
bGwgPHBhd2VsLm1vbGxAYXJtLmNvbT4KQ2M6IE1hcmsgUnV0bGFuZCA8bWFyay5ydXRsYW5kQGFy
bS5jb20+CkNjOiBTdGVwaGVuIFdhcnJlbiA8c3dhcnJlbkB3d3dkb3Rvcmcub3JnPgpDYzogSWFu
IENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQ2M6IFJ1c3NlbGwgS2luZyA8bGlu
dXhAYXJtLmxpbnV4Lm9yZy51az4KQ2M6IGxpbnV4LW9tYXBAdmdlci5rZXJuZWwub3JnCkNjOiBk
ZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZwpDYzogbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZy
YWRlYWQub3JnCkNjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnClNpZ25lZC1vZmYtYnk6
IEVkdWFyZG8gVmFsZW50aW4gPGVkdWFyZG8udmFsZW50aW5AdGkuY29tPgotLS0KIGFyY2gvYXJt
L2Jvb3QvZHRzL29tYXA0NDYwLmR0c2kgfCAxMCArKysrKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwg
OCBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gvYXJtL2Jv
b3QvZHRzL29tYXA0NDYwLmR0c2kgYi9hcmNoL2FybS9ib290L2R0cy9vbWFwNDQ2MC5kdHNpCmlu
ZGV4IGMyZjBmMzkuLmI2YjliODMgMTAwNjQ0Ci0tLSBhL2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA0
NDYwLmR0c2kKKysrIGIvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDQ0NjAuZHRzaQpAQCAtMTIsNyAr
MTIsNyBAQAogLyB7CiAJY3B1cyB7CiAJCS8qIE9NQVA0NDZ4ICdzdGFuZGFyZCBkZXZpY2UnIHZh
cmlhbnRzIE9QUDUwIHRvIE9QUFR1cmJvICovCi0JCWNwdUAwIHsKKwkJY3B1MDogY3B1QDAgewog
CQkJb3BlcmF0aW5nLXBvaW50cyA9IDwKIAkJCQkvKiBrSHogICAgdVYgKi8KIAkJCQkzNTAwMDAg
IDEwMjUwMDAKQEAgLTMwLDEyICszMCwxOCBAQAogCQl0aSxod21vZHMgPSAiZGVidWdzcyI7CiAJ
fTsKIAotCWJhbmRnYXAgeworCXRoZXJtYWwtem9uZXN7CisJCSNpbmNsdWRlICJvbWFwNC1jcHUt
dGhlcm1hbC5kdHNpIgorCX07CisKKwliYW5kZ2FwOiBiYW5kZ2FwIHsKIAkJcmVnID0gPDB4NGEw
MDIyNjAgMHg0CiAJCSAgICAgICAweDRhMDAyMzJDIDB4NAogCQkgICAgICAgMHg0YTAwMjM3OCAw
eDE4PjsKIAkJY29tcGF0aWJsZSA9ICJ0aSxvbWFwNDQ2MC1iYW5kZ2FwIjsKIAkJaW50ZXJydXB0
cyA9IDwwIDEyNiBJUlFfVFlQRV9MRVZFTF9ISUdIPjsgLyogdGFsZXJ0ICovCiAJCWdwaW9zID0g
PCZncGlvMyAyMiAwPjsgLyogdHNodXQgKi8KKworCQkjc2Vuc29yLWNlbGxzID0gPDE+OwogCX07
CiB9OwotLSAKMS44LjIuMS4zNDIuZ2ZhNzI4NWQKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3Jz
QGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2xtLXNlbnNvcnM

[PATCH 11/16] arm: dts: add cooling properties on omap4430 cpu node

[Eduardo Valentin]

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 6987df9..5737e49 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

[PATCH 11/16] arm: dts: add cooling properties on omap4430 cpu node

[Eduardo Valentin]

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 6987df9..5737e49 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

[PATCH 11/16] arm: dts: add cooling properties on omap4430 cpu node

[Eduardo Valentin]

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 6987df9..5737e49 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

[lm-sensors] [PATCH 11/16] arm: dts: add cooling properties on omap4430 cpu node

[Eduardo Valentin]

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

[PATCH 12/16] arm: dts: add cooling properties on omap4460 cpu node

[Eduardo Valentin]

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 b6b9b83..0806f03 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

[PATCH 12/16] arm: dts: add cooling properties on omap4460 cpu node

[Eduardo Valentin]

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 b6b9b83..0806f03 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

[PATCH 12/16] arm: dts: add cooling properties on omap4460 cpu node

[Eduardo Valentin]

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 b6b9b83..0806f03 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

[lm-sensors] [PATCH 12/16] arm: dts: add cooling properties on omap4460 cpu node

[Eduardo Valentin]

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

[PATCH 13/16] arm: dts: add omap5 GPU thermal data

[Eduardo Valentin]

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..08a1290
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&bandgap     1>;
+
+	trips {
+		gpu_crit: gpu_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = <THERMAL_TRIP_CRITICAL>;
+		};
+	};
+};
-- 
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

[PATCH 13/16] arm: dts: add omap5 GPU thermal data

[Eduardo Valentin]

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..08a1290
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&bandgap     1>;
+
+	trips {
+		gpu_crit: gpu_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = <THERMAL_TRIP_CRITICAL>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

[PATCH 13/16] arm: dts: add omap5 GPU thermal data

[Eduardo Valentin]

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..08a1290
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&bandgap     1>;
+
+	trips {
+		gpu_crit: gpu_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = <THERMAL_TRIP_CRITICAL>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

[lm-sensors] [PATCH 13/16] arm: dts: add omap5 GPU thermal data

[Eduardo Valentin]

VGhpcyBwYXRjaCBjaGFuZ2VzIGEgZHRzaSBmaWxlIHRvIGNvbnRhaW4gdGhlIHRoZXJtYWwgZGF0
YQpmb3IgR1BVIGRvbWFpbiBvbiBPTUFQNSBhbmQgbGF0ZXIgU29Dcy4gVGhpcyBkYXRhIHdpbGwK
ZW5hYmxlIGEgdGhlcm1hbCBzaHV0ZG93biBhdCAxMjVDLgoKVGhpcyB0aGVybWFsIGRhdGEgY2Fu
IGJlIHJldXNlZCBhY3Jvc3MgVEkgU29DIGRldmljZXMuCgpDYzogIkJlbm/DrnQgQ291c3NvbiIg
PGJjb3Vzc29uQGJheWxpYnJlLmNvbT4KQ2M6IFRvbnkgTGluZGdyZW4gPHRvbnlAYXRvbWlkZS5j
b20+CkNjOiBSb2IgSGVycmluZyA8cm9iLmhlcnJpbmdAY2FseGVkYS5jb20+CkNjOiBQYXdlbCBN
b2xsIDxwYXdlbC5tb2xsQGFybS5jb20+CkNjOiBNYXJrIFJ1dGxhbmQgPG1hcmsucnV0bGFuZEBh
cm0uY29tPgpDYzogU3RlcGhlbiBXYXJyZW4gPHN3YXJyZW5Ad3d3ZG90b3JnLm9yZz4KQ2M6IElh
biBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkNjOiBSdXNzZWxsIEtpbmcgPGxp
bnV4QGFybS5saW51eC5vcmcudWs+CkNjOiBsaW51eC1vbWFwQHZnZXIua2VybmVsLm9yZwpDYzog
ZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5m
cmFkZWFkLm9yZwpDYzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZwpTaWduZWQtb2ZmLWJ5
OiBFZHVhcmRvIFZhbGVudGluIDxlZHVhcmRvLnZhbGVudGluQHRpLmNvbT4KLS0tCiBhcmNoL2Fy
bS9ib290L2R0cy9vbWFwNS1ncHUtdGhlcm1hbC5kdHNpIHwgMjggKysrKysrKysrKysrKysrKysr
KysrKysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDI4IGluc2VydGlvbnMoKykKIGNyZWF0ZSBtb2Rl
IDEwMDY0NCBhcmNoL2FybS9ib290L2R0cy9vbWFwNS1ncHUtdGhlcm1hbC5kdHNpCgpkaWZmIC0t
Z2l0IGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUtZ3B1LXRoZXJtYWwuZHRzaSBiL2FyY2gvYXJt
L2Jvb3QvZHRzL29tYXA1LWdwdS10aGVybWFsLmR0c2kKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5k
ZXggMDAwMDAwMC4uMDhhMTI5MAotLS0gL2Rldi9udWxsCisrKyBiL2FyY2gvYXJtL2Jvb3QvZHRz
L29tYXA1LWdwdS10aGVybWFsLmR0c2kKQEAgLTAsMCArMSwyOCBAQAorLyoKKyAqIERldmljZSBU
cmVlIFNvdXJjZSBmb3IgT01BUDU0M3ggU29DIEdQVSB0aGVybWFsCisgKgorICogQ29weXJpZ2h0
IChDKSAyMDEzIFRleGFzIEluc3RydW1lbnRzIEluY29ycG9yYXRlZCAtIGh0dHA6Ly93d3cudGku
Y29tLworICogQ29udGFjdDogRWR1YXJkbyBWYWxlbnRpbiA8ZWR1YXJkby52YWxlbnRpbkB0aS5j
b20+CisgKgorICogVGhpcyBmaWxlIGlzIGxpY2Vuc2VkIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUg
R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIHZlcnNpb24gMi4gIFRoaXMgcHJvZ3JhbSBp
cyBsaWNlbnNlZCAiYXMgaXMiIHdpdGhvdXQgYW55IHdhcnJhbnR5IG9mIGFueQorICoga2luZCwg
d2hldGhlciBleHByZXNzIG9yIGltcGxpZWQuCisgKi8KKworI2luY2x1ZGUgPGR0LWJpbmRpbmdz
L3RoZXJtYWwvdGhlcm1hbC5oPgorCitncHVfdGhlcm1hbDogZ3B1X3RoZXJtYWwgeworCXBhc3Np
dmUtZGVsYXkgPSA8MjUwPjsgLyogbWlsbGlzZWNvbmRzICovCisJcG9sbGluZy1kZWxheSA9IDwx
MDAwPjsgLyogbWlsbGlzZWNvbmRzICovCisKKwkJLyogc2Vuc29yICAgICAgIElEICovCisJc2Vu
c29ycyA9IDwmYmFuZGdhcCAgICAgMT47CisKKwl0cmlwcyB7CisJCWdwdV9jcml0OiBncHVfY3Jp
dCB7CisJCQl0ZW1wZXJhdHVyZSA9IDwxMjUwMDA+OyAvKiBtaWxsaUNlbHNpdXMgKi8KKwkJCWh5
c3RlcmVzaXMgPSA8MjAwMD47IC8qIG1pbGxpQ2Vsc2l1cyAqLworCQkJdHlwZSA9IDxUSEVSTUFM
X1RSSVBfQ1JJVElDQUw+OworCQl9OworCX07Cit9OwotLSAKMS44LjIuMS4zNDIuZ2ZhNzI4NWQK
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5z
b3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5s
bS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

[PATCH 14/16] arm: dts: add omap5 CORE thermal data

[Eduardo Valentin]

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..1fdd32e
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&bandgap     2>;
+
+	trips {
+		core_crit: core_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = <THERMAL_TRIP_CRITICAL>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

[PATCH 14/16] arm: dts: add omap5 CORE thermal data

[Eduardo Valentin]

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..1fdd32e
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&bandgap     2>;
+
+	trips {
+		core_crit: core_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = <THERMAL_TRIP_CRITICAL>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

[PATCH 14/16] arm: dts: add omap5 CORE thermal data

[Eduardo Valentin]

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..1fdd32e
--- /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 {
+	passive-delay = <250>; /* milliseconds */
+	polling-delay = <1000>; /* milliseconds */
+
+		/* sensor       ID */
+	sensors = <&bandgap     2>;
+
+	trips {
+		core_crit: core_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = <THERMAL_TRIP_CRITICAL>;
+		};
+	};
+};
-- 
1.8.2.1.342.gfa7285d

[lm-sensors] [PATCH 14/16] arm: dts: add omap5 CORE thermal data

[Eduardo Valentin]

VGhpcyBwYXRjaCBjaGFuZ2VzIGEgZHRzaSBmaWxlIHRvIGNvbnRhaW4gdGhlIHRoZXJtYWwgZGF0
YQpmb3IgQ09SRSBkb21haW4gb24gT01BUDUgYW5kIGxhdGVyIFNvQ3MuIFRoaXMgZGF0YSB3aWxs
CmVuYWJsZSBhIHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1Qy4KClRoaXMgdGhlcm1hbCBkYXRhIGNh
biBiZSByZXVzZWQgYWNyb3NzIFRJIFNvQyBkZXZpY2VzLgoKQ2M6ICJCZW5vw650IENvdXNzb24i
IDxiY291c3NvbkBiYXlsaWJyZS5jb20+CkNjOiBUb255IExpbmRncmVuIDx0b255QGF0b21pZGUu
Y29tPgpDYzogUm9iIEhlcnJpbmcgPHJvYi5oZXJyaW5nQGNhbHhlZGEuY29tPgpDYzogUGF3ZWwg
TW9sbCA8cGF3ZWwubW9sbEBhcm0uY29tPgpDYzogTWFyayBSdXRsYW5kIDxtYXJrLnJ1dGxhbmRA
YXJtLmNvbT4KQ2M6IFN0ZXBoZW4gV2FycmVuIDxzd2FycmVuQHd3d2RvdG9yZy5vcmc+CkNjOiBJ
YW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpDYzogUnVzc2VsbCBLaW5nIDxs
aW51eEBhcm0ubGludXgub3JnLnVrPgpDYzogbGludXgtb21hcEB2Z2VyLmtlcm5lbC5vcmcKQ2M6
IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnCkNjOiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmlu
ZnJhZGVhZC5vcmcKQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcKU2lnbmVkLW9mZi1i
eTogRWR1YXJkbyBWYWxlbnRpbiA8ZWR1YXJkby52YWxlbnRpbkB0aS5jb20+Ci0tLQogYXJjaC9h
cm0vYm9vdC9kdHMvb21hcDUtY29yZS10aGVybWFsLmR0c2kgfCAyOCArKysrKysrKysrKysrKysr
KysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMjggaW5zZXJ0aW9ucygrKQogY3JlYXRlIG1v
ZGUgMTAwNjQ0IGFyY2gvYXJtL2Jvb3QvZHRzL29tYXA1LWNvcmUtdGhlcm1hbC5kdHNpCgpkaWZm
IC0tZ2l0IGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUtY29yZS10aGVybWFsLmR0c2kgYi9hcmNo
L2FybS9ib290L2R0cy9vbWFwNS1jb3JlLXRoZXJtYWwuZHRzaQpuZXcgZmlsZSBtb2RlIDEwMDY0
NAppbmRleCAwMDAwMDAwLi4xZmRkMzJlCi0tLSAvZGV2L251bGwKKysrIGIvYXJjaC9hcm0vYm9v
dC9kdHMvb21hcDUtY29yZS10aGVybWFsLmR0c2kKQEAgLTAsMCArMSwyOCBAQAorLyoKKyAqIERl
dmljZSBUcmVlIFNvdXJjZSBmb3IgT01BUDU0M3ggU29DIENPUkUgdGhlcm1hbAorICoKKyAqIENv
cHlyaWdodCAoQykgMjAxMyBUZXhhcyBJbnN0cnVtZW50cyBJbmNvcnBvcmF0ZWQgLSBodHRwOi8v
d3d3LnRpLmNvbS8KKyAqIENvbnRhY3Q6IEVkdWFyZG8gVmFsZW50aW4gPGVkdWFyZG8udmFsZW50
aW5AdGkuY29tPgorICoKKyAqIFRoaXMgZmlsZSBpcyBsaWNlbnNlZCB1bmRlciB0aGUgdGVybXMg
b2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiB2ZXJzaW9uIDIuICBUaGlzIHBy
b2dyYW0gaXMgbGljZW5zZWQgImFzIGlzIiB3aXRob3V0IGFueSB3YXJyYW50eSBvZiBhbnkKKyAq
IGtpbmQsIHdoZXRoZXIgZXhwcmVzcyBvciBpbXBsaWVkLgorICovCisKKyNpbmNsdWRlIDxkdC1i
aW5kaW5ncy90aGVybWFsL3RoZXJtYWwuaD4KKworY29yZV90aGVybWFsOiBjb3JlX3RoZXJtYWwg
eworCXBhc3NpdmUtZGVsYXkgPSA8MjUwPjsgLyogbWlsbGlzZWNvbmRzICovCisJcG9sbGluZy1k
ZWxheSA9IDwxMDAwPjsgLyogbWlsbGlzZWNvbmRzICovCisKKwkJLyogc2Vuc29yICAgICAgIElE
ICovCisJc2Vuc29ycyA9IDwmYmFuZGdhcCAgICAgMj47CisKKwl0cmlwcyB7CisJCWNvcmVfY3Jp
dDogY29yZV9jcml0IHsKKwkJCXRlbXBlcmF0dXJlID0gPDEyNTAwMD47IC8qIG1pbGxpQ2Vsc2l1
cyAqLworCQkJaHlzdGVyZXNpcyA9IDwyMDAwPjsgLyogbWlsbGlDZWxzaXVzICovCisJCQl0eXBl
ID0gPFRIRVJNQUxfVFJJUF9DUklUSUNBTD47CisJCX07CisJfTsKK307Ci0tIAoxLjguMi4xLjM0
Mi5nZmE3Mjg1ZAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0
cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

[PATCH 15/16] arm: dts: add omap5 thermal data

[Eduardo Valentin]

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 07be2cd..b2ca0cf 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 */
@@ -704,13 +710,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";
+
+			#sensor-cells = <1>;
 		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[PATCH 15/16] arm: dts: add omap5 thermal data

[Eduardo Valentin]

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 07be2cd..b2ca0cf 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 */
@@ -704,13 +710,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";
+
+			#sensor-cells = <1>;
 		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[PATCH 15/16] arm: dts: add omap5 thermal data

[Eduardo Valentin]

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 07be2cd..b2ca0cf 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 */
@@ -704,13 +710,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";
+
+			#sensor-cells = <1>;
 		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d

[lm-sensors] [PATCH 15/16] arm: dts: add omap5 thermal data

[Eduardo Valentin]

VGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBkdHNpIGVudHJ5IG9uIG9tYXA1IHRvIGNvbnRhaW4KdGhl
IHRoZXJtYWwgZGF0YS4gVGhpcyBkYXRhIHdpbGwgZW5hYmxlIHRoZSBwYXNzaXZlCmNvb2xpbmcg
d2l0aCBDUFVmcmVxIGNvb2xpbmcgZGV2aWNlIGF0IDEwMEMuIFRoZQpzeXN0ZW0gd2lsbCBkbyBh
IHRoZXJtYWwgc2h1dGRvd24gYXQgMTI1QyB3aGVuZXZlcgphbnkgb2YgaXRzIHNlbnNvcnMgc2Vl
cyB0aGlzIGxldmVsLgoKQ2M6ICJCZW5vw650IENvdXNzb24iIDxiY291c3NvbkBiYXlsaWJyZS5j
b20+CkNjOiBUb255IExpbmRncmVuIDx0b255QGF0b21pZGUuY29tPgpDYzogUm9iIEhlcnJpbmcg
PHJvYi5oZXJyaW5nQGNhbHhlZGEuY29tPgpDYzogUGF3ZWwgTW9sbCA8cGF3ZWwubW9sbEBhcm0u
Y29tPgpDYzogTWFyayBSdXRsYW5kIDxtYXJrLnJ1dGxhbmRAYXJtLmNvbT4KQ2M6IFN0ZXBoZW4g
V2FycmVuIDxzd2FycmVuQHd3d2RvdG9yZy5vcmc+CkNjOiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1w
YmVsbEBjaXRyaXguY29tPgpDYzogUnVzc2VsbCBLaW5nIDxsaW51eEBhcm0ubGludXgub3JnLnVr
PgpDYzogbGludXgtb21hcEB2Z2VyLmtlcm5lbC5vcmcKQ2M6IGRldmljZXRyZWVAdmdlci5rZXJu
ZWwub3JnCkNjOiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKQ2M6IGxpbnV4
LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcKU2lnbmVkLW9mZi1ieTogRWR1YXJkbyBWYWxlbnRpbiA8
ZWR1YXJkby52YWxlbnRpbkB0aS5jb20+Ci0tLQogYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUuZHRz
aSB8IDEyICsrKysrKysrKystLQogMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKyksIDIg
ZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUuZHRzaSBi
L2FyY2gvYXJtL2Jvb3QvZHRzL29tYXA1LmR0c2kKaW5kZXggMDdiZTJjZC4uYjJjYTBjZiAxMDA2
NDQKLS0tIGEvYXJjaC9hcm0vYm9vdC9kdHMvb21hcDUuZHRzaQorKysgYi9hcmNoL2FybS9ib290
L2R0cy9vbWFwNS5kdHNpCkBAIC0zMyw3ICszMyw3IEBACiAJCSNhZGRyZXNzLWNlbGxzID0gPDE+
OwogCQkjc2l6ZS1jZWxscyA9IDwwPjsKIAotCQljcHVAMCB7CisJCWNwdTA6IGNwdUAwIHsKIAkJ
CWRldmljZV90eXBlID0gImNwdSI7CiAJCQljb21wYXRpYmxlID0gImFybSxjb3J0ZXgtYTE1IjsK
IAkJCXJlZyA9IDwweDA+OwpAQCAtNDUsNiArNDUsMTIgQEAKIAkJfTsKIAl9OwogCisJdGhlcm1h
bC16b25lcyB7CisJCSNpbmNsdWRlICJvbWFwNC1jcHUtdGhlcm1hbC5kdHNpIgorCQkjaW5jbHVk
ZSAib21hcDUtZ3B1LXRoZXJtYWwuZHRzaSIKKwkJI2luY2x1ZGUgIm9tYXA1LWNvcmUtdGhlcm1h
bC5kdHNpIgorCX07CisKIAl0aW1lciB7CiAJCWNvbXBhdGlibGUgPSAiYXJtLGFybXY3LXRpbWVy
IjsKIAkJLyogUFBJIHNlY3VyZS9ub25zZWN1cmUgSVJRICovCkBAIC03MDQsMTMgKzcxMCwxNSBA
QAogCQkJfTsKIAkJfTsKIAotCQliYW5kZ2FwQDRhMDAyMWUwIHsKKwkJYmFuZGdhcDogYmFuZGdh
cEA0YTAwMjFlMCB7CiAJCQlyZWcgPSA8MHg0YTAwMjFlMCAweGMKIAkJCSAgICAgICAweDRhMDAy
MzJjIDB4YwogCQkJICAgICAgIDB4NGEwMDIzODAgMHgyYwogCQkJICAgICAgIDB4NGEwMDIzQzAg
MHgzYz47CiAJCQlpbnRlcnJ1cHRzID0gPEdJQ19TUEkgMTI2IElSUV9UWVBFX0xFVkVMX0hJR0g+
OwogCQkJY29tcGF0aWJsZSA9ICJ0aSxvbWFwNTQzMC1iYW5kZ2FwIjsKKworCQkJI3NlbnNvci1j
ZWxscyA9IDwxPjsKIAkJfTsKIAl9OwogfTsKLS0gCjEuOC4yLjEuMzQyLmdmYTcyODVkCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBt
YWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vu
c29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

[PATCH 16/16] arm: dts: add cooling properties on omap5 cpu node

[Eduardo Valentin]

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 b2ca0cf..9eb95b7 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

[PATCH 16/16] arm: dts: add cooling properties on omap5 cpu node

[Eduardo Valentin]

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 b2ca0cf..9eb95b7 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

[PATCH 16/16] arm: dts: add cooling properties on omap5 cpu node

[Eduardo Valentin]

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 b2ca0cf..9eb95b7 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

[lm-sensors] [PATCH 16/16] arm: dts: add cooling properties on omap5 cpu node

[Eduardo Valentin]

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