RE: The new thermal management sysfs class, and hwmon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Henrique de Moraes Holschuh [mailto:hmh@xxxxxxxxxx]
> Sent: Sunday, February 03, 2008 11:20 PM
> To: Mark M. Hoffman
> Cc: Zhang, Rui; linux-acpi@xxxxxxxxxxxxxxx; lm-sensors@xxxxxxxxxxxxxx;
> 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@xxxxxxxxx> [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
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux