The new thermal management sysfs class, and hwmon
The new thermal managemeny sysfs class that was just merged into acpi-test, especially when dealing with temperature measurement and fan control, has a lot of common ground with the hwmon interface.
However, the ACPI model for thermal cooling devices (fans, etc) and thermal zones (temp sensors) as currently implemented in the sysfs class appears at first glance to be a lot more simplified than what is available through the hwmon sysfs ABI (for a lack of a better term to describe the sysfs attribute specifications).
And the two sysfs ABIs are incompatible. The ACPI one uses low-precision units, (temperature in 10^0 degrees Celcius), while the hwmon ABI uses medium precision units (10^-3 degrees Celcius), for example. There is also no tachometer feedback for fans, etc.
Missing functionality in the new thermal class are apparently mainly related to the idea of hardware-based temperature limits and alarms, plus any non-trivial fan control schemes (many chips, and in case of thinkpad-acpi, EC firmware, have auto-cruise modes, some have more than one automatic fan
control scheme, etc). If I am wrong about this, please correct me.
IMHO, we can probably do better than two incompatible sysfs ABIs for what ammounts to the same functionality for many userspace applications (i.e. thermal monitor apps, and fan control and monitoring apps). And it would be really neat if the new thermal management stuff could just plug into the already available temperature sensors and fan controllers that follow the hwmon sysfs ABI.
Any thoughs on this?
Signature · 9 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi, henrique,
Quoted 5 lines · Henrique de Moraes Holschuh
The new thermal managemeny sysfs class that was just merged into acpi-test,
especially when dealing with temperature measurement and fan control, has a
lot of common ground with the hwmon interface.
Yes, that's true.
The idea is from Len's ols paper in 2007, "Cool Hand Linux - Handheld Thermal Extensions". The new thermal management sysfs class can be used by handheld devices which use device throttling for thermal control and may have no fan at all.
Please refer to
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2007-cool-web/
Quoted 10 lines
However, the ACPI model for thermal cooling devices (fans, etc) and thermal
zones (temp sensors) as currently implemented in the sysfs class appears at
first glance to be a lot more simplified than what is available through the
hwmon sysfs ABI (for a lack of a better term to describe the sysfs attribute
specifications).
Quoted 6 lines
And the two sysfs ABIs are incompatible. The ACPI one uses low-precision
units, (temperature in 10^0 degrees Celcius), while the hwmon ABI uses medium precision units (10^-3 degrees Celcius), for example. There is also
no tachometer feedback for fans, etc.
Yes, currently ACPI is the only user of the thermal sysfs I/F. We can add new sys I/F if someone really need it.
Quoted 12 lines
IMHO, we can probably do better than two incompatible sysfs ABIs for what
ammounts to the same functionality for many userspace applications (i.e.
thermal monitor apps, and fan control and monitoring apps). And it would be
really neat if the new thermal management stuff could just plug into the
already available temperature sensors and fan controllers that follow the
hwmon sysfs ABI.
Yes, we do want to use the hwmon sysfs ABI at the beginning. But there are several gaps that making us turn to a new thermal sysfs class. And the biggest one is that hwmon does NOT support ACPI passive cooling devices like processor, video, etc. intel menlow platform even has a ACPI memory controller device which can be throttled by changing the bandwidth. These are quite different from the hwmon's fan-based thermal management, right?
thanks,
rui
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi:
Quoted 4 lines · Henrique de Moraes Holschuh
Quoted 3 lines
The new thermal managemeny sysfs class that was just merged into acpi-test, especially when dealing with temperature measurement and fan control, has a lot of common ground with the hwmon interface.
Quoted 7 lines · Zhang Rui
Yes, that's true.
The idea is from Len's ols paper in 2007, "Cool Hand Linux - Handheld Thermal Extensions". The new thermal management sysfs class can be used by handheld devices which use device throttling for thermal control and may have no fan at all.
Please refer to
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2007-cool-web/
Interesting.
Quoted 22 lines
Quoted 10 lines
However, the ACPI model for thermal cooling devices (fans, etc) and thermal zones (temp sensors) as currently implemented in the sysfs class appears at first glance to be a lot more simplified than what is available through the hwmon sysfs ABI (for a lack of a better term to describe the sysfs attribute specifications).
And the two sysfs ABIs are incompatible. The ACPI one uses low-precision units, (temperature in 10^0 degrees Celcius), while the hwmon ABI uses medium precision units (10^-3 degrees Celcius), for example. There is also no tachometer feedback for fans, etc.
Yes, currently ACPI is the only user of the thermal sysfs I/F. We can add new sys I/F if someone really need it.
Quoted 7 lines
IMHO, we can probably do better than two incompatible sysfs ABIs for what ammounts to the same functionality for many userspace applications (i.e. thermal monitor apps, and fan control and monitoring apps). And it would be really neat if the new thermal management stuff could just plug into the already available temperature sensors and fan controllers that follow the hwmon sysfs ABI.
Quoted 7 lines
Yes, we do want to use the hwmon sysfs ABI at the beginning. But there are several gaps that making us turn to a new thermal sysfs class. And the biggest one is that hwmon does NOT support ACPI passive cooling devices like processor, video, etc. intel menlow platform even has a ACPI memory controller device which can be throttled by changing the bandwidth. These are quite different from the hwmon's fan-based thermal management, right?
The hwmon class ABI is more about exposing the functionality that is available on various devices than it is about accomplishing some specific task like "thermal management". That said...
I don't see why the hwmon class ABI couldn't be extended to accomodate CPU throttling, etc. But I also don't see that it hurts anything to put these controls somewhere else in sysfs.
I *do* think that any driver which reports temperature, etc. should expose those measurements through the hwmon class - even if they're exposed somewhere else as well.
Regards,
Signature · 8 lines
Mark M. Hoffman [email protected] _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 9 lines · Mark M. Hoffman
Quoted 8 lines · Zhang Rui
Quoted 4 lines · Henrique de Moraes Holschuh
And the two sysfs ABIs are incompatible. The ACPI one uses low-precision units, (temperature in 10^0 degrees Celcius), while the hwmon ABI uses medium precision units (10^-3 degrees Celcius), for example. There is also no tachometer feedback for fans, etc.
Yes, currently ACPI is the only user of the thermal sysfs I/F. We can add new sys I/F if someone really need it.
I would really appreciate if the thermal zone ABI used a subset of the hwmon ABI. There is absolutely no reason to have one return data in 10^-3 C while the other returns data in 10^0 C, for example. IMO, if both ABIs need thermal readings, both should use the same attribute, defined in the same way. The same goes for other attributes in the two interfaces that share a common concept.
Quoted 16 lines
Quoted 8 lines
Quoted 7 lines
IMHO, we can probably do better than two incompatible sysfs ABIs for what ammounts to the same functionality for many userspace applications (i.e. thermal monitor apps, and fan control and monitoring apps). And it would be really neat if the new thermal management stuff could just plug into the already available temperature sensors and fan controllers that follow the hwmon sysfs ABI.
Quoted 7 lines
Yes, we do want to use the hwmon sysfs ABI at the beginning. But there are several gaps that making us turn to a new thermal sysfs class. And the biggest one is that hwmon does NOT support ACPI passive cooling devices like processor, video, etc. intel menlow platform even has a ACPI memory controller device which can be throttled by changing the bandwidth. These are quite different from the hwmon's fan-based thermal management, right?
Quoted 3 lines
The hwmon class ABI is more about exposing the functionality that is available on various devices than it is about accomplishing some specific task like "thermal management". That said...
But a lot of chips *can* do thermal management, and there is an ABI for it on hwmon (but it is not easy to use, I started messing with lm85 to do so and dropped the ball because the in-chip ABI was not so easy to map to the hwmon ABI and I got sidetracked).
We could reshape that ABI into something that could be useful for all monitoring chips AND for both ACPI active and passive cooling control.
Quoted 3 lines
I don't see why the hwmon class ABI couldn't be extended to accomodate CPU throttling, etc. But I also don't see that it hurts anything to put these controls somewhere else in sysfs.
Agreed. However, *duplicating* what is already in hwmon elsewhere is not fun. Please reconsider. I'd like to see passive cooling (heck, the entire ACPI v3.0 thermal model, if needed) added to hwmon, that will enhance hwmon to be even more generic, and we all benefit from that.
Quoted 3 lines
I *do* think that any driver which reports temperature, etc. should expose those measurements through the hwmon class - even if they're exposed somewhere else as well.
While I *do* think if we have to expose them twice, we are doing something wrong :-)
Signature · 9 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 13 lines
-----Original Message-----
From: Henrique de Moraes Holschuh [mailto:[email protected]]
Sent: Sunday, February 03, 2008 11:20 PM
To: Mark M. Hoffman
Cc: Zhang, Rui; [email protected]; [email protected]; Jean Delvare; Len Brown; Thomas, Sujith
Subject: Re: The new thermal management sysfs class, and hwmonQuoted 2 lines · Mark M. Hoffman
Quoted 1 line · Zhang Rui
On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
And the two sysfs ABIs are incompatible. The ACPI one uses low-precision units, (temperature in 10^0 degrees Celcius),
while
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
the hwmon ABI uses medium precision units (10^-3 degrees
Celcius),
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
for example. There is also no tachometer feedback for fans,
etc.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, currently ACPI is the only user of the thermal sysfs I/F. We
can
Quoted 8 lines
Quoted 1 line
Quoted 1 line
add new sys I/F if someone really need it.
I would really appreciate if the thermal zone ABI used a subset of the hwmon
ABI. There is absolutely no reason to have one return data in 10^-3 C while
the other returns data in 10^0 C, for example. IMO, if both ABIs need thermal readings, both should use the same attribute, defined in the
same
Quoted 1 line
way. The same goes for other attributes in the two interfaces that
share
Quoted 2 lines
a
common concept.
1)Hwmon interface have other sensors for voltage and current measurement as well in addition to thermal sensors. Though this interface is generic from a "monitoring" perspective, it lacks some hierarchy representation. For eg. it lacks folder structure to store the list of devices associated with a thermal sensor. This hierarchy information is very much required by application to make an intelligent decision.
2) It is missing interfaces for passive device control.(CPU- T states,LCD,Memory controller, etc..)
3) The solution should work on any ACPI based system or any other thermal model for that matter which follows the basic concept. (The model being : There are devices associated with sensors and if we "control" the device, the temperature of the sensor will come down). 4)What I have understood is that Hwmon supports only Smbus and I2C based sensors. It doesn't have support for EC based sensors at this point of time.
5)If I am not wrong, Hwmon lacks support for programming AUX trip points and trigger events based on that.
These were all the facts which lead us to take a different route than hwmon.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
IMHO, we can probably do better than two incompatible sysfs ABIs
for
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
what ammounts to the same functionality for many userspace applications (i.e. thermal monitor apps, and fan control and monitoring apps). And it would be really neat if the new
thermal
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
management stuff could just plug into the already available temperature sensors and fan controllers that follow the hwmon
sysfs
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
ABI.
Yes, we do want to use the hwmon sysfs ABI at the beginning. But there are several gaps that making us turn to a new thermal
sysfs
Quoted 1 line
Quoted 1 line
Quoted 1 line
class. And the biggest one is that hwmon does NOT support ACPI
passive
Quoted 1 line
Quoted 1 line
Quoted 1 line
cooling devices like processor, video, etc. intel menlow platform
even
Quoted 1 line
Quoted 1 line
Quoted 1 line
has a ACPI memory controller device which can be throttled by
changing
Quoted 1 line
Quoted 1 line
Quoted 1 line
the bandwidth. These are quite different from the hwmon's
fan-based
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
thermal management, right?
The hwmon class ABI is more about exposing the functionality that is available on various devices than it is about accomplishing some specific task like "thermal management". That said...
But a lot of chips *can* do thermal management, and there is an ABI
for it
Quoted 1 line
on hwmon (but it is not easy to use, I started messing with lm85 to do
so
Quoted 1 line
and dropped the ball because the in-chip ABI was not so easy to map to
the
Quoted 6 lines
hwmon ABI and I got sidetracked).
We could reshape that ABI into something that could be useful for all monitoring chips AND for both ACPI active and passive cooling control.
Quoted 1 line
I don't see why the hwmon class ABI couldn't be extended to
accomodate
Quoted 1 line
Quoted 1 line
CPU throttling, etc. But I also don't see that it hurts anything to
put
Quoted 3 lines
Quoted 1 line
these controls somewhere else in sysfs.
Agreed. However, *duplicating* what is already in hwmon elsewhere is
not
Quoted 11 lines
fun. Please reconsider. I'd like to see passive cooling (heck, the entire
ACPI v3.0 thermal model, if needed) added to hwmon, that will enhance hwmon
to be even more generic, and we all benefit from that.Quoted 3 lines
I *do* think that any driver which reports temperature, etc. should expose those measurements through the hwmon class - even if they're exposed somewhere else as well.
While I *do* think if we have to expose them twice, we are doing
something
Quoted 1 line
wrong :-)
IMO the scope of hwmon is to monitor/report out temperature, voltage , current etc of the devices/platform . But the scope of these patches is purely thermal management for a generic thermal model. As a first step we have made it work for ACPI thermal model.
The only duplication which I can see of is in the "reporting of temperature", which is quite reasonable for a thermal management module to have.
:-Sujith
Quoted 6 lines
--
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Hi:
(btw: Please use an email client that doesn't completely butcher the text to which you're replying. Thanks.)
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines · Henrique de Moraes Holschuh
And the two sysfs ABIs are incompatible. The ACPI one uses low-precision units, (temperature in 10^0 degrees Celcius), while the hwmon ABI uses medium precision units (10^-3 degrees Celcius), for example. There is also no tachometer feedback for fans, etc.
Quoted 2 lines · Zhang Rui
Yes, currently ACPI is the only user of the thermal sysfs I/F. We can add new sys I/F if someone really need it.
* Henrique de Moraes Holschuh <[email protected]>:
Quoted 6 lines
Quoted 6 lines
I would really appreciate if the thermal zone ABI used a subset of the hwmon ABI. There is absolutely no reason to have one return data in 10^-3 C while the other returns data in 10^0 C, for example. IMO, if both ABIs need thermal readings, both should use the same attribute, defined in the same way. The same goes for other attributes in the two interfaces that share a common concept.
Quoted 6 lines · Thomas, Sujith
1)Hwmon interface have other sensors for voltage and current measurement as well in addition to thermal sensors. Though this interface is generic from a "monitoring" perspective, it lacks some hierarchy representation. For eg. it lacks folder structure to store the list of devices associated with a thermal sensor. This hierarchy information is very much required by application to make an intelligent decision.
It's not there now. It could be added.
Quoted 2 lines
2) It is missing interfaces for passive device control.(CPU- T states,LCD,Memory controller, etc..)
Ditto.
Quoted 4 lines
3) The solution should work on any ACPI based system or any other thermal model for that matter which follows the basic concept. (The model being : There are devices associated with sensors and if we "control" the device, the temperature of the sensor will come down).
The "association" bit is difficult for most hwmon drivers. There are 10k different mainboards, all wired differently, with no way to query them to determine e.g. which PWM output is associated with which temp sensor. So, we are forced to punt the assocation to userspace. You won't have that problem w/ ACPI - lucky you. ;)
That still doesn't mean that this info can't or shouldn't be exposed in hwmon when it *is* available.
Quoted 3 lines
4)What I have understood is that Hwmon supports only Smbus and I2C based sensors. It doesn't have support for EC based sensors at this point of time.
Incorrect. We support devices with a variety of hardware interfaces in addition to the I2C/SMBus. Did you even look?
Quoted 2 lines
5)If I am not wrong, Hwmon lacks support for programming AUX trip points and trigger events based on that.
You keep saying "hwmon lacks support for"... the hwmon sysfs interface supports exactly what the hardware can do. If your hardware can do something new or unique, you extend the interface to support it. There are numerous examples of this.
Quoted 2 lines
These were all the facts which lead us to take a different route than hwmon.
I don't actually mind having a thermal management interface that is outside of hwmon, if that's what you want to do. But these "facts" (which are the premises of your rationale) are mostly bogus.
<cut>
Quoted 2 lines · Thomas, Sujith
IMO the scope of hwmon is to monitor/report out temperature, voltage , current etc of the devices/platform . But the scope of these patches is
The scope of hwmon is to allow whatever the hardware allows. Period.
Quoted 5 lines
purely thermal management for a generic thermal model. As a first step we have made it work for ACPI thermal model.
The only duplication which I can see of is in the "reporting of temperature", which is quite reasonable for a thermal management module to have.
Well, HdMH and I apparently disagree about this. All I really care about is that the temp info should be available through /sys/class/hwmon. Many people just want to check their temps, without diving into the fine details of a "thermal management solution".
So... what class of hardware would I need to give these patches a try? Probably it would take me less time to write a patch to add hwmon class support to that than it did to write this message... ;)
Regards,
Signature · 8 lines
Mark M. Hoffman [email protected] _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 7 lines · Mark M. Hoffman
* Henrique de Moraes Holschuh <[email protected]>:
Quoted 6 lines
Quoted 6 lines
I would really appreciate if the thermal zone ABI used a subset of the hwmon ABI. There is absolutely no reason to have one return data in 10^-3 C while the other returns data in 10^0 C, for example. IMO, if both ABIs need thermal readings, both should use the same attribute, defined in the same way. The same goes for other attributes in the two interfaces that share a common concept.
Nobody seems to have paid attention to this detail so far.
At least *please* keep the two interfaces in sync for everything that is common to the two. As I driver author, I would appreciate that a LOT.
Quoted 2 lines
Incorrect. We support devices with a variety of hardware interfaces in addition to the I2C/SMBus. Did you even look?
Heh. I was the first to complain, and thinkpad-acpi is NOT a I2C or SMBus driver. In fact, it is an *ACPI* driver. It talks to the thinkpad ACPI EC using the APCI EC interface.
thinkpad-acpi uses the hwmon interface very effectively to export what would ammount to up to 16 thermal zones (although I have not seen more than 11 of them in use in any ThinkPad to date), one advanced fan controller that ACPI can't even model properly AFAIK, etc.
Quoted 6 lines
Quoted 2 lines
These were all the facts which lead us to take a different route than hwmon.
I don't actually mind having a thermal management interface that is outside of hwmon, if that's what you want to do. But these "facts" (which are the premises of your rationale) are mostly bogus.
Well, I *do* mind a thermal management interface outside of hwmon *when* it is duplicating functionality, but does it differently for no strong reason. Otherwise, I don't strongly care either way, even if I do prefer a single unified interface.
Please at least keep the same attribute naming and specification as hwmon for everything that is common to the two interfaces. That would make the life a lot easier for us driver writers.
But extending hwmon to do all ACPI needs it to would be *much* better IMHO, that would improve the hwmon interface, and give userspace a single generic thermal management *and* monitoring interface to talk to.
Quoted 5 lines · Thomas, Sujith
Quoted 2 lines
IMO the scope of hwmon is to monitor/report out temperature, voltage , current etc of the devices/platform . But the scope of these patches is
The scope of hwmon is to allow whatever the hardware allows. Period.
I'd say that the scope of hwmon is to allow *all* capabilities of any sensor/monitoring hardware/firmware to be exported to the kernel and userspace, *while* making as much common functionality between the various chips/firmwares/drivers as generic as possible. Old hwmon didn't attempt to do this, and it was hell to work with it. The new one with generic interfaces is a lot tougher on driver writers sometimes, but it paid off very well in userspace IMO.
Quoted 8 lines
Quoted 3 lines
The only duplication which I can see of is in the "reporting of temperature", which is quite reasonable for a thermal management module to have.
Well, HdMH and I apparently disagree about this. All I really care about is that the temp info should be available through
/sys/class/hwmon. Many people just want to check their temps, without diving into the fine details of a "thermal management solution".
Well, I strongly care for not having to duplicate the entire sysfs code of the thinkpad-acpi thermal management subdrivers (fan control, thermal readings) to a new interface AND maybe even finding myself in need to add a *third* platform device and driver to thinkpad-acpi just because the new interface didn't even try to be as compatible with hwmon as possible :-(
Signature · 9 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Len Brown
reviewerQuoted 9 lines · Henrique de Moraes Holschuh
Quoted 8 lines
Quoted 3 lines
The only duplication which I can see of is in the "reporting of temperature", which is quite reasonable for a thermal management module to have.
Well, HdMH and I apparently disagree about this. All I really care about is that the temp info should be available through
/sys/class/hwmon. Many people just want to check their temps, without diving into the fine details of a "thermal management solution".
Quoted 5 lines
Well, I strongly care for not having to duplicate the entire sysfs code of the thinkpad-acpi thermal management subdrivers (fan control, thermal readings) to a new interface AND maybe even finding myself in need to add a *third* platform device and driver to thinkpad-acpi just because the new interface didn't even try to be as compatible with hwmon as possible :-(
I expect that Thinpads will continue to be optimized primarily for Windows via ACPI. I don't expect thinkpads to suddenly switch over to OSPM user-space thermal control -- because Windows doesn't do that. So I don't think any bad things will happen if thinkpad-acpi doesn't respond to this.
I do agree that we should make the I/F the same, where possible, (that was my original proposal)
I'm delighted to hear that the hwmon community is open minded about expanding the capabilities of hwmon. We should definately look into that. While Menlo will likely start shipping with the current solution, there is no reason we can't evolve it over time -- for we know the guys writing the software that will use this I/F...
thanks,
-Len
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 16 lines · Len Brown
Quoted 9 lines · Henrique de Moraes Holschuh
Quoted 8 lines
Quoted 3 lines
The only duplication which I can see of is in the "reporting of temperature", which is quite reasonable for a thermal management module to have.
Well, HdMH and I apparently disagree about this. All I really care about is that the temp info should be available through
/sys/class/hwmon. Many people just want to check their temps, without diving into the fine details of a "thermal management solution".Quoted 5 lines
Well, I strongly care for not having to duplicate the entire sysfs code of the thinkpad-acpi thermal management subdrivers (fan control, thermal readings) to a new interface AND maybe even finding myself in need to add a *third* platform device and driver to thinkpad-acpi just because the new interface didn't even try to be as compatible with hwmon as possible :-(
Quoted 5 lines
I expect that Thinpads will continue to be optimized primarily for Windows via ACPI. I don't expect thinkpads to suddenly switch over to OSPM user-space thermal control -- because Windows doesn't do that. So I don't think any bad things will happen if thinkpad-acpi doesn't respond to this.
Nor do I. But thinkpad users (Windows AND linux users alike) don't exactly like the fan behaviour of the thinkpad EC, and they do override it with userspace solutions (yes, even in Windows). Either to speed the fan up earlier, or to speed it up much later :p
Heck, I find myself kicking the T43 fan to level 7 (fastest normal fan mode) every time I am doing a long kernel compile, just to make sure the temperatures don't rise too much. The T43 passive cooling ain't the best (people even hardware-mod it to enhance it), and the chinese plants manufacturing the planar cards for thinkpad have a long story of using crappy time-bomb solder that breaks under thermal stress after a few years, and I want my T43 to last without the need to reflow the entire planar card (motherboard) every five years. We *think* they started using better solder since the 2686 and 2687 T43 models, but the machines are not yet old enough to know this for sure, so better save than sorry.
So, you'd have a few users right there, including one that is a kernel developer and can give you high-quality feedback with an outsider PoV :) Heck, I keep getting requests to add a fan control loop in thinkpad-acpi... I'd very much prefer to have the ACPI subsystem handle it.
Quoted 2 lines
I do agree that we should make the I/F the same, where possible, (that was my original proposal)
Please do, then. At least for the termal readings, which are a clear pain right now for a driver writer to add to both hwmon and the new interfce. Name the attributes for thermal reading as hwmon does, use 10^-3 C as the unit, and if you want to give the thermal zone names from the ACPI tables, use the hwmon "label" attribute. That's not a big change, should take 1h tops to write and debug.
I have nothing against the generalized "cooling control levels" the new interface adds, and I wouldn't mind proposing the required hwmon changes, and adding it to thinkpad-acpi... it is just yet another attribute and another way to control the fan, hwmon already has enough of them that one extra won't matter at all.
Quoted 5 lines
I'm delighted to hear that the hwmon community is open minded about expanding the capabilities of hwmon. We should definately look into that. While Menlo will likely start shipping with the current solution, there is no reason we can't evolve it over time -- for we know the guys writing the software that will use this I/F...
It would be best to avoid changing the ABI too much, that's why I'd quite like to see at least the thermal zones become hwmon-ABI-compatible as soon as possible :(
Signature · 9 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 7 lines
-----Original Message-----
From: Mark M. Hoffman [mailto:[email protected]]
Sent: Tuesday, February 05, 2008 7:27 PM
To: Thomas, Sujith
Cc: Henrique de Moraes Holschuh; Zhang, Rui;
[email protected]; lm-
Quoted 12 lines
[email protected]; Jean Delvare; Len Brown
Subject: Re: The new thermal management sysfs class, and hwmonHi:
(btw: Please use an email client that doesn't completely butcher the text to which you're replying. Thanks.)
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines · Henrique de Moraes Holschuh
And the two sysfs ABIs are incompatible. The ACPI one uses low-precision units, (temperature in 10^0 degrees Celcius),
while
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
the hwmon ABI uses medium precision units (10^-3 degrees
Celcius),
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
for example. There is also no tachometer feedback for fans,
etc.
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines · Zhang Rui
Quoted 1 line
Yes, currently ACPI is the only user of the thermal sysfs I/F.
We
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
can add new sys I/F if someone really need it.
* Henrique de Moraes Holschuh <[email protected]>:
Quoted 1 line
Quoted 1 line
I would really appreciate if the thermal zone ABI used a subset of
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
hwmon ABI. There is absolutely no reason to have one return data
in
Quoted 1 line
Quoted 1 line
Quoted 1 line
10^-3 C while the other returns data in 10^0 C, for example. IMO,
if
Quoted 1 line
Quoted 1 line
Quoted 1 line
both ABIs need thermal readings, both should use the same
attribute,
Quoted 1 line
Quoted 1 line
Quoted 1 line
defined in the same way. The same goes for other attributes in
the two
Quoted 3 lines
Quoted 1 line
Quoted 1 line
interfaces that share a common concept.
* Thomas, Sujith <[email protected]> [2008-02-05 15:44:19
+0530]:
Quoted 1 line
Quoted 1 line
1)Hwmon interface have other sensors for voltage and current
measurement
Quoted 1 line
Quoted 1 line
as well in addition to thermal sensors. Though this interface is
generic
Quoted 1 line
Quoted 1 line
from a "monitoring" perspective, it lacks some hierarchy
representation.
Quoted 16 lines
Quoted 3 lines
For eg. it lacks folder structure to store the list of devices associated with a thermal sensor. This hierarchy information is very much required by application to make an intelligent decision.
It's not there now. It could be added.
Quoted 2 lines
2) It is missing interfaces for passive device control.(CPU- T states,LCD,Memory controller, etc..)
Ditto.
Quoted 4 lines
3) The solution should work on any ACPI based system or any other thermal model for that matter which follows the basic concept. (The model being : There are devices associated with sensors and if we "control" the device, the temperature of the sensor will come down).
Quoted 7 lines
The "association" bit is difficult for most hwmon drivers. There are 10k different mainboards, all wired differently, with no way to query them to determine e.g. which PWM output is associated with which temp sensor. So, we are forced to punt the assocation to userspace. You won't have that problem w/ ACPI - lucky you. ;)
That still doesn't mean that this info can't or shouldn't be exposed
in
Quoted 3 lines
hwmon when it *is* available.
Quoted 1 line
4)What I have understood is that Hwmon supports only Smbus and I2C
based
Quoted 1 line
Quoted 1 line
sensors. It doesn't have support for EC based sensors at this point
of
Quoted 3 lines
Quoted 1 line
time.
Incorrect. We support devices with a variety of hardware interfaces
in
Quoted 3 lines
addition to the I2C/SMBus. Did you even look?
Quoted 1 line
5)If I am not wrong, Hwmon lacks support for programming AUX trip
points
Quoted 5 lines
Quoted 1 line
and trigger events based on that.
You keep saying "hwmon lacks support for"... the hwmon sysfs interface supports exactly what the hardware can do. If your hardware can do something new or unique, you extend the interface to support it.
There
Quoted 3 lines
are numerous examples of this.
Quoted 1 line
These were all the facts which lead us to take a different route
than
Quoted 9 lines
Quoted 1 line
hwmon.
I don't actually mind having a thermal management interface that is outside of hwmon, if that's what you want to do. But these "facts" (which are the premises of your rationale) are mostly bogus.
<cut>
* Thomas, Sujith <[email protected]> [2008-02-05 15:44:19
+0530]:
Quoted 1 line
Quoted 1 line
IMO the scope of hwmon is to monitor/report out temperature, voltage
,
Quoted 1 line
Quoted 1 line
current etc of the devices/platform . But the scope of these patches
is
Quoted 4 lines
The scope of hwmon is to allow whatever the hardware allows. Period.
Quoted 1 line
purely thermal management for a generic thermal model. As a first
step
Quoted 3 lines
Quoted 3 lines
we have made it work for ACPI thermal model.
The only duplication which I can see of is in the "reporting of temperature", which is quite reasonable for a thermal management
module
Quoted 4 lines
Quoted 1 line
to have.
Well, HdMH and I apparently disagree about this. All I really care about is that the temp info should be available through
/sys/class/hwmon.
Quoted 1 line
Many people just want to check their temps, without diving into the
fine
Quoted 1 line
details of a "thermal management solution".
I absolutely don't have any issue with this. I feel that's the way to go. Hwmon can roll out a patch which can report out temperature of thermal sensors which are connected to EC and which follows ACPI spec.
:-Sujith
Quoted 3 lines
So... what class of hardware would I need to give these patches a try? Probably it would take me less time to write a patch to add hwmon
class
Quoted 7 lines
support to that than it did to write this message... ;)
Regards,
--
Mark M. Hoffman
[email protected]
On Wed, 2008-02-06 at 10:53 +0530, Thomas, Sujith wrote:
...
Quoted 3 lines
I absolutely don't have any issue with this. I feel that's the way to go. Hwmon can roll out a patch which can report out temperature of thermal sensors which are connected to EC and which follows ACPI spec.
Why do you want to still export the temperature via ACPI sysfs paths then?
Once it is there and userspace progs make use of it, you will have to maintain it forever and HAL is getting crazy and must take care about:
- How to find the ACPI thermal node
- Find the hwmon node
- Both interfaces provide temeratures
- Parse different output of temperature values (totally crazy)
Thomas
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 9 lines · Thomas Renninger
Why do you want to still export the temperature via ACPI sysfs paths then?
Once it is there and userspace progs make use of it, you will have to maintain it forever and HAL is getting crazy and must take care about:
- How to find the ACPI thermal node
- Find the hwmon node
- Both interfaces provide temeratures
- Parse different output of temperature values (totally crazy)
Quite. There's still been no indication that anyone cares about fixing this interface, and I'm upset that it was merged despite there being clear and valid concerns about it. Do we have a commitment that it's going to be cleaned up before final? If not, it should be pulled before userspace starts depending on it. The only hardware where this currently matters isn't going to be running 2.6.25 anyway.
Signature · 6 lines
Matthew Garrett | [email protected] _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 5 lines · Thomas Renninger
Quoted 4 lines
Why do you want to still export the temperature via ACPI sysfs paths then?
Once it is there and userspace progs make use of it, you will have
to
Quoted 1 line
Quoted 1 line
maintain it forever and HAL is getting crazy and must take care
about:
Quoted 11 lines
Quoted 5 lines
- How to find the ACPI thermal node
- Find the hwmon node
- Both interfaces provide temeratures
- Parse different output of temperature values (totally crazy)Quite. There's still been no indication that anyone cares about fixing
this interface, and I'm upset that it was merged despite there being clear and valid concerns about it. Do we have a commitment that it's going to be cleaned up before final? If not, it should be pulled
before
Quoted 1 line
userspace starts depending on it. The only hardware where this
currently
Quoted 1 line
matters isn't going to be running 2.6.25 anyway.
Len had mentioned in one of his responses that there is scope for evolving
and we can do that. As you pointed out if there are differences in the way temperatures are reported out, we can go ahead and
fix it.
Sujith
Quoted 3 lines
Signature · 2 lines
-- Matthew Garrett | [email protected]
Quoted 6 lines · Sujith
Len had mentioned in one of his responses that there is scope for evolving
and we can do that. As you pointed out if there are differences in the way temperatures are reported out, we can go ahead and
fix it.
That's fine, but it *needs* to be done before 2.6.25 is released. Otherwise we're stuck with the broken one forever, which is somewhat longer than ideal.
Signature · 6 lines
Matthew Garrett | [email protected] _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 11 lines · Matthew Garrett
Quoted 6 lines · Sujith
Len had mentioned in one of his responses that there is scope for evolving
and we can do that. As you pointed out if there are differences in the way temperatures are reported out, we can go ahead and
fix it.That's fine, but it *needs* to be done before 2.6.25 is released. Otherwise we're stuck with the broken one forever, which is somewhat longer than ideal.
And, frankly, the thermal sysfs class should be marked EXPERIMENTAL in Kconfig at this time, IMHO. Otherwise, fixing it after 2.6.25 is out will be more difficult.
Signature · 9 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi, all,
Sorry for the late response as I'm on the Chinese New Year vacation.
Quoted 14 lines · Matthew Garrett
Quoted 3 lines · Thomas Renninger
Why do you want to still export the temperature via ACPI sysfs paths then?
Once it is there and userspace progs make use of it, you will haveto
Quoted 1 line
maintain it forever and HAL is getting crazy and must take care
about:
Quoted 5 lines
- How to find the ACPI thermal node
- Find the hwmon node
- Both interfaces provide temeratures
- Parse different output of temperature values (totally crazy)
Quoted 9 lines
Quite. There's still been no indication that anyone cares about fixing this interface, and I'm upset that it was merged despite there being clear and valid concerns about it. Do we have a commitment that it's going to be cleaned up before final? If not, it should be pulled before
userspace starts depending on it. The only hardware where this currently
matters isn't going to be running 2.6.25 anyway.
Here is my understanding of the problem, please correct me if I say something wrong. :)
It would be great if we can use the hwmon for ACPI thermal model. And it's also true that there are some gaps exist just as thomas had already listed.
so let's make the problems clear one by one. Surely it would be great if we can solve all the problems so that we can use the hwmon. But if not, please let the new thermal sysfs class go upstream as we really need this functionality and we don't get any alternatives.
Here is a typical thermal sys I/F for ACPI thermal zone. /sys/class/thermal:
|thermal_zone1:
|-----type: ACPI thermal zone
|-----temp: 37
|-----mode: kernel
|----trip_point_0_temp: 100
|-----trip_point_0_type: critical
|-----trip_point_1_temp: 80
|-----trip_point_1_type: passive
|-----trip_point_2_temp: 70
|-----trip_point_2_type: active0
|-----trip_point_3_temp: 60
|-----trip_point_3_type: active1
|-----cdev0:
--->/sys/class/thermal/cooling_device0
|-----cdev0_trip_point: 1 /* used for passive */
|-----cdev1: --->/sys/class/thermal/cooling_device1
|-----cdev1_trip_point: 1 /* used for passive */
|-----cdev2: --->/sys/class/thermal/cooling_device2
|-----cdev2_trip_point: 2 /* used for active0 */
|-----cdev3: --->/sys/class/thermal/cooling_device3
|-----cdev3_trip_point: 2 /* used for active0 */
|-----cdev4: --->/sys/class/thermal/cooling_device3
|-----cdev4_trip_point: 3 /* used for active1*/
|thermal_zone2:
|-----type: ACPI thermal zone
|-----temp: 43
|-----mode: kernel
|-----trip_point_0_temp: 105
|-----trip_point_0_type: critical
|-----trip_point_1_temp: 65
|-----trip_point_1_type: passive
|-----cdev0: --->/sys/class/thermal/cooling_device0
|-----cdev0_trip_point: 1 /* used for passive */|cooling_device0:
|-----type: Processor
|-----max_state: 8
|-----cur_state: 0
|cooling_device1:
|-----type: Processor
|-----max_state: 8
|-----cur_state: 0
|cooling_device2:
|-----type: Fan
|-----max_state: 1
|-----cur_state: 0
|cooling_device3:
|-----type: Fan
|-----max_state: 1
|-----cur_state: 0The first problem is how to use hwmon for all cooling device. We need a uniform I/F for both fan and passive cooling devices.
pwm[1-*]_enable, and pwm[1-*] and fan[1-*]_input can be used for fan control.
The same I/F can work for acpi fan, even for all cooling devices, e.g pwm[1-*]_enable to enable/disable cooling device control via acpi thermal driver, pwm[1-*] to control the device cooling state, where 0 stands for no cooling and 255 stands for maximum cooling state. But it seems really ugly and it's a misuse of pwm[1-*] attribute, right?
So we should either introduce new hwmon ABIs for cooling device control, just like what we've already done in the thermal sys class, or give up the idea of making them hwmon compatible.
If we have generic hwmon ABIs for all cooling devices, let's go further. Hwmon also has the ABIs to support multiple trip points for fan device, i.e. pwm[1-*]_auto_point[1-*]_pwm and pwm[1-*]_auto_point[1-*]_temp. But in order to make this available for all cooling devices, we still need to introduce new ABIs, maybe something like dev[1-*]_auto_point[1-*]_temp.
And we also needs to introduce the folder structure to store the list of devices associated with a thermal sensor.
Then the new thermal sys I/F should look like:/sys/class/hwmon:
|hwmon0/device: --->/sys/class/thermal/thermal_zone0
|hwmon1/device: --->/sys/class/thermal/thermal_zone1
/sys/class/thermal:
|thermal_zone0:
|-----name: ACPI thermal zone
|-----temp1_input: 37000
|-----temp1_crit: 100000
|-----dev1_enable: 2
|-----dev1_control: --->/sys/class/thermal/cooling_device0
|-----dev1_auto_point1_temp: 80000
|-----dev2_enable: 2
|-----dev2_control: --->/sys/class/thermal/cooling_device1
|-----dev2_auto_point1_temp: 80000
|-----dev3_enable: 2
|-----dev3_control: --->/sys/class/thermal/cooling_device2
|-----dev3_auto_point1_temp: 70000
|-----dev4_enable: 2
|-----dev4__control: --->/sys/class/thermal/cooling_device3
|-----dev4_auto_point1_temp: 60000|thermal_zone1:
|-----name: ACPI thermal zone
|-----temp1_input: 43000
|-----temp1_crit: 105000
|-----dev1_enable: 2
|-----dev1__control: --->/sys/class/thermal/cooling_device1
|-----dev1_auto_point1_temp: 85000|cooling_device0: no change |cooling_device1: ... |cooling_device2: ... |cooling_device3: ...
(PS: I don't like the idea of mapping the cur_state to an Integer value in the range 0 to 255 like PWM[1-*], cur_state/max_state will be much easier for user space to use, what do you think?)
So this is the prototype proposal. IMO, the hwmon doesn't have any framework for us to use, we will end up first doing framework and then making use of it which is not worth doing. :(
If you think something is wrong/improper, or you get some better ideas, please just speak it out. Any comments are appreciated. ;)
thanks,
rui
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 155 lines · zhangrui
Hi, all,
Sorry for the late response as I'm on the Chinese New Year vacation.
Quoted 13 lines · Matthew Garrett
Quoted 3 lines · Thomas Renninger
Why do you want to still export the temperature via ACPI sysfs paths then?
Once it is there and userspace progs make use of it, you will haveto
Quoted 1 line
maintain it forever and HAL is getting crazy and must take care
about:
Quoted 5 lines
- How to find the ACPI thermal node
- Find the hwmon node
- Both interfaces provide temeratures
- Parse different output of temperature values (totally crazy)Quoted 9 lines
Quite. There's still been no indication that anyone cares about fixing this interface, and I'm upset that it was merged despite there being clear and valid concerns about it. Do we have a commitment that it's going to be cleaned up before final? If not, it should be pulled before
userspace starts depending on it. The only hardware where this currently
matters isn't going to be running 2.6.25 anyway.Here is my understanding of the problem, please correct me if I say something wrong. :)
It would be great if we can use the hwmon for ACPI thermal model. And it's also true that there are some gaps exist just as thomas had already listed.
so let's make the problems clear one by one. Surely it would be great if we can solve all the problems so that we can use the hwmon. But if not, please let the new thermal sysfs class go upstream as we really need this functionality and we don't get any alternatives.Here is a typical thermal sys I/F for ACPI thermal zone.
/sys/class/thermal:
|thermal_zone1:|-----type: ACPI thermal zone |-----temp: 37 |-----mode: kernel |----trip_point_0_temp: 100 |-----trip_point_0_type: critical |-----trip_point_1_temp: 80 |-----trip_point_1_type: passive |-----trip_point_2_temp: 70 |-----trip_point_2_type: active0 |-----trip_point_3_temp: 60 |-----trip_point_3_type: active1 |-----cdev0: --->/sys/class/thermal/cooling_device0 |-----cdev0_trip_point: 1 /* used for passive */ |-----cdev1: --->/sys/class/thermal/cooling_device1 |-----cdev1_trip_point: 1 /* used for passive */ |-----cdev2: --->/sys/class/thermal/cooling_device2 |-----cdev2_trip_point: 2 /* used for active0 */ |-----cdev3: --->/sys/class/thermal/cooling_device3 |-----cdev3_trip_point: 2 /* used for active0 */ |-----cdev4: --->/sys/class/thermal/cooling_device3 |-----cdev4_trip_point: 3 /* used for active1*/ |thermal_zone2: |-----type: ACPI thermal zone |-----temp: 43 |-----mode: kernel |-----trip_point_0_temp: 105 |-----trip_point_0_type: critical |-----trip_point_1_temp: 65 |-----trip_point_1_type: passive |-----cdev0: --->/sys/class/thermal/cooling_device0 |-----cdev0_trip_point: 1 /* used for passive */|cooling_device0:
|-----type: Processor |-----max_state: 8 |-----cur_state: 0 |cooling_device1: |-----type: Processor |-----max_state: 8 |-----cur_state: 0 |cooling_device2: |-----type: Fan |-----max_state: 1 |-----cur_state: 0 |cooling_device3: |-----type: Fan |-----max_state: 1 |-----cur_state: 0The first problem is how to use hwmon for all cooling device. We need a uniform I/F for both fan and passive cooling devices.
pwm[1-*]_enable, and pwm[1-*] and fan[1-*]_input can be used for fan control.
The same I/F can work for acpi fan, even for all cooling devices, e.g pwm[1-*]_enable to enable/disable cooling device control via acpi thermal driver, pwm[1-*] to control the device cooling state, where 0 stands for no cooling and 255 stands for maximum cooling state. But it seems really ugly and it's a misuse of pwm[1-*] attribute, right?So we should either introduce new hwmon ABIs for cooling device control, just like what we've already done in the thermal sys class, or give up the idea of making them hwmon compatible.
If we have generic hwmon ABIs for all cooling devices, let's go further. Hwmon also has the ABIs to support multiple trip points for fan device, i.e. pwm[1-*]_auto_point[1-*]_pwm and pwm[1-*]_auto_point[1-*]_temp. But in order to make this available for all cooling devices, we still need to introduce new ABIs, maybe something like dev[1-*]_auto_point[1-*]_temp.
And we also needs to introduce the folder structure to store the list of devices associated with a thermal sensor.
Then the new thermal sys I/F should look like:
/sys/class/hwmon:
|hwmon0/device: --->/sys/class/thermal/thermal_zone0
|hwmon1/device: --->/sys/class/thermal/thermal_zone1
/sys/class/thermal:
|thermal_zone0:|-----name: ACPI thermal zone |-----temp1_input: 37000 |-----temp1_crit: 100000 |-----dev1_enable: 2 |-----dev1_control: --->/sys/class/thermal/cooling_device0 |-----dev1_auto_point1_temp: 80000 |-----dev2_enable: 2 |-----dev2_control: --->/sys/class/thermal/cooling_device1 |-----dev2_auto_point1_temp: 80000 |-----dev3_enable: 2 |-----dev3_control: --->/sys/class/thermal/cooling_device2 |-----dev3_auto_point1_temp: 70000 |-----dev4_enable: 2 |-----dev4__control: --->/sys/class/thermal/cooling_device3 |-----dev4_auto_point1_temp: 60000|thermal_zone1:
|-----name: ACPI thermal zone |-----temp1_input: 43000 |-----temp1_crit: 105000 |-----dev1_enable: 2 |-----dev1__control: --->/sys/class/thermal/cooling_device1 |-----dev1_auto_point1_temp: 85000|cooling_device0: no change |cooling_device1: ... |cooling_device2: ... |cooling_device3: ...(PS: I don't like the idea of mapping the
cur_stateto an Integer value in the range 0 to 255 like PWM[1-*], cur_state/max_state will be much easier for user space to use, what do you think?)
Quoted 6 lines
So this is the prototype proposal. IMO, the hwmon doesn't have any framework for us to use, we will end up first doing framework and then making use of it which is not worth doing. :(
If you think something is wrong/improper, or you get some better ideas, please just speak it out. Any comments are appreciated. ;)
I think all that is really needed and asked for is for the new thermal ACPI code to:
1) provide temp readings in the same format as hwmon (so milli degrees celcius, not degrees celcius)
2) provide a hwmon interface so that tools like (but not limited too):
* net-snmp
* mrtg
* sensors
* sensors-applet (gnome)
* xfce-sensors-applet
* ksysguard
* ksensors
* gkrellm
Can provide temp and fan readings without having to be modified.
To be clear I am suggesting that the new code exports both:
1) the current full fledged thermal acpi zone interface, as designed for both reading and configuration
2) a read only hwmon interface for reporting temps and fans
Regards,
Hans (lm_sensors contributer)
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi, Hans,
Quoted 6 lines · Hans de Goede
I think all that is really needed and asked for is for the new thermal ACPI
code to:
1) provide temp readings in the same format as hwmon (so milli degrees celcius,
not degrees celcius
Agree.
Quoted 11 lines
2) provide a hwmon interface so that tools like (but not limited too):
* net-snmp
* mrtg
* sensors
* sensors-applet (gnome)
* xfce-sensors-applet
* ksysguard
* ksensors
* gkrellmCan provide temp and fan readings without having to be modified.
hmm, for fan device, maybe something like this? pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
2+: automatic fan control (by acpi thermal driver)
pwm[1-*] = 0 : fan is off.
pwm[1-*] = 255: fan is on.
pwm[1-*] has only two valid values as ACPI fan only support two states, ON/OFF. and it doesn't need fan[1-*]_input because the fan speed is not available.
Yes, it can work for ACPI fan although I don't think the existing pwm hwmon I/F maps well to what we need and it seems like a "forced fit" to use it. Any better ideas? :)
Thanks,
Rui
Quoted 5 lines
To be clear I am suggesting that the new code exports both:
1) the current full fledged thermal acpi zone interface, as designed for
both reading and configuration
2) a read only hwmon interface for reporting temps and fans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 22 lines · Rui
Hi, Hans,
Quoted 6 lines · Hans de Goede
I think all that is really needed and asked for is for the new thermal ACPI
code to:
1) provide temp readings in the same format as hwmon (so milli degrees celcius,
not degrees celciusAgree.
Quoted 11 lines
2) provide a hwmon interface so that tools like (but not limited too):
* net-snmp
* mrtg
* sensors
* sensors-applet (gnome)
* xfce-sensors-applet
* ksysguard
* ksensors
* gkrellmCan provide temp and fan readings without having to be modified.
Quoted 12 lines
hmm, for fan device, maybe something like this? pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
2+: automatic fan control (by acpi thermal driver)
pwm[1-*] = 0 : fan is off.
pwm[1-*] = 255: fan is on.
pwm[1-*] has only two valid values as ACPI fan only support two states, ON/OFF. and it doesn't need fan[1-*]_input because the fan speed is not available.
Yes, it can work for ACPI fan although I don't think the existing pwm hwmon I/F maps well to what we need and it seems like a "forced fit" to use it. Any better ideas? :)
I wouldn't expose a pwm interface, doing so isn't that important as none of the above listed apps actually use it, the pwm interface really only is for people who want to manually tweak their fan speed and / or use some scripts to control the fan speed based on temp when the hardware doesn't support it, as such it doesn't get widely used, also since there isn't a really good mapping between acpi thermalzone stuff and the hwmon pwm interface I wouldn't add a pwm interface to a hwmon interface the the thermal zone code.
And if fan speeds aren't available (aren't they?) then I would only add a hwmon
class reference to a sysfs dir containing tempX_input's and a name atrribute
and leave it at that.
But thats just my 2 euro-cents
Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Len Brown
reviewerQuoted 5 lines · Hans de Goede
Quoted 4 lines · Rui
Hi, Hans,
On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
I think all that is really needed and asked for is for the new thermal ACPI
code to:
1) provide temp readings in the same format as hwmon (so milli degrees celcius,
not degrees celciusAgree.
/me looks for the "temp = temp * 1000" patch from Rui, as nobody disagrees that we should implement the original plan of being as hwmon compatible as possbile.
(actually, ACPI always works with 1/10th degree Kelvin internall, so someplace
it should actually be temp = temp * 100)
Quoted 33 lines
Quoted 12 lines
Quoted 11 lines
2) provide a hwmon interface so that tools like (but not limited too):
* net-snmp
* mrtg
* sensors
* sensors-applet (gnome)
* xfce-sensors-applet
* ksysguard
* ksensors
* gkrellmCan provide temp and fan readings without having to be modified.
Quoted 12 lines
hmm, for fan device, maybe something like this? pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
2+: automatic fan control (by acpi thermal driver)
pwm[1-*] = 0 : fan is off.
pwm[1-*] = 255: fan is on.
pwm[1-*] has only two valid values as ACPI fan only support two states, ON/OFF. and it doesn't need fan[1-*]_input because the fan speed is not available.
Yes, it can work for ACPI fan although I don't think the existing pwm hwmon I/F maps well to what we need and it seems like a "forced fit" to use it. Any better ideas? :)I wouldn't expose a pwm interface, doing so isn't that important as none of the above listed apps actually use it, the pwm interface really only is for people who want to manually tweak their fan speed and / or use some scripts to control the fan speed based on temp when the hardware doesn't support it, as such it doesn't get widely used, also since there isn't a really good mapping between acpi thermalzone stuff and the hwmon pwm interface I wouldn't add a pwm interface to a hwmon interface the the thermal zone code.
Quoted 3 lines
And if fan speeds aren't available (aren't they?) then I would only add a hwmon
class reference to a sysfs dir containing tempX_input's and a name atrribute
and leave it at that.
Right, ACPI doesn't supply fan speeds -- ACPI abstracts fans so that that they are just on/off. Systems that support multi-speed ACPI fans do it with with multiple logical fans to indicate the different speeds of the same physical fan.
Yeah, i know, this abstraction is distasteful to hwmon folks
who are used to talking to the real hw and knowing what it is doing. Needless to say, that simply isn't the model these system designers had in mind. The good news only laptops from hp, acer, fsc tend to implement acpi fan control. Laptops from other vendors do not, and I've never seen a desktop or server with ACPI fan control.
per the paper at the beginning of this thread, the actual focus of the new generic thermal I/F isn't ACPI fans at all. it is really being driven by upcoming systems that have no fans. Indeed, it not an "ACPI thermal I/F", for we fully intend that it to be a generic I/F that non-ACPI devices can use too.
thanks,
-Len
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 36 lines · Hans de Goede
Quoted 22 lines · Rui
Hi, Hans,
Quoted 6 lines · Hans de Goede
I think all that is really needed and asked for is for the new thermal ACPI
code to:
1) provide temp readings in the same format as hwmon (so milli degrees celcius,
not degrees celciusAgree.
Quoted 11 lines
2) provide a hwmon interface so that tools like (but not limited too):
* net-snmp
* mrtg
* sensors
* sensors-applet (gnome)
* xfce-sensors-applet
* ksysguard
* ksensors
* gkrellmCan provide temp and fan readings without having to be modified.
Quoted 12 lines
hmm, for fan device, maybe something like this? pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
2+: automatic fan control (by acpi thermal driver)
pwm[1-*] = 0 : fan is off.
pwm[1-*] = 255: fan is on.
pwm[1-*] has only two valid values as ACPI fan only support two states, ON/OFF. and it doesn't need fan[1-*]_input because the fan speed is not available.
Yes, it can work for ACPI fan although I don't think the existing pwm hwmon I/F maps well to what we need and it seems like a "forced fit" to use it. Any better ideas? :)
Quoted 2 lines
I wouldn't expose a pwm interface, doing so isn't that important as none of the above listed apps actually use it, the pwm interface really only is for people
Note: libsensors itself doesn't care about the pwm files.
Quoted 11 lines
who want to manually tweak their fan speed and / or use some scripts to control the fan speed based on temp when the hardware doesn't support it, as such it doesn't get widely used, also since there isn't a really good mapping between acpi thermalzone stuff and the hwmon pwm interface I wouldn't add a pwm interface to a hwmon interface the the thermal zone code.
And if fan speeds aren't available (aren't they?) then I would only add a hwmon
class reference to a sysfs dir containing tempX_input's and a name atrribute
and leave it at that.But thats just my 2 euro-cents
FWIW, I agree with pretty much everything Hans said.
Additionally, we could map the critical trip point to tempX_crit (read-only).
Note that since lm-sensors 3.0.1, libsensors accepts hardware monitoring attributes in the hwmon "class" device directory, and I recommend doing this so as to have a separate namespace. This will ensure that we don't get name collisions, and it makes things cleaner anyway.
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 70 lines · Jean Delvare
Quoted 6 lines · Hans de Goede
Quoted 5 lines · Rui
Hi, Hans,
Quoted 1 line · Hans de Goede
I think all that is really needed and asked for is for the new
thermal
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
ACPI
code to:
1) provide temp readings in the same format as hwmon (so millidegrees
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
celcius,
not degrees celciusAgree.
Quoted 1 line
2) provide a hwmon interface so that tools like (but not limited
too):
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
* net-snmp
* mrtg
* sensors
* sensors-applet (gnome)
* xfce-sensors-applet
* ksysguard
* ksensors
* gkrellmQuoted 8 lines
Quoted 8 lines
Quoted 1 line
Can provide temp and fan readings without having to be modified.
hmm, for fan device, maybe something like this? pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
2+: automatic fan control (by acpi thermal driver)
pwm[1-*] = 0 : fan is off.
pwm[1-*] = 255: fan is on.
pwm[1-*] has only two valid values as ACPI fan only support two states, ON/OFF. and it doesn't need fan[1-*]_input because thefan
Quoted 2 lines
Quoted 2 lines
speed is not available.
Yes, it can work for ACPI fan although I don't think the existingpwm
Quoted 1 line
Quoted 1 line
hwmon I/F maps well to what we need and it seems like a "forced
fit" to
Quoted 4 lines
Quoted 2 lines
use it. Any better ideas? :)
I wouldn't expose a pwm interface, doing so isn't that important as
none of the
Quoted 1 line
above listed apps actually use it, the pwm interface really only is
for people
Note: libsensors itself doesn't care about the pwm files.
Quoted 1 line
who want to manually tweak their fan speed and / or use some scripts
to control
Quoted 1 line
the fan speed based on temp when the hardware doesn't support it, as
such it
Quoted 1 line
doesn't get widely used, also since there isn't a really good
mapping between
Quoted 1 line
acpi thermalzone stuff and the hwmon pwm interface I wouldn't add a
pwm
Quoted 3 lines
interface to a hwmon interface the the thermal zone code.
And if fan speeds aren't available (aren't they?) then I would only
add a hwmon
Quoted 1 line
class reference to a sysfs dir containing tempX_input's and a name
atrribute
Quoted 3 lines
and leave it at that.
But thats just my 2 euro-cents
FWIW, I agree with pretty much everything Hans said.
Quoted 8 lines
Additionally, we could map the critical trip point to
tempX_crit(read-only).Note that since lm-sensors 3.0.1, libsensors accepts hardware monitoring attributes in the hwmon "class" device directory, and I recommend doing this so as to have a separate namespace. This will ensure that we don't get name collisions, and it makes things cleaner anyway.
then we'll have have duplicate attributes for temperature and critical trip point, like:/sys/class/hwmon/
|hwmon0
|---name |---temp1_input |---temp1_crit |device --->/sys/class/thermal/thermal_zone1 |---type |---temp(in millidegree Celsius) |---trip_point_0_type: critical |---trip_point_0_temp(in millidegree Celsius) ...
It's okay if we always keep these them in sync, right?
thanks,
rui
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 90 lines · Rui
Quoted 68 lines · Jean Delvare
Quoted 6 lines · Hans de Goede
Quoted 5 lines · Rui
Hi, Hans,
Quoted 1 line · Hans de Goede
I think all that is really needed and asked for is for the new
thermal
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
ACPI
code to:
1) provide temp readings in the same format as hwmon (so millidegrees
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
celcius,
not degrees celciusAgree.
Quoted 1 line
2) provide a hwmon interface so that tools like (but not limited
too):
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
* net-snmp
* mrtg
* sensors
* sensors-applet (gnome)
* xfce-sensors-applet
* ksysguard
* ksensors
* gkrellmQuoted 8 lines
Quoted 8 lines
Quoted 1 line
Can provide temp and fan readings without having to be modified.
hmm, for fan device, maybe something like this? pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
2+: automatic fan control (by acpi thermal driver)
pwm[1-*] = 0 : fan is off.
pwm[1-*] = 255: fan is on.
pwm[1-*] has only two valid values as ACPI fan only support two states, ON/OFF. and it doesn't need fan[1-*]_input because thefan
Quoted 2 lines
Quoted 2 lines
speed is not available.
Yes, it can work for ACPI fan although I don't think the existingpwm
Quoted 1 line
Quoted 1 line
hwmon I/F maps well to what we need and it seems like a "forced
fit" to
Quoted 3 lines
Quoted 2 lines
use it. Any better ideas? :)
I wouldn't expose a pwm interface, doing so isn't that important as
none of the
Quoted 1 line
above listed apps actually use it, the pwm interface really only is
for people
Note: libsensors itself doesn't care about the pwm files.
Quoted 1 line
who want to manually tweak their fan speed and / or use some scripts
to control
Quoted 1 line
the fan speed based on temp when the hardware doesn't support it, as
such it
Quoted 1 line
doesn't get widely used, also since there isn't a really good
mapping between
Quoted 1 line
acpi thermalzone stuff and the hwmon pwm interface I wouldn't add a
pwm
Quoted 3 lines
interface to a hwmon interface the the thermal zone code.
And if fan speeds aren't available (aren't they?) then I would only
add a hwmon
Quoted 1 line
class reference to a sysfs dir containing tempX_input's and a name
atrribute
Quoted 3 lines
and leave it at that.
But thats just my 2 euro-cents
FWIW, I agree with pretty much everything Hans said.
Quoted 8 lines
Additionally, we could map the critical trip point to
tempX_crit(read-only).Note that since lm-sensors 3.0.1, libsensors accepts hardware monitoring attributes in the hwmon "class" device directory, and I recommend doing this so as to have a separate namespace. This will ensure that we don't get name collisions, and it makes things cleaner anyway.
then we'll have have duplicate attributes for temperature and critical trip point, like:
/sys/class/hwmon/
|hwmon0|---name |---temp1_input |---temp1_crit |device --->/sys/class/thermal/thermal_zone1 |---type |---temp(in millidegree Celsius) |---trip_point_0_type: critical |---trip_point_0_temp(in millidegree Celsius) ...
Quoted 2 lines
It's okay if we always keep these them in sync, right?
Yes thats the whole idea, then lm_sensors using applications can get the info you add to the hwmon dir without having to learn yet another API (esp since allmost all these applications are always only reading things like temperature and maybe limits, and are not interested in the more advanced stuff.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 2 lines · Rui
pwm[1-*]_enable = 1 : manual fan control (using pwm[1-*])
2+: automatic fan control (by acpi thermal driver)
And pwm[1-*]_enable = 0 should try to bump the fan to the fasted speed possible, BTW. This is not very obvious :-)
Many hwmon devices already have a function assigned to lower values of pwm_enable. I suggest we define a static (high) value to the generic software-based kernel-mode fan controllers (of which, ACPI thermal management is the first one), so that the software-based fan-controllers can control generic fans too.
say, reserve bits 7,6 and 5 to select the fan controller class:
000 -
000 00000: disabled (fan at top speed)
000 00001: manual pwm control
000 001xx: device specific hw or sw strategies 000 01xxx: reserved for future use
000 1xxxx: reserved for future use
001 -
001 00000: ACPI thermal management controller 001 00001: (foobar thermal management controller)
...
01x - reserved for future use.
1xx - reserved for future use.
Or something like that. Note that the above is, AFAIK, fully backwards compatible with all current hwmon devices.
Quoted 3 lines
Yes, it can work for ACPI fan although I don't think the existing pwm hwmon I/F maps well to what we need and it seems like a "forced fit" to use it. Any better ideas? :)
Sure: we add a new "view" of the pwm controller. hwmon drivers are allowed to export either one or both. If they export both, however, they MUST be kept in complete sync. Most hwmon devices will export either, but not both. Stuff like thinkpad-acpi that is already complex enough anyway, can go through the pain of providing both and keeping them in sync.
The new "view" could well use the ACPI thermal management idea, which is nicely generic (if a bit less powerful) than hwmon's current view, and you could very easily convert the current thermal management stuff to it. Here's a proposal:
pwm[1-*]_max_level (RO):
Maximum valid level for pwm[1-*]_level
pwm[1-*]_level (RO/RW):
Alternate view of pwm[1-*]. 0 means off. 1-pwm[1-*]_max_level means active. The higher the level, the higher the speed.
However, that would only make sense for fans. Using the pwm model to control generic cooling properties of devices doesn't work well.
I propose we add an alternate "cooling power" set of attributes. Fans could use either one, or even both (as long as they are kept in sync):
cooling_mode (RO/RW):
0 = disabled (no extra cooling effort)
1 = manual
2.. (same as pwm_enable)
Note that this does NOT have the same behaviour of pwm_enable=0!
cooling[1-*]_max_level (RO):
maximum cooling effort level available
cooling[1-*]_level (RW/RO):
0 = no extra cooling
1 = cooling effort level 1
...
Increasing the cooling effort level, increases the cooling effect of the device (might mean downclocking buses at higher levels, etc).
I propose this, because it is actually a damn nice way to deal with fans in most Linux platforms, as they are used only for cooling. It has clearly conceptual advantages over the pwm model we have right now. And it could be easily used by the ACPI thermal management stuff.
Signature · 9 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Len Brown
reviewerQuoted 3 lines
Agreed. However, *duplicating* what is already in hwmon elsewhere is not fun. Please reconsider.
I started off with the same position as you, Henrique, but Rui and Sujith don't see it that way.
Of course this is software, we can always change it -- particularly since there will be a very small list of users for the new I/F, and we happen to know them:-)
Quoted 3 lines
I'd like to see passive cooling (heck, the entire
ACPI v3.0 thermal model, if needed) added to hwmon, that will enhance hwmon to be even more generic, and we all benefit from that.
The ACPI 3.0 thermal model requires quite a bit of sophistication from the system designer and BIOS writer.
Based on the quality of system designs and BIOS code we see in the industry, I think it is way over the head of 99% of the industry.
That said, if a system does come out that supports the ACPI 3.0 Thermal Model and they want to ship Linux on it, we can look into it then.
cheers,
-Len
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors