[lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build

[Guenter Roeck]

On Fri, Jul 19, 2013 at 12:48:39PM -0600, Stephen Warren wrote:
> On 07/18/2013 03:21 PM, Guenter Roeck wrote:
> > On Thu, Jul 18, 2013 at 11:18:05AM -0600, Stephen Warren wrote:
> >> On 07/18/2013 07:53 AM, Eduardo Valentin wrote:
> >>> Hello Guenter,
> >>>
> >>> On 17-07-2013 18:09, Guenter Roeck wrote:
> >>>> On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin
> >>>> wrote:
> >>>>> Hello all,
> >>>>>
> >>>>> As you noticed, I am working in a way to represent thermal
> >>>>> data using device tree [1]. Essentially, this should be a way
> >>>>> to say what to do with a sensor and how to associate (cooling)
> >>>>> actions with it.
> >>>>>
> >>>> Seems to me that goes way beyond the supposed scope of devicetree
> >>>> data. Devicetree data is supposed to describe hardware, not its
> >>>> configuration or use. This is clearly a use case.
> >>>
> >>> Thanks for rising your voice here. It is important to know what
> >>> hwmon ppl think about this.
> >>
> >> I meant to find time to read Guenter's original email where he
> >> initially objected to putting data into DT, and determine exactly what
> >> was being objected to. I still haven't:-( However, the arguments that
> >> Eduardo stated in his email do make sense to me; I agree that
> >> temperature limits really are a description of HW. Details of which
> >> cooling methods to invoke when certain temperature limits are reached
> >> is also part of the HW/system design, and hence I would tend to agree
> >> that they're appropriate to include in DT. Anyway, that's just my 2
> >> cents on the matter:-)
> > 
> > Many systems have multiple profiles for various use cases (high performance,
> > low power etc), and limits are different based on the use case. If that means
> > you are going to have multiple devicetree variants based on the profile,
> > I would argue that you crossed the line.
> 
> Yes, I can see that argument. However, a counter-point:
> 
> * I believe we do need a DT binding to describe the absolute thermal
> limits of a system, for safety/correctness of system operation.
> 
> * We need to define a syntax/schema to represent that.
> 
> * If we then want to implement additional profiles with stricter limits,
> do we really want to invent a different syntax/schema to represent
> those? Representing them in the same way seems like good use of the
> design, mind-share, etc.
> 
> * Perhaps that doesn't mean that the additional profiles have to be in
> DT though; just that we somehow make any other representation of those
> profiles as close to the DT representation in syntax/structure as we
> can, to get maximum re-use.
> 
> > With thermal profiles it gets even more
> > complicated, as those parameters may be played around with and changed
> > multiple times to find the best settings to achieve optimal cooling.
> 
> To me, that sounds more like fixing a bug in the initial data, rather
> than something which fundamentally affects how the data should be
> represented.
> 

For me, a bug in devicetree data would be if a wrong gpio pin is assigned ... if
a wrong clock frequency is specified, or a wrong clock input. I would not expect
a clock rate or pin assignment to be played around with to find the optimal
setting. Either it works or it doesn't.

Note that we don't really talk about pure thermal limits here. We are talking
about association between thermal sensors and cooling devices, which is much
more abstract and not as well defined as clock pin assignments. In many case,
more than one cooling device exists, and there is no well defined means to cool
the system. It may be cooled with a fan, or by reducing the CPU clock speed.
There may be multiple fans interacting with each other, and not all may be
present at all times. There may be secondary cooling options if primary cooling
fails (eg reduce CPU speed or increase speed of a secondary fan if a primary fan
fails).

Yes, I understand you need a means to describe thermal profiles. Putting one of
those into DT and declaring it to be the "absolute thermal limit", however, is
really just asking for putting other thermal profiles into DT as well ..
if you want a different thermal profile, just load a different devicetree, and
possibly make it configurable in BIOS/ROMMON. Of course you can declare that not
to be "intentional", but what do you think would happen in the real world ?
Do you really think anyone would bother putting one profile into DT and others
into some other database ? Not really, especially if the kernel would not even
support reading that other database. And if it would, you would not need the
DT data in the first place.

This is completely different to the intended use of devicetree information.
An instance of devicetree data should be tied to a specific piece of hardware.
Changing it may enable or disable pieces of that hardware, but change its
operation, as in "optimize for performance" or "optimize for low power
consumption" ? Yes, again, I understand you are saying that this is not the
_intent_, but that is what it enables.

Other but related subject .. from a thermal / hwmon driver's perspective, if
such a driver supports thermal subsystem, it should just register itself as
thermal sensor device, because that is what it is. If and how it is tied to
cooling devices should be part of the thermal subsystem and be decided there.
I don't think it is necessary for a thermal sensor to read devicetree data
in order to determine if it is supposed to register as thermal device or not.
That _is_ configuration and does not describe hardware - the mere fact that
a thermal sensor exists in the system already identifies it as thermal sensor
device, not anything in devicetree data. This would be similar to, say, a clock
device. A clock is a clock, and registers itself with the clock subsystem even
if there is no consumer. Sure, its interconnection with clock consumers would
be determined by devicetree data, but that is a different subject. So, even if
devicetree maintainers accept your definition of thermal profiles as hardware,
I think your approach is still wrong, and a thermal sensor device should
register itself as thermal device independently of its association with
cooling devices.

Thanks,
Guenter