The new thermal management sysfs class, and hwmon

The new thermal management sysfs class, and hwmon

[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.

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?

-- 
  "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

Re: The new thermal management sysfs class, and hwmon

[Zhang Rui]

Hi, henrique,

On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh wrote:
> 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/

> 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.
> 
> 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

Re: The new thermal management sysfs class, and hwmon

[Mark M. Hoffman]

Hi:

> On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh wrote:
> > 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.

* Zhang Rui <rui.zhang@intel.com> [2008-02-03 17:31:12 +0800]:
> 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.

> > 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.

> > 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?

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,

-- 
Mark M. Hoffman
mhoffman@lightlink.com


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: The new thermal management sysfs class, and hwmon

[Henrique de Moraes Holschuh]

On Sun, 03 Feb 2008, Mark M. Hoffman wrote:
> * Zhang Rui <rui.zhang@intel.com> [2008-02-03 17:31:12 +0800]:
> > On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh wrote:
> > > 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.

> > > 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?
> 
> 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.

> 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.

> 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 :-)

-- 
  "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

RE: The new thermal management sysfs class, and hwmon

[Thomas, Sujith]

> -----Original Message-----
> From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> Sent: Sunday, February 03, 2008 11:20 PM
> To: Mark M. Hoffman
> Cc: Zhang, Rui; linux-acpi@vger.kernel.org; lm-sensors@lm-sensors.org;
> Jean Delvare; Len Brown; Thomas, Sujith
> Subject: Re: The new thermal management sysfs class, and hwmon
> 
> On Sun, 03 Feb 2008, Mark M. Hoffman wrote:
> > * Zhang Rui <rui.zhang@intel.com> [2008-02-03 17:31:12 +0800]:
> > > On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh
wrote:
> > > > 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.
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.
> 
> > > > 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?
> >
> > 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.
> 
> > 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.
> 
> > 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 :-)
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
> 
> --
>   "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

Re: The new thermal management sysfs class, and hwmon

[Mark M. Hoffman]

Hi:

(btw: Please use an email client that doesn't completely butcher the
text to which you're replying.  Thanks.)

> > > > On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh
> > > > wrote:
> > > > > 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.

> > > * Zhang Rui <rui.zhang@intel.com> [2008-02-03 17:31:12 +0800]:
> > > > 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 <hmh@hmh.eng.br>:
> > 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.

* Thomas, Sujith <sujith.thomas@intel.com> [2008-02-05 15:44:19 +0530]:
> 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.

> 2) It is missing interfaces for passive device control.(CPU- T
> states,LCD,Memory controller, etc..)

Ditto.

> 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.

> 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?

> 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.

> 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>

* Thomas, Sujith <sujith.thomas@intel.com> [2008-02-05 15:44:19 +0530]:
> 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.

> 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,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Henrique de Moraes Holschuh]

On Tue, 05 Feb 2008, Mark M. Hoffman wrote:
> * Henrique de Moraes Holschuh <hmh@hmh.eng.br>:
> > > 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.

> 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.

> > 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.

> * Thomas, Sujith <sujith.thomas@intel.com> [2008-02-05 15:44:19 +0530]:
> > 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.

> > 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 :-(

-- 
  "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

RE: The new thermal management sysfs class, and hwmon

[Thomas, Sujith]

> -----Original Message-----
> From: Mark M. Hoffman [mailto:mhoffman@lightlink.com]
> Sent: Tuesday, February 05, 2008 7:27 PM
> To: Thomas, Sujith
> Cc: Henrique de Moraes Holschuh; Zhang, Rui;
linux-acpi@vger.kernel.org; lm-
> sensors@lm-sensors.org; Jean Delvare; Len Brown
> Subject: Re: The new thermal management sysfs class, and hwmon
> 
> Hi:
> 
> (btw: Please use an email client that doesn't completely butcher the
> text to which you're replying.  Thanks.)
> 
> > > > > On Sun, 2008-02-03 at 10:26 +0800, Henrique de Moraes Holschuh
> > > > > wrote:
> > > > > > 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.
> 
> > > > * Zhang Rui <rui.zhang@intel.com> [2008-02-03 17:31:12 +0800]:
> > > > > 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 <hmh@hmh.eng.br>:
> > > 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.
> 
> * Thomas, Sujith <sujith.thomas@intel.com> [2008-02-05 15:44:19
+0530]:
> > 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.
> 
> > 2) It is missing interfaces for passive device control.(CPU- T
> > states,LCD,Memory controller, etc..)
> 
> Ditto.
> 
> > 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.
> 
> > 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?
> 
> > 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.
> 
> > 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>
> 
> * Thomas, Sujith <sujith.thomas@intel.com> [2008-02-05 15:44:19
+0530]:
> > 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.
> 
> > 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".
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
> 
> 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,
> 
> --
> Mark M. Hoffman
> mhoffman@lightlink.com

Re: The new thermal management sysfs class, and hwmon

[Len Brown]

> 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:-)

> 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

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Len Brown]

On Tuesday 05 February 2008 09:55, Henrique de Moraes Holschuh wrote:

> > > 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 :-(

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

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Henrique de Moraes Holschuh]

On Thu, 07 Feb 2008, Len Brown wrote:
> On Tuesday 05 February 2008 09:55, Henrique de Moraes Holschuh wrote:
> > > > 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 :-(
> 
> 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.

> 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.

> 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 :(

-- 
  "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

RE: The new thermal management sysfs class, and hwmon

[Thomas Renninger]

On Wed, 2008-02-06 at 10:53 +0530, Thomas, Sujith wrote:
...

> 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

Re: The new thermal management sysfs class, and hwmon

[Matthew Garrett]

On Wed, Feb 13, 2008 at 04:10:50PM +0100, Thomas Renninger wrote:

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

RE: The new thermal management sysfs class, and hwmon

[Thomas, Sujith]

> On Wed, Feb 13, 2008 at 04:10:50PM +0100, Thomas Renninger wrote:
> 
> > 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.
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
> 
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org

Re: The new thermal management sysfs class, and hwmon

[Matthew Garrett]

On Fri, Feb 15, 2008 at 04:34:34PM +0530, Thomas, Sujith wrote:

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Henrique de Moraes Holschuh]

On Fri, 15 Feb 2008, Matthew Garrett wrote:
> On Fri, Feb 15, 2008 at 04:34:34PM +0530, Thomas, Sujith wrote:
> > 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.

-- 
  "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

Re: The new thermal management sysfs class, and hwmon

[zhangrui]

Hi, all,

Sorry for the late response as I'm on the Chinese New Year vacation.

On Thu, 2008-02-14 at 22:08 +0800, Matthew Garrett wrote:
> On Wed, Feb 13, 2008 at 04:10:50PM +0100, Thomas Renninger wrote:
> 
> > 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.
> 

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:                0

The 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

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Hans de Goede]

zhangrui wrote:
> Hi, all,
> 
> Sorry for the late response as I'm on the Chinese New Year vacation.
> 
> On Thu, 2008-02-14 at 22:08 +0800, Matthew Garrett wrote:
>> On Wed, Feb 13, 2008 at 04:10:50PM +0100, Thomas Renninger wrote:
>>
>>> 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.
>>
> 
> 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:                0
> 
> The 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. ;)
> 

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)

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Zhang, Rui]

Hi, Hans,

On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:

> 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.
> 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.
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

> 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

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Hans de Goede]

Zhang, Rui wrote:
> Hi, Hans,
> 
> On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:
> 
>> 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.
>> 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.
> 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

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Len Brown]

On Friday 22 February 2008 05:54, Hans de Goede wrote:
> Zhang, Rui wrote:
> > Hi, Hans,
> > 
> > On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:
> > 
> >> 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.

/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)

> >> 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.

> > 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.

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

Re: The new thermal management sysfs class, and hwmon

[Jean Delvare]

On Fri, 22 Feb 2008 11:54:06 +0100, Hans de Goede wrote:
> Zhang, Rui wrote:
> > Hi, Hans,
> > 
> > On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:
> > 
> >> 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.
> >> 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.
> > 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 

Note: libsensors itself doesn't care about the pwm files.

> 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.

-- 
Jean Delvare

Re: [lm-sensors] The new thermal management sysfs class, and hwmon

[Henrique de Moraes Holschuh]

On Fri, 22 Feb 2008, Zhang, Rui wrote:
> 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.

> 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.

-- 
  "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

Re: The new thermal management sysfs class, and hwmon

[Zhang, Rui]

On Sat, 2008-02-23 at 16:29 +0800, Jean Delvare wrote:
> On Fri, 22 Feb 2008 11:54:06 +0100, Hans de Goede wrote:
> > Zhang, Rui wrote:
> > > Hi, Hans,
> > >
> > > On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:
> > >
> > >> 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.
> > >> 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.
> > > 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
> 
> Note: libsensors itself doesn't care about the pwm files.
> 
> > 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.
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

Re: The new thermal management sysfs class, and hwmon

[Hans de Goede]

Zhang, Rui wrote:
> On Sat, 2008-02-23 at 16:29 +0800, Jean Delvare wrote:
>> On Fri, 22 Feb 2008 11:54:06 +0100, Hans de Goede wrote:
>>> Zhang, Rui wrote:
>>>> Hi, Hans,
>>>>
>>>> On Fri, 2008-02-22 at 16:00 +0800, Hans de Goede wrote:
>>>>
>>>>> 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.
>>>>> 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.
>>>> 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
>>
>> Note: libsensors itself doesn't care about the pwm files.
>>
>>> 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.
> 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?
> 

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