Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On Mon, Jul 22, 2013 at 12:43:43PM -0700, Stephen Warren wrote: > On 07/21/2013 04:08 AM, Guenter Roeck wrote: > > ... [a bunch of good points re: why DT shouldn't describe thermal > > profiles] > > Yes, lots of good arguments there. > > So, where/how in your opinion should thermal profiles be defined, and > how should they get into the kernel? The nice thing about DT is that > it's a single place that describes the platform, with a well-defined > method of getting that information into the kernel. What alternatives exist? > Excellent but quite different question. Quite frankly, I would love to be able to use DT to describe a platform and its configuration and use instead of just its hardware. Just like with thermal data, it would be great if I could use devicetree information to describe limits for hwmon devices and configuration information for all kinds of devices. This would simplify my life a lot. Unfortunately, that is not how it works, so one ends up with pre-configuring devices on ROMMON or secondary methods such as sensors.conf for hwmon devices. Sure, that all works, but for embedded devices it means I have to re-build the root file system each time a limit is changed. It _would_ be much simpler to just be able to change the limit(s) in devicetree data and be done. So, no, I don't have a good other solution. I have seen attempts to implement a user-space 'parallel' devicetree, or the above mentioned sensors.conf file, but nothing comprehensive. If you find a good generic solution, let me know. Note that ACPI is an attempt to do that, but its scope is not limited to describing the hardware, and it is not available on non-Intel embedded systems. Also, it is typically controlled by another entity in a company (the BIOS engineers), who tend to be highly resistive to changes. Modifying ACPI data tends to be way more difficult than modifying devicetree data. > > 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. > > For audio, we have individual DT nodes that represent individual > audio-related components such as audio controllers, audio CODECs, etc. > We also have a "virtual" node that describes how those components > interact and create a complete sound card. Would it make sense to do > something similar with thermal sensors and cooling devices; represent > them all individually, have them register themselves with the > thermal/hwmon subsystem as you describe, but then have another "system > level" node that describes how the system designer intended them to > interact? > For device registration itself, definitely. An instance of a sensor driver should not have to know how (or if) it is used by the system, just like a gpio driver does not have to know if and how the gpio pins it provides are used. Binding is the tricky question here, as it is all virtual and, as you said yourself, describes the interaction and thus use of the various sensors and cooling devices to accomplish the ultimate goal of keeping the system in an acceptable temperature range. Hopefully you'll get an answer from the devicetree experts if your intended devicetree usage of it is acceptable. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 07/21/2013 04:08 AM, Guenter Roeck wrote: > ... [a bunch of good points re: why DT shouldn't describe thermal > profiles] Yes, lots of good arguments there. So, where/how in your opinion should thermal profiles be defined, and how should they get into the kernel? The nice thing about DT is that it's a single place that describes the platform, with a well-defined method of getting that information into the kernel. What alternatives exist? > 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. For audio, we have individual DT nodes that represent individual audio-related components such as audio controllers, audio CODECs, etc. We also have a "virtual" node that describes how those components interact and create a complete sound card. Would it make sense to do something similar with thermal sensors and cooling devices; represent them all individually, have them register themselves with the thermal/hwmon subsystem as you describe, but then have another "system level" node that describes how the system designer intended them to interact? If you don't think so, how would the kernel represent and gain that higher-level knowledge? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 07/21/2013 04:08 AM, Guenter Roeck wrote: ... [a bunch of good points re: why DT shouldn't describe thermal profiles] Yes, lots of good arguments there. So, where/how in your opinion should thermal profiles be defined, and how should they get into the kernel? The nice thing about DT is that it's a single place that describes the platform, with a well-defined method of getting that information into the kernel. What alternatives exist? 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. For audio, we have individual DT nodes that represent individual audio-related components such as audio controllers, audio CODECs, etc. We also have a virtual node that describes how those components interact and create a complete sound card. Would it make sense to do something similar with thermal sensors and cooling devices; represent them all individually, have them register themselves with the thermal/hwmon subsystem as you describe, but then have another system level node that describes how the system designer intended them to interact? If you don't think so, how would the kernel represent and gain that higher-level knowledge? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On Mon, Jul 22, 2013 at 12:43:43PM -0700, Stephen Warren wrote: On 07/21/2013 04:08 AM, Guenter Roeck wrote: ... [a bunch of good points re: why DT shouldn't describe thermal profiles] Yes, lots of good arguments there. So, where/how in your opinion should thermal profiles be defined, and how should they get into the kernel? The nice thing about DT is that it's a single place that describes the platform, with a well-defined method of getting that information into the kernel. What alternatives exist? Excellent but quite different question. Quite frankly, I would love to be able to use DT to describe a platform and its configuration and use instead of just its hardware. Just like with thermal data, it would be great if I could use devicetree information to describe limits for hwmon devices and configuration information for all kinds of devices. This would simplify my life a lot. Unfortunately, that is not how it works, so one ends up with pre-configuring devices on ROMMON or secondary methods such as sensors.conf for hwmon devices. Sure, that all works, but for embedded devices it means I have to re-build the root file system each time a limit is changed. It _would_ be much simpler to just be able to change the limit(s) in devicetree data and be done. So, no, I don't have a good other solution. I have seen attempts to implement a user-space 'parallel' devicetree, or the above mentioned sensors.conf file, but nothing comprehensive. If you find a good generic solution, let me know. Note that ACPI is an attempt to do that, but its scope is not limited to describing the hardware, and it is not available on non-Intel embedded systems. Also, it is typically controlled by another entity in a company (the BIOS engineers), who tend to be highly resistive to changes. Modifying ACPI data tends to be way more difficult than modifying devicetree data. 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. For audio, we have individual DT nodes that represent individual audio-related components such as audio controllers, audio CODECs, etc. We also have a virtual node that describes how those components interact and create a complete sound card. Would it make sense to do something similar with thermal sensors and cooling devices; represent them all individually, have them register themselves with the thermal/hwmon subsystem as you describe, but then have another system level node that describes how the system designer intended them to interact? For device registration itself, definitely. An instance of a sensor driver should not have to know how (or if) it is used by the system, just like a gpio driver does not have to know if and how the gpio pins it provides are used. Binding is the tricky question here, as it is all virtual and, as you said yourself, describes the interaction and thus use of the various sensors and cooling devices to accomplish the ultimate goal of keeping the system in an acceptable temperature range. Hopefully you'll get an answer from the devicetree experts if your intended devicetree usage of it is acceptable. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On Fri, Jul 19, 2013 at 02:56:19PM -0400, Eduardo Valentin wrote: > On 19-07-2013 14:45, Stephen Warren wrote: > > On 07/19/2013 07:38 AM, Eduardo Valentin wrote: > >> 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. > > > > I might suggest (a) sending the email "To" the DT maintainer, rather > > than just CC'ing him, (b) perhaps start a new thread just to present > > the proposed DT binding, and get feedback on that. A thread with a new > > subject like "[RFC] DT binding for thermal zones" might get more > > attention than a patch submission; the subject line of this patch > > doesn't stand much (since it implies to me it's more about build > > issues than DT bindings even though it does mention DT). > > > > OK. I will do that. Sounds reasonable. Resending this series as RFC > again, but now addressed to DT folks. > It might help to not just send the series, but to start a thread to discuss the proposed bindings. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On Fri, Jul 19, 2013 at 02:56:19PM -0400, Eduardo Valentin wrote: On 19-07-2013 14:45, Stephen Warren wrote: On 07/19/2013 07:38 AM, Eduardo Valentin wrote: 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. I might suggest (a) sending the email To the DT maintainer, rather than just CC'ing him, (b) perhaps start a new thread just to present the proposed DT binding, and get feedback on that. A thread with a new subject like [RFC] DT binding for thermal zones might get more attention than a patch submission; the subject line of this patch doesn't stand much (since it implies to me it's more about build issues than DT bindings even though it does mention DT). OK. I will do that. Sounds reasonable. Resending this series as RFC again, but now addressed to DT folks. It might help to not just send the series, but to start a thread to discuss the proposed bindings. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 19-07-2013 14:45, Stephen Warren wrote: > On 07/19/2013 07:38 AM, Eduardo Valentin wrote: >> 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. > > I might suggest (a) sending the email "To" the DT maintainer, rather > than just CC'ing him, (b) perhaps start a new thread just to present > the proposed DT binding, and get feedback on that. A thread with a new > subject like "[RFC] DT binding for thermal zones" might get more > attention than a patch submission; the subject line of this patch > doesn't stand much (since it implies to me it's more about build > issues than DT bindings even though it does mention DT). > OK. I will do that. Sounds reasonable. Resending this series as RFC again, but now addressed to DT folks. > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. > Does this describe hardware ? I don't think so, but, as I mentioned before, > maybe I am wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 07/19/2013 07:38 AM, Eduardo Valentin wrote: > 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. I might suggest (a) sending the email "To" the DT maintainer, rather than just CC'ing him, (b) perhaps start a new thread just to present the proposed DT binding, and get feedback on that. A thread with a new subject like "[RFC] DT binding for thermal zones" might get more attention than a patch submission; the subject line of this patch doesn't stand much (since it implies to me it's more about build issues than DT bindings even though it does mention DT). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 18-07-2013 17:21, 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, No, definitely this patch series is *not* about mapping multiples profiles for various use cases on device tree! This series is about mapping *hw thermal limits* on device tree. > I would argue that you crossed the line. 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. > Does this describe hardware ? I don't think so, but, as I mentioned before, > maybe I am wrong. Again, this is about describing points and actions to avoid your hw degradation. May be also useful to avoid end user harm. This series is not about describing performance profiles. > > Guenter > > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 18-07-2013 17:21, 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, No, definitely this patch series is *not* about mapping multiples profiles for various use cases on device tree! This series is about mapping *hw thermal limits* on device tree. I would argue that you crossed the line. 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. Does this describe hardware ? I don't think so, but, as I mentioned before, maybe I am wrong. Again, this is about describing points and actions to avoid your hw degradation. May be also useful to avoid end user harm. This series is not about describing performance profiles. Guenter -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 07/19/2013 07:38 AM, Eduardo Valentin wrote: 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. I might suggest (a) sending the email To the DT maintainer, rather than just CC'ing him, (b) perhaps start a new thread just to present the proposed DT binding, and get feedback on that. A thread with a new subject like [RFC] DT binding for thermal zones might get more attention than a patch submission; the subject line of this patch doesn't stand much (since it implies to me it's more about build issues than DT bindings even though it does mention DT). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. Does this describe hardware ? I don't think so, but, as I mentioned before, maybe I am wrong. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On 19-07-2013 14:45, Stephen Warren wrote: On 07/19/2013 07:38 AM, Eduardo Valentin wrote: 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. I might suggest (a) sending the email To the DT maintainer, rather than just CC'ing him, (b) perhaps start a new thread just to present the proposed DT binding, and get feedback on that. A thread with a new subject like [RFC] DT binding for thermal zones might get more attention than a patch submission; the subject line of this patch doesn't stand much (since it implies to me it's more about build issues than DT bindings even though it does mention DT). OK. I will do that. Sounds reasonable. Resending this series as RFC again, but now addressed to DT folks. -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. 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. Does this describe hardware ? I don't think so, but, as I mentioned before, maybe I am wrong. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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:-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. > > 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. 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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. 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. 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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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:-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. 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. Does this describe hardware ? I don't think so, but, as I mentioned before, maybe I am wrong. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. Guenter > The motivation to create such infrastructure is: > (i) - to reuse the existing temperature sensor code base; > (ii) - have a way to easily describe thermal data across different > boards for the same sensor. Say you have an i2c temp sensor, > which is placed close to your battery on board A but on > board B, another instance of this same senor is placed > close to your display, for instance. > > This series introduces then a DT parser. The data expected in > DT must contain the needed properties to build a thermal zone > out of the desired sensor. All properties are documented and > they are derived from the existing requirements of current > thermal API. > > In order to perform a binding with cooling devices, > the new thermal zone built using DT nodes will use > the existing thermal API that uses binding parameters. This is > the current proposed way to register thermal zones with platform > information, written by Durga. > > There are some virtual concepts that are pushed to device tree, > I know. But I believe using device tree to do this makes sense > because we are still describing the HW and how they are related > to each other. Things like cooling devices are not represented > in device tree though, as I believe that will cause a lot of > confusion with real devices (as already does). > > So the series is short but I think it makes sense to describe > how it is organized, as it touches several places. First four > patches are a preparation for this parser. There is a change > on cpufreq-cpu0, so that it knows now how to load its > corresponding cooling device. There is a change on thermal_core > to split its hwmon code, because I think we may need to improve > this code base when we start to integrate better with hwmon > temperature sensors. Then, another needed preparation is to > improve the bind_params, so that we are able to bind with > upper and lower limits. The remaining patches are the changes > with the proposed DT parser. A part from the DT thermal zone > builder itself (patch 05), I also changed the ti-soc-thermal > driver to use this new API and the omap4430 bandgap DT node, > as an example (this has been tested on panda omap4430); and also changed > the hwmon drivers lm75 and tmp102 to have the option to build > a thermal zone using DT. I haven't touched any dts file using > lm75 or tmp102 because this should come on a need basis. > > I believe this code is pretty usable the way it is, but might > need to be revisited, in case the enhancement proposed by Durga > get in. This is because representing virtual thermal zones > built out of several sensors may need a different representation > in DT. > > [1] - RFC of this work: > http://comments.gmane.org/gmane.linux.power-management.general/35874 > > Changes from RFC: > - Added a way to load cpufreq cooling device out of DT > - Added a way to bind with upper and lower limits using bind_params > - Added a way to specify upper and lower binding limits on DT > - Added DT thermal builder support to lm75 and tmp102 hwmon drivers > - Changed ERANGE to EDOM > - Added thermal constants for zone type and bind limit, so that > dts file could be more readable > > Tested on panda omap4430 (3.11-rc1 with minor changes for getting cpufreq > working) > > BR, > > Eduardo Valentin (9): > cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling' > thermal: hwmon: move hwmon support to single file > thermal: thermal_core: allow binding with limits on bind_params > arm: dts: flag omap4430 with needs-cooling for cpu node > thermal: introduce device tree parser > thermal: ti-soc-thermal: use thermal DT infrastructure > arm: dts: add omap4430 thermal data > hwmon: lm75: expose to thermal fw via DT nodes > hwmon: tmp102: expose to thermal fw via DT nodes > > .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 3 + > .../devicetree/bindings/thermal/thermal.txt| 133 ++ > Documentation/thermal/sysfs-api.txt| 7 + > arch/arm/boot/dts/omap443x.dtsi| 32 +- > drivers/cpufreq/cpufreq-cpu0.c | 8 + > drivers/hwmon/lm75.c | 29 ++ > drivers/hwmon/tmp102.c | 25 ++ > drivers/thermal/Kconfig| 22 + > drivers/thermal/Makefile | 4 + > drivers/thermal/thermal_core.c | 274 +--- > drivers/thermal/thermal_dt.c | 458 >
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
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. Guenter The motivation to create such infrastructure is: (i) - to reuse the existing temperature sensor code base; (ii) - have a way to easily describe thermal data across different boards for the same sensor. Say you have an i2c temp sensor, which is placed close to your battery on board A but on board B, another instance of this same senor is placed close to your display, for instance. This series introduces then a DT parser. The data expected in DT must contain the needed properties to build a thermal zone out of the desired sensor. All properties are documented and they are derived from the existing requirements of current thermal API. In order to perform a binding with cooling devices, the new thermal zone built using DT nodes will use the existing thermal API that uses binding parameters. This is the current proposed way to register thermal zones with platform information, written by Durga. There are some virtual concepts that are pushed to device tree, I know. But I believe using device tree to do this makes sense because we are still describing the HW and how they are related to each other. Things like cooling devices are not represented in device tree though, as I believe that will cause a lot of confusion with real devices (as already does). So the series is short but I think it makes sense to describe how it is organized, as it touches several places. First four patches are a preparation for this parser. There is a change on cpufreq-cpu0, so that it knows now how to load its corresponding cooling device. There is a change on thermal_core to split its hwmon code, because I think we may need to improve this code base when we start to integrate better with hwmon temperature sensors. Then, another needed preparation is to improve the bind_params, so that we are able to bind with upper and lower limits. The remaining patches are the changes with the proposed DT parser. A part from the DT thermal zone builder itself (patch 05), I also changed the ti-soc-thermal driver to use this new API and the omap4430 bandgap DT node, as an example (this has been tested on panda omap4430); and also changed the hwmon drivers lm75 and tmp102 to have the option to build a thermal zone using DT. I haven't touched any dts file using lm75 or tmp102 because this should come on a need basis. I believe this code is pretty usable the way it is, but might need to be revisited, in case the enhancement proposed by Durga get in. This is because representing virtual thermal zones built out of several sensors may need a different representation in DT. [1] - RFC of this work: http://comments.gmane.org/gmane.linux.power-management.general/35874 Changes from RFC: - Added a way to load cpufreq cooling device out of DT - Added a way to bind with upper and lower limits using bind_params - Added a way to specify upper and lower binding limits on DT - Added DT thermal builder support to lm75 and tmp102 hwmon drivers - Changed ERANGE to EDOM - Added thermal constants for zone type and bind limit, so that dts file could be more readable Tested on panda omap4430 (3.11-rc1 with minor changes for getting cpufreq working) BR, Eduardo Valentin (9): cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling' thermal: hwmon: move hwmon support to single file thermal: thermal_core: allow binding with limits on bind_params arm: dts: flag omap4430 with needs-cooling for cpu node thermal: introduce device tree parser thermal: ti-soc-thermal: use thermal DT infrastructure arm: dts: add omap4430 thermal data hwmon: lm75: expose to thermal fw via DT nodes hwmon: tmp102: expose to thermal fw via DT nodes .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 3 + .../devicetree/bindings/thermal/thermal.txt| 133 ++ Documentation/thermal/sysfs-api.txt| 7 + arch/arm/boot/dts/omap443x.dtsi| 32 +- drivers/cpufreq/cpufreq-cpu0.c | 8 + drivers/hwmon/lm75.c | 29 ++ drivers/hwmon/tmp102.c | 25 ++ drivers/thermal/Kconfig| 22 + drivers/thermal/Makefile | 4 + drivers/thermal/thermal_core.c | 274 +--- drivers/thermal/thermal_dt.c | 458 + drivers/thermal/thermal_hwmon.c| 269
