Hi there,
In power management group, we have a working item of exposing thermal information to user space through sysfs. However, so far, the thermal sensor drivers under 'drivers/hwmon' expose their information in various nodes under sysfs, which makes information collection difficult. Intel's thermal framework is located under 'drivers/thermal', but all the thermal drivers under hwmon don't make use of it due to some reason (part of the reason for this situation may be that intel's thermal framework is comparatively new therefore when those sensor drivers were implemented they did not have a framework to register themselves.) We like to find out a simple and unified way to expose thermal related information, intel's thermal interface could be a choice. Using thermal framework is straightforward, below is a sample driver for this purpose. Thus all the information goes to /sys/class/thermal, like temperature, mode...
... #include <linux/module.h> #include <linux/device.h> #include <linux/thermal.h> #include <linux/hwmon.h> static int thermal_get_temp(struct thermal_zone_device *thermal, unsigned long *temp) { *temp = xxx; return 0; } static struct device *hwmon; static struct thermal_zone_device *thermal; static struct thermal_zone_device_ops ops = { .get_temp = thermal_get_temp, }; static int __init sensor_init(void) { ... thermal = thermal_zone_device_register("sample", 0, 0, &ops, 0, 0, 0, 0); } static void __exit sensor_cleanup(void) { ... } module_init(sensor_init); module_exit(sensor_cleanup);
Are there any better ideas about this? Your comments are highly appreciated.
Yong
On 10 Nov 24, Yong Shen wrote:
Hi there,
In power management group, we have a working item of exposing thermal information to user space through sysfs. However, so far, the thermal sensor drivers under 'drivers/hwmon' expose their information in various nodes under sysfs, which makes information collection difficult. Intel's thermal framework is located under 'drivers/thermal', but all the thermal drivers under hwmon don't make use of it due to some reason (part of the reason for this situation may be that intel's thermal framework is comparatively new therefore when those sensor drivers were implemented they did not have a framework to register themselves.)
It is not that new (after checking)
$ git describe 203d3d4aa482339b4816f131f713e1b8ee37f6dd v2.6.24-6482-g203d3d4
We like to find out a simple and unified way to expose thermal related information, intel's thermal interface could be a choice. Using thermal framework is straightforward, below is a sample driver for this purpose. Thus all the information goes to /sys/class/thermal, like temperature, mode...
... #include <linux/module.h> #include <linux/device.h> #include <linux/thermal.h> #include <linux/hwmon.h> static int thermal_get_temp(struct thermal_zone_device *thermal, unsigned long *temp) { *temp = xxx; return 0; } static struct device *hwmon; static struct thermal_zone_device *thermal; static struct thermal_zone_device_ops ops = { .get_temp = thermal_get_temp, }; static int __init sensor_init(void) { ... thermal = thermal_zone_device_register("sample", 0, 0, &ops, 0, 0, 0, 0); } static void __exit sensor_cleanup(void) { ... } module_init(sensor_init); module_exit(sensor_cleanup);
Are there any better ideas about this? Your comments are highly appreciated.
What is important is not just a user-space interface (in /sys), but also a in-kernel interface that drivers can call.
I had a brief look at the thermal API. There are two types of devices: * Thermal Zone (a sensor) * Cooling device (fan, processor, perhaps even a policy manager?)
You can bind cooling devices with thermal zones.
Can the thermal_zone_bind_cooling_device() function be used by external drivers for registering call-backs for thermal trip conditions?
/Amit
On Wed, Nov 24, 2010 at 7:02 PM, Amit Kucheria amit.kucheria@linaro.org wrote:
On 10 Nov 24, Yong Shen wrote:
Hi there,
In power management group, we have a working item of exposing thermal information to user space through sysfs. However, so far, the thermal sensor drivers under 'drivers/hwmon' expose their information in various nodes under sysfs, which makes information collection difficult. Intel's thermal framework is located under 'drivers/thermal', but all the thermal drivers under hwmon don't make use of it due to some reason (part of the reason for this situation may be that intel's thermal framework is comparatively new therefore when those sensor drivers were implemented they did not have a framework to register themselves.)
It is not that new (after checking)
$ git describe 203d3d4aa482339b4816f131f713e1b8ee37f6dd v2.6.24-6482-g203d3d4
I meant it is newer than drivers/hwmon which was first introduced in 2005, while drivers/thermal was introduced in 2008.
We like to find out a simple and unified way to expose thermal related information, intel's thermal interface could be a choice. Using thermal framework is straightforward, below is a sample driver for this purpose. Thus all the information goes to /sys/class/thermal, like temperature, mode...
... #include <linux/module.h> #include <linux/device.h> #include <linux/thermal.h> #include <linux/hwmon.h> static int thermal_get_temp(struct thermal_zone_device *thermal, unsigned long *temp) { *temp = xxx; return 0; } static struct device *hwmon; static struct thermal_zone_device *thermal; static struct thermal_zone_device_ops ops = { .get_temp = thermal_get_temp, }; static int __init sensor_init(void) { ... thermal = thermal_zone_device_register("sample", 0, 0, &ops, 0, 0, 0, 0); } static void __exit sensor_cleanup(void) { ... } module_init(sensor_init); module_exit(sensor_cleanup);
Are there any better ideas about this? Your comments are highly appreciated.
What is important is not just a user-space interface (in /sys), but also a in-kernel interface that drivers can call.
I had a brief look at the thermal API. There are two types of devices: * Thermal Zone (a sensor) * Cooling device (fan, processor, perhaps even a policy manager?)
You can bind cooling devices with thermal zones.
Can the thermal_zone_bind_cooling_device() function be used by external drivers for registering call-backs for thermal trip conditions?
Yes. If I understand right, you also want to let this thermal framework communicate directly with other kernel modules or drivers. In this case, other modules can appear as a cooling device although they don't have to be a real one, and register themselves with a thermal_cooling_device_ops. When thermal zone device updates its status, it will go through all the trip points and invoke related binding cooling devices to set their states (ops->set_cur_state). Correct me.
/Amit
On 10 Nov 25, Yong Shen wrote:
On Wed, Nov 24, 2010 at 7:02 PM, Amit Kucheria amit.kucheria@linaro.org wrote:
On 10 Nov 24, Yong Shen wrote:
Hi there,
In power management group, we have a working item of exposing thermal information to user space through sysfs. However, so far, the thermal sensor drivers under 'drivers/hwmon' expose their information in various nodes under sysfs, which makes information collection difficult. Intel's thermal framework is located under 'drivers/thermal', but all the thermal drivers under hwmon don't make use of it due to some reason (part of the reason for this situation may be that intel's thermal framework is comparatively new therefore when those sensor drivers were implemented they did not have a framework to register themselves.)
It is not that new (after checking)
$ git describe 203d3d4aa482339b4816f131f713e1b8ee37f6dd v2.6.24-6482-g203d3d4
I meant it is newer than drivers/hwmon which was first introduced in 2005, while drivers/thermal was introduced in 2008.
We like to find out a simple and unified way to expose thermal related information, intel's thermal interface could be a choice. Using thermal framework is straightforward, below is a sample driver for this purpose. Thus all the information goes to /sys/class/thermal, like temperature, mode...
... #include <linux/module.h> #include <linux/device.h> #include <linux/thermal.h> #include <linux/hwmon.h> static int thermal_get_temp(struct thermal_zone_device *thermal, unsigned long *temp) { *temp = xxx; return 0; } static struct device *hwmon; static struct thermal_zone_device *thermal; static struct thermal_zone_device_ops ops = { .get_temp = thermal_get_temp, }; static int __init sensor_init(void) { ... thermal = thermal_zone_device_register("sample", 0, 0, &ops, 0, 0, 0, 0); } static void __exit sensor_cleanup(void) { ... } module_init(sensor_init); module_exit(sensor_cleanup);
Are there any better ideas about this? Your comments are highly appreciated.
What is important is not just a user-space interface (in /sys), but also a in-kernel interface that drivers can call.
I had a brief look at the thermal API. There are two types of devices: * Thermal Zone (a sensor) * Cooling device (fan, processor, perhaps even a policy manager?)
You can bind cooling devices with thermal zones.
Can the thermal_zone_bind_cooling_device() function be used by external drivers for registering call-backs for thermal trip conditions?
Yes. If I understand right, you also want to let this thermal framework communicate directly with other kernel modules or drivers. In this case, other modules can appear as a cooling device although they don't have to be a real one, and register themselves with a thermal_cooling_device_ops. When thermal zone device updates its status, it will go through all the trip points and invoke related binding cooling devices to set their states (ops->set_cur_state). Correct me.
Yes that is the possibility I'm thinking of. Now the question to ask the various SoC vendors is, is that the interface they'd prefer?
Kevin, any thoughts?
/Amit
-
Amit Kucheria -
Yong Shen