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
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
