devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pawel Moll <pawel.moll@arm.com>
To: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Durgadoss R <durgadoss.r@intel.com>,
	"Zhang, Rui" <rui.zhang@intel.com>, Wei Ni <wni@nvidia.com>,
	"linux-pm@vger.kernel.org" <linux-pm@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: device thermal limits represented in device tree nodes
Date: Thu, 25 Jul 2013 18:33:31 +0100	[thread overview]
Message-ID: <1374773611.3213.44.camel@hornet> (raw)
In-Reply-To: <51F15E42.1060409@ti.com>

On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
> >> 	thermal_zone {
> >> 		type = "CPU";
> > 
> > So what does this exactly mean? What is so special about CPU? What other
> > types you've got there? (Am I just lazy not looking at the numerous
> > links you provided? ;-)
> 
> Hehehe. OK. Type is supposed to describe what your zone is representing.

As in "a name"? So, for example "The board", "PSU"? What I meant to ask
was: does the string carry any meaning?

> >> 		monitoring_device = <&sensor@xxxx
> >> 				    &sensor@yyyy>;
> >>
> >> 		mask = <0x03>; /* trips writability */
> >> 		passive_delay = <250>; /* milliseconds */
> >> 		polling_delay = <1000>; /* milliseconds */
> >> 		policy = "step_wise";
> > 
> > The word "policy" doesn't sound to me like a "hardware feature",
> > wouldn't you agree?
> 
> Agreed. As I mentioned in other email, we can leave this to OS decide
> what to use, by default, for instance.

Cool, I believe it is the right thing to do.

> > 
> >> 		trips {
> >> 			alert@100000{
> >> 				temperature = <100000>; /* milliCelsius
> >> 				hysteresis = <2000>; /* milliCelsius */
> >> 				type = <THERMAL_TRIP_PASSIVE>;
> >> 			};
> >> 			crit@125000{
> >> 				temperature = <125000>; /* milliCelsius
> >> 				hysteresis = <2000>; /* milliCelsius */
> >> 				type = <THERMAL_TRIP_CRITICAL>;
> >> 			};
> >> 		};
> >> 		bind_params {
> >> 			action@0{
> >>				cooling_device = "thermal-cpufreq";
> > 
> > Why is it a string? It seems very Linux-y... (cpufreq) Is there any
> > particular reason not to have phandles to the fans that have any impact
> > on the zone? 
> 
> Because fans are not the only way to cool your system, specially those
> systems that don't feature fans. Managing the speed of your CPU is one
> example of lowering temperature without fans. Managing the load on your
> system is another way. These are obviously, virtual concepts. And
> because we have physical ways and logical ways to cool the zone, then I
> didnt put a phandle to a device there.

"virtual concepts"... This is where my problem lies... It's not hardware
so it doesn't seem to belong in the tree at the first sight. Shouldn't
it focus on "physical data" instead? As in: point at devices that have
some impact on the conditions? For example, you can say "please, do the
right thing to cool your environment down" to both CPU and fan, can't
you? The "cooling driver" for the CPU would know that it has to slow
down, while a driver for the fan would know that it has to speed up ;-)

What I'm trying to say is that in my opinion the tree should simply link
the object, the sensor and the actuator. Nothing more, nothing less.

Thanks for your time!

Pawel



  reply	other threads:[~2013-07-25 17:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 14:25 RFC: device thermal limits represented in device tree nodes Eduardo Valentin
2013-07-24  1:44 ` Stephen Warren
2013-07-24 10:45   ` Mark Rutland
2013-07-24 13:29     ` Eduardo Valentin
2013-07-24 11:19   ` Pawel Moll
2013-07-24 15:04     ` Eduardo Valentin
2013-07-25 16:15       ` Pawel Moll
2013-07-25 16:38         ` Pawel Moll
2013-07-25 17:21           ` Eduardo Valentin
2013-07-25 17:20         ` Eduardo Valentin
2013-07-25 17:33           ` Pawel Moll [this message]
2013-07-26 19:55             ` Eduardo Valentin
2013-08-06 11:14               ` Pawel Moll
2013-08-07 20:18                 ` Eduardo Valentin
2013-08-08  8:53                   ` Mark Rutland
2013-08-08 13:45                     ` Pawel Moll
2013-07-24 13:24   ` Eduardo Valentin
  -- strict thread matches above, loose matches on Subject: below --
2013-07-22 14:19 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=1374773611.3213.44.camel@hornet \
    --to=pawel.moll@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=durgadoss.r@intel.com \
    --cc=eduardo.valentin@ti.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).