> -----Original Message----- > From: Mark M. Hoffman [mailto:mhoffman@xxxxxxxxxxxxx] > Sent: Tuesday, February 05, 2008 7:27 PM > To: Thomas, Sujith > Cc: Henrique de Moraes Holschuh; Zhang, Rui; linux-acpi@xxxxxxxxxxxxxxx; lm- > sensors@xxxxxxxxxxxxxx; 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@xxxxxxxxx> [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@xxxxxxxxxx>: > > > 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@xxxxxxxxx> [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@xxxxxxxxx> [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@xxxxxxxxxxxxx - 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
