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

[Eduardo Valentin]

On 18-07-2013 17:11, Guenter Roeck wrote:
> On Thu, Jul 18, 2013 at 09:53:05AM -0400, 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.
>>
> Sorry, I don't know what ppl stands for.
> 
>>>
>>> Guenter
>>
>> As your answers to the series are giving same argument, I chose to
>> answer on patch 0. I would be happier if you could elaborate a bit more
>> on your concern, specially if you take hwmon cap here, and give your
>> view with that perspective.
>>
>> I also considered that this work could be abusing of DT purposes. But
>> let me explain why I still think it makes sense to have it.
>>
> Ultimately, you are making my point here. If you considered it, did you ask
> devicetree experts for an opinion ? Did you discuss the subject on the
> devicetree-discuss mailing list ? If so, what was the result ?

Although I have asked, I didn't get any feedback.
https://lkml.org/lkml/2013/4/11/760

But now I am requesting feedback in a formal (patch) way.

Consider this patch series as official request for (devicetree experts
and everyone involved) opinions.

> 
>> First thing is that this series intend to describe the thermal data
>> required for a specific board. That means, considering your board
>> layout, mechanics, power dissipation and composition of your ICs, etc,
>> that will impose thermal requirements on your system. That is not
>> configuration, but part of your board design and non-functional
>> requirement. To me, configuration would be something like saying you
>> want to use a specific keyboard layout, or defining your wifi card
>> channel, or display size, etc.
>>
>> Here what is described and setup may get confused with configuration,
>> but it is not because what goes in DT in this case must be actually
>> derived from your HW needs. Putting a sensor  close to your battery has
>> a strong meaning behind. Same if you put a sensor close to your
>> processor. For instance, we have cases we need to consider external heat
>> in order to properly determine our CPU hotspot level, using a board
>> sensor. That is what I mean by HW requirement/need.
>>
>> Again, just to refresh our minds, this is about protecting your board
>> and ICs from operating out of their spec and extending their lifetime.
>> This is not about configuring something just because user has chosen to.
>> That is definitely not a configuration.
>>
>> Being a use case, well, these new DT nodes can still be seen as a use
>> case, yes. But depends on your understanding of use case. Because a
>> sensor device may be used on different needs, composing different use
>> cases. But still here we are talking about HW needs and composition. And
>> yes, if you take that perspective, there are use cases already described
>> in DT.
>>
>> For instance, just because you use an LDO to power a MMC, does it mean
>> you always will use it to power MMC on all boards. Would that be a use
>> case? And in that example, because your MMC requires 2.8V, if you have a
>> DT property to say that, does it mean it is  configuration? Well, yes,
>> but that is based on HW needs, otherwise it wont operate properly. Same
>> thing here, leave your hw operating out of temperature specs and you
>> will see what is the outcome.
>>
>> Similar example would be cpufreq, or OPPs for opp layer. Defining an OPP
>> in DT could be considered a configuration?  Well in theory yes, one can
>> pick what ever configuration for your (D)PLL then match with a
>> minimalist voltage level. And in theory, a voltage level can sustain
>> more than one frequency level. An OPP is still a virtual concept, and we
>> still describe it in DT. Why? To me is because it is a HW need, because
>> HW folks have actually validated that configuration of PLL (frequency)
>> and voltage level. Sometimes they have even optimized it (for low power
>> consumption for instance), as one may achieve same OPP with different
>> configuration. Then why thermal data, which is again, a 'HW
>> configuration' that has been optimized by HW folks, known to be a HW
>> requirement, cannot be described in DT?
>>
>> Similar argument goes to the fact that one may think this is subsystem
>> specific. Again, describing your OPPs is not OPP layer specific?
>> Besides, one can still read the device tree nodes I have written for
>> describing thermal data and implement the HW requirement elsewhere, if
>> wanted (say in user land). I don't see as subsystem specific.
>>
>> Keep in mind that these very same concepts are actually derived from
>> ACPI specification. They don't come from nowhere. And just because your
>> system does not have ACPI support, does not mean it won't have a need to
>> describe thermal?
>>
>> So, because with this work (i) we are describing something that is
>> required for properly usage of your HW (and not choice of the user),
>> because (ii) same data is used on different specification (that is used
>> on different OSes too), because (iii) you don't need thermal fw to read
>> this data and you could implement the HW requirement elsewhere, because
>> (iv) there are other similar requirements already implemented via DT; I
>> still think this work is within DT scope. And that is based on evidence
>> of existing work not because DT is nice and I would want to use it.
>>
>> Hope that clarifies.
>>
>> Of course it is always welcome to hear ppl opinion. I would be really
>> interested to know what ppl from OF think about this topic.
>>
> Yes, me too, or more widely the devicetree community. This is exactly
> why I brought it up.

And that is why I copied them.

> 
>> If still, this does not fit DT, I would like to understand a proper
>> argument. Better than, this is configuration/use case.
>>
> 
> I am not a devicetree expert. One of the complaints by the devicetree
> folks is that much is added to devicetree which should not be there.
> I find this use case questionable. Maybe I am wrong and it isn't,

ok..

> which may well be. But you thought about it as well, so I don't think
> I am that far off track.

Well, what I meant was more like, yes, I considered DT requirements
before writing this code.

> 
> This needs to be discussed and determined by devicetree experts, not me.
> I'll be happy with your patch series if you get an agreement or an Ack
> by the devicetree maintainer for your patch series.

Ok. Thanks for your review and taking the time to express your judgment,
Guenter. Let s wait for Grant and dt folks to express their too.

> 
> Guenter
> 
> 


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

Eduardo Valentin

Attachment: signature.asc
Description: OpenPGP digital signature