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)
