> -----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; linux-acpi@vger.kernel.org; [EMAIL PROTECTED]; > 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 <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
