All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Valentin <eduardo.valentin@ti.com>
To: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"rui.zhang@intel.com" <rui.zhang@intel.com>,
	"wni@nvidia.com" <wni@nvidia.com>,
	"durgadoss.r@intel.com" <durgadoss.r@intel.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 02/14] drivers: thermal: introduce device tree parser
Date: Mon, 2 Sep 2013 12:28:34 -0400	[thread overview]
Message-ID: <5224BCB2.9090305@ti.com> (raw)
In-Reply-To: <521FD70F.7080104@ti.com>

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

On 29-08-2013 19:19, Eduardo Valentin wrote:
> Mark, Pawel and Stephen,
> 
> 
> On 27-08-2013 14:17, Eduardo Valentin wrote:
>> On 27-08-2013 12:23, Mark Rutland wrote:
>>> On Tue, Aug 27, 2013 at 02:44:40PM +0100, Eduardo Valentin wrote:
>>>> Hello Mark,
> 
> <cut>
> 
> I believe now we need to align on thermal bindings, before I propose
> next version of this series. So, following the discussions on this
> thread, I believe a typical CPU thermal zone would look like the following:
> + #include <dt-bindings/thermal/thermal.h>
> +
> + cpu_thermal: cpu_thermal {
> +         passive-delay = <250>; /* milliseconds */
> +         polling-delay = <1000>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&bandgap0     0>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip            lower
> bound             upper bound
> +                          */
> +         cooling-devices = <&cpu0        100     &cpu-alert
> THERMAL_NO_LIMITS        THERMAL_NO_LIMITS>;
> +         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>;
> +                 };
> +         };
> + };
> 
> *Note: THERMAL_NO_LIMIT means, it will be using the cooling device
> minimum and maximum limits.
> 
> Couple of comments.
> 1. I am keeping the pooling intervals. A possible alternative way to
> describe that would be specifying the maximum dT/dt. Essentially because
> I am still convinced that this is part of hw specs.
> 
> 2. The above follows your suggestion to use consumer pointing to
> producers. Although, I still need to figure out how this could be
> implemented for Linux. But I think that is another story, at least for
> now. We need to first align on the DT binding itself.
> 
> 3. The link from cooling device specification to trip points, from my
> perspective, should be enough, and thus we shall not need the thermal
> cells and size for trip points, as you proposed. Let me know what you think.
> 
> Below is another example, on a more complex scenario, board specific
> case (hypothetical, just for exemplification):
> 
> + #include <dt-bindings/thermal/thermal.h>
> +
> + board_thermal: board_thermal {
> +         passive-delay = <1000>; /* milliseconds */
> +         polling-delay = <2500>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&adc-dummy     0>,
> +		    <&adc-dummy     1>,
> +		    <&adc-dymmy     2>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip		lower	upper
> +                          */
> +         cooling-devices = <&cpu0       75     &cpu-trip	0      2>,
> +			    <&gpu0       40     &gpu-trip	0      2>;
> +			    <&lcd0       25     &lcd-trip	5      10>;
> +         trips {
> +                 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>;
> +                 };
> +         };
> + };
> 
> Now writing the above example, one might want to have a way to say the
> sensor correlation equation.
> 
> Another example:
> + #include <dt-bindings/thermal/thermal.h>
> +
> + dsp_thermal: dsp_thermal {
> +         passive-delay = <250>; /* milliseconds */
> +         polling-delay = <1000>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&bandgap0     1>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip            lower
> bound             upper bound
> +                          */
> +         cooling-devices = <&dsp0        100     &dsp-alert
> THERMAL_NO_LIMIT        THERMAL_NO_LIMIT>;
> +         trips {
> +                 dsp-alert: dsp-alert {
> +                         temperature = <100000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_PASSIVE>;
> +                 };
> +                 dsp-crit: cdsp-crit {
> +                         temperature = <125000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_CRITICAL>;
> +                 };
> +         };
> + };
> +
> + gpu_thermal: gpu_thermal {
> +         passive-delay = <500>; /* milliseconds */
> +         polling-delay = <1000>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&bandgap0     2>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip            lower
> bound             upper bound
> +                          */
> +         cooling-devices = <&gpu0        100     &gpu-alert
> THERMAL_NO_LIMIT        THERMAL_NO_LIMIT>;
> +         trips {
> +                 gpu-alert: gpu-alert {
> +                         temperature = <100000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_PASSIVE>;
> +                 };
> +                 gpu-crit: gpu-crit {
> +                         temperature = <125000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_CRITICAL>;
> +                 };
> +         };
> + };
> 
> 
> Wei, I think the above would cover for the IPs with multiple internal
> sensors cases you were looking for, right?
> 
> Durga, please also check if I am missing something to cover for your
> plans to, in case you will be using DT to describe your HW.
> 
> Anyways, Mark and Pawel, let me know if I missed something from our
> discussion. I believe the above bindings would look more like regular
> standard DT bindings. And also they should be now slim enough, without
> Linux implementation details and also without policies.

Any objections on the above binding proposal?

> 
>>
>>
> 
> 


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

WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Valentin <eduardo.valentin@ti.com>
To: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"rui.zhang@intel.com" <rui.zhang@intel.com>,
	"wni@nvidia.com" <wni@nvidia.com>,
	"durgadoss.r@intel.com" <durgadoss.r@intel.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] [RFC PATCH 02/14] drivers: thermal: introduce device tree parser
Date: Mon, 02 Sep 2013 16:28:34 +0000	[thread overview]
Message-ID: <5224BCB2.9090305@ti.com> (raw)
In-Reply-To: <521FD70F.7080104@ti.com>


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

On 29-08-2013 19:19, Eduardo Valentin wrote:
> Mark, Pawel and Stephen,
> 
> 
> On 27-08-2013 14:17, Eduardo Valentin wrote:
>> On 27-08-2013 12:23, Mark Rutland wrote:
>>> On Tue, Aug 27, 2013 at 02:44:40PM +0100, Eduardo Valentin wrote:
>>>> Hello Mark,
> 
> <cut>
> 
> I believe now we need to align on thermal bindings, before I propose
> next version of this series. So, following the discussions on this
> thread, I believe a typical CPU thermal zone would look like the following:
> + #include <dt-bindings/thermal/thermal.h>
> +
> + cpu_thermal: cpu_thermal {
> +         passive-delay = <250>; /* milliseconds */
> +         polling-delay = <1000>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&bandgap0     0>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip            lower
> bound             upper bound
> +                          */
> +         cooling-devices = <&cpu0        100     &cpu-alert
> THERMAL_NO_LIMITS        THERMAL_NO_LIMITS>;
> +         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>;
> +                 };
> +         };
> + };
> 
> *Note: THERMAL_NO_LIMIT means, it will be using the cooling device
> minimum and maximum limits.
> 
> Couple of comments.
> 1. I am keeping the pooling intervals. A possible alternative way to
> describe that would be specifying the maximum dT/dt. Essentially because
> I am still convinced that this is part of hw specs.
> 
> 2. The above follows your suggestion to use consumer pointing to
> producers. Although, I still need to figure out how this could be
> implemented for Linux. But I think that is another story, at least for
> now. We need to first align on the DT binding itself.
> 
> 3. The link from cooling device specification to trip points, from my
> perspective, should be enough, and thus we shall not need the thermal
> cells and size for trip points, as you proposed. Let me know what you think.
> 
> Below is another example, on a more complex scenario, board specific
> case (hypothetical, just for exemplification):
> 
> + #include <dt-bindings/thermal/thermal.h>
> +
> + board_thermal: board_thermal {
> +         passive-delay = <1000>; /* milliseconds */
> +         polling-delay = <2500>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&adc-dummy     0>,
> +		    <&adc-dummy     1>,
> +		    <&adc-dymmy     2>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip		lower	upper
> +                          */
> +         cooling-devices = <&cpu0       75     &cpu-trip	0      2>,
> +			    <&gpu0       40     &gpu-trip	0      2>;
> +			    <&lcd0       25     &lcd-trip	5      10>;
> +         trips {
> +                 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>;
> +                 };
> +         };
> + };
> 
> Now writing the above example, one might want to have a way to say the
> sensor correlation equation.
> 
> Another example:
> + #include <dt-bindings/thermal/thermal.h>
> +
> + dsp_thermal: dsp_thermal {
> +         passive-delay = <250>; /* milliseconds */
> +         polling-delay = <1000>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&bandgap0     1>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip            lower
> bound             upper bound
> +                          */
> +         cooling-devices = <&dsp0        100     &dsp-alert
> THERMAL_NO_LIMIT        THERMAL_NO_LIMIT>;
> +         trips {
> +                 dsp-alert: dsp-alert {
> +                         temperature = <100000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_PASSIVE>;
> +                 };
> +                 dsp-crit: cdsp-crit {
> +                         temperature = <125000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_CRITICAL>;
> +                 };
> +         };
> + };
> +
> + gpu_thermal: gpu_thermal {
> +         passive-delay = <500>; /* milliseconds */
> +         polling-delay = <1000>; /* milliseconds */
> +                 /*
> +                  * sensor       ID
> +                  */
> +         sensors = <&bandgap0     2>;
> +                         /*
> +                          * cooling
> +                          * device       Usage   Trip            lower
> bound             upper bound
> +                          */
> +         cooling-devices = <&gpu0        100     &gpu-alert
> THERMAL_NO_LIMIT        THERMAL_NO_LIMIT>;
> +         trips {
> +                 gpu-alert: gpu-alert {
> +                         temperature = <100000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_PASSIVE>;
> +                 };
> +                 gpu-crit: gpu-crit {
> +                         temperature = <125000>; /* milliCelsius */
> +                         hysteresis = <2000>; /* milliCelsius */
> +                         type = <THERMAL_TRIP_CRITICAL>;
> +                 };
> +         };
> + };
> 
> 
> Wei, I think the above would cover for the IPs with multiple internal
> sensors cases you were looking for, right?
> 
> Durga, please also check if I am missing something to cover for your
> plans to, in case you will be using DT to describe your HW.
> 
> Anyways, Mark and Pawel, let me know if I missed something from our
> discussion. I believe the above bindings would look more like regular
> standard DT bindings. And also they should be now slim enough, without
> Linux implementation details and also without policies.

Any objections on the above binding proposal?

> 
>>
>>
> 
> 


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

  parent reply	other threads:[~2013-09-02 16:28 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-23 23:15 [RFC PATCH 00/14] RFCv2: device thermal limits represented in device tree nodes Eduardo Valentin
2013-08-23 23:15 ` Eduardo Valentin
2013-08-23 23:15 ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 01/14] cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones' Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-26  4:42   ` Viresh Kumar
2013-08-26  4:54     ` [lm-sensors] " Viresh Kumar
2013-08-26 12:13     ` Eduardo Valentin
2013-08-26 12:13       ` Eduardo Valentin
2013-08-26 12:13       ` [lm-sensors] " Eduardo Valentin
2013-08-27  9:29   ` Mark Rutland
2013-08-27  9:29     ` [lm-sensors] " Mark Rutland
2013-08-27 13:05     ` Eduardo Valentin
2013-08-27 13:05       ` Eduardo Valentin
2013-08-27 13:05       ` [lm-sensors] " Eduardo Valentin
2013-08-27 13:05       ` Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 02/14] drivers: thermal: introduce device tree parser Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-27 10:22   ` Mark Rutland
2013-08-27 10:22     ` [lm-sensors] " Mark Rutland
2013-08-27 13:44     ` Eduardo Valentin
2013-08-27 13:44       ` [lm-sensors] " Eduardo Valentin
2013-08-27 16:23       ` Mark Rutland
2013-08-27 16:23         ` [lm-sensors] " Mark Rutland
2013-08-27 18:17         ` Eduardo Valentin
2013-08-27 18:17           ` [lm-sensors] " Eduardo Valentin
2013-08-29 23:19           ` Eduardo Valentin
2013-08-29 23:19             ` [lm-sensors] " Eduardo Valentin
2013-09-02  8:14             ` Wei Ni
2013-09-02  8:14               ` [lm-sensors] " Wei Ni
2013-09-02 16:28             ` Eduardo Valentin [this message]
2013-09-02 16:28               ` Eduardo Valentin
2013-09-03 13:15             ` Mark Rutland
2013-09-03 13:15               ` [lm-sensors] " Mark Rutland
2013-09-03 17:12               ` Eduardo Valentin
2013-09-03 17:12                 ` [lm-sensors] " Eduardo Valentin
2013-09-07  0:19               ` Eduardo Valentin
2013-09-07  0:19                 ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 03/14] hwmon: lm75: expose to thermal fw via DT nodes Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:39   ` Guenter Roeck
2013-08-23 23:39     ` [lm-sensors] " Guenter Roeck
2013-08-26 12:11     ` Eduardo Valentin
2013-08-26 12:11       ` Eduardo Valentin
2013-08-26 12:11       ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:50   ` Guenter Roeck
2013-08-23 23:50     ` [lm-sensors] " Guenter Roeck
2013-08-26 12:15     ` Eduardo Valentin
2013-08-26 12:15       ` Eduardo Valentin
2013-08-26 12:15       ` [lm-sensors] " Eduardo Valentin
2013-08-27 10:26   ` Mark Rutland
2013-08-27 10:26     ` [lm-sensors] " Mark Rutland
2013-08-23 23:15 ` [RFC PATCH 04/14] hwmon: tmp102: " Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-27 10:27   ` Mark Rutland
2013-08-27 10:27     ` [lm-sensors] " Mark Rutland
2013-08-23 23:15 ` [RFC PATCH 05/14] thermal: ti-soc-thermal: use thermal DT infrastructure Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 06/14] arm: dts: add omap4 CPU thermal data Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 07/14] arm: dts: add omap4430 " Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 08/14] arm: dts: add omap4460 " Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 09/14] arm: dts: point to cooling-zones on omap4430 cpu node Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 10/14] arm: dts: point to cooling-zones on omap4460 " Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 11/14] arm: dts: add omap5 GPU thermal data Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 12/14] arm: dts: add omap5 CORE " Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 13/14] arm: dts: add omap5 " Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin
2013-08-23 23:15 ` [RFC PATCH 14/14] arm: dts: point to cooling-zones on omap5 cpu node Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` Eduardo Valentin
2013-08-23 23:15   ` [lm-sensors] " Eduardo Valentin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5224BCB2.9090305@ti.com \
    --to=eduardo.valentin@ti.com \
    --cc=Pawel.Moll@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=durgadoss.r@intel.com \
    --cc=grant.likely@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mark.rutland@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=rui.zhang@intel.com \
    --cc=swarren@wwwdotorg.org \
    --cc=wni@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.