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 ? > 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. > 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, which may well be. But you thought about it as well, so I don't think I am that far off track. 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. Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
