lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <521FD70F.7080104@ti.com>
Date:	Thu, 29 Aug 2013 19:19:43 -0400
From:	Eduardo Valentin <eduardo.valentin@...com>
To:	Eduardo Valentin <eduardo.valentin@...com>
CC:	Mark Rutland <mark.rutland@....com>,
	"swarren@...dotorg.org" <swarren@...dotorg.org>,
	Pawel Moll <Pawel.Moll@....com>,
	"ian.campbell@...rix.com" <ian.campbell@...rix.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux@...ck-us.net" <linux@...ck-us.net>,
	"rui.zhang@...el.com" <rui.zhang@...el.com>,
	"wni@...dia.com" <wni@...dia.com>,
	"durgadoss.r@...el.com" <durgadoss.r@...el.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 02/14] drivers: thermal: introduce device tree parser

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.

> 
> 


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

Eduardo Valentin


Download attachment "signature.asc" of type "application/pgp-signature" (296 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ