Re: RFC: device thermal limits represented in device tree nodes

[Pawel Moll]

Apologies about the delay, I was "otherwise engaged" for a week...

I hope you haven't lost all motivation to work on this subject, as it's
really worth the while!

On Fri, 2013-07-26 at 20:55 +0100, Eduardo Valentin wrote:
> On 25-07-2013 13:33, Pawel Moll wrote:
> > 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?

You haven't commended on this...

> >>>> 		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
>
> Yeah, in fact, this is exactly the point that creates most of the
> disagreement. You may check Guenter's arguments against this proposal
> (in my original RFC email, there is a link to it).
> 
> Well, if one don't want to see this as a 'virtual concept' it could say
> the cooling device is the cpu itself:
> 		cooling_device = <&cpu0>;

Would this create any particular problem at the driver/framework side?

> > 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.
> 
> OK. I think it would be a little unfair to have only links, without
> describing what this link is supposed to be or how it is supposed to be
> used. In previous discussions, I have mentioned two similar examples
> already existing in DT. Here are they: regulator bindings, one does not
> describe only which device connects to which regulator, but also needs
> to describe, voltage limits, current limits, offsets, and other
> properties. And an existing 'virtual concept' would be predefined CPU
> OPPs, that feed the opp layer. Those are configurations of the hardware
> that define a 'virtual' concept of operating point.
> 
> So, saying we need to describe only physical connections or touchable
> things would be a little unfair, IMO. Besides, thermal is still physical
> :-).

Believe me, I'm trying to be as fair as possible :-) and I see a lot of
value in describing the thermal properties of the platforms in the tree.
It's just that we really want to focus on describing the hardware, not
policies. And as you have already spent so much time on the matter, you
are in the best position to find the best set of *physical* properties
that would allow to make the right decision in the code. Could you,
please, try to make one step back and have another look at the problem?
What input data (as in: numbers :-) would you need to get what you want?
Are those numbers characteristic to the specific device (they probably
should live in the driver than) or to the board/platform (tree without a
doubt).

Thanks!

Pawel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/