About thermal framework

In Linux kernel, so far, the thermal sensor drivers under 'drivers/hwmon' have their own way to sample temperature and report to the rest of the kernel or user space. This situation makes thermal information collection difficult. Intel's thermal framework (reffed as 'thermal framework' later) is there for years and it is well documented under Documentation/thermal. However, all the thermal drivers under hwmon don't make use of it due to some reasons. We like to find out a simple and unified way to expose thermal related information, intel's thermal framework could be a choice. Here, we promote using this framework until a better one comes out.

Exposing thermal information to user space

To acheive a unified interface and location, it is better to use thermal framework, thus all the information go to sysfs under /sys/class/thermal. For example, to report temperature to user space, simple add below code in your driver.

#include <linux/module.h>

#include <linux/device.h>

#include <linux/thermal.h>

static int thermal_get_temp(struct thermal_zone_device *thermal, unsigned long *temp)

{

  • temp = 100;
  • return 0;

}

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);

With thermal information available at a common place, user space applications like power policy manager can easily find out it and use it.

Cooperate with other kernel modules

kernel interface

Normally, any thermal sensors may want to register themselves as a 'thermal zone' device. Other modules can appear as a cooling device although they don't have to be a real one, and register themselves as a cooling device. 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, therefore leaving other modules a chance to response thermal information update.thermal_zone_device_register

thermal_zone_device_unregister

thermal_colling_device_register

thermal_cooling_device_unregister

thermal_zone_bind_cooling_device

thermal_zone_unbind_cooling_device

thermal_zone_unbind_cooling_device

thermal_zone_device_update

How to bind a cooling device to a thermal device

Like code of how to export thermal information to sysfs, for every thermal device this a thermal_zone_device_ops, like:

static thermal_zone_device_ops xxx = {

  • bind = xxx_bind(struct thermal_zone_device *thermal, struct thermal_cooling_device *cdev),

....

}

This is the place where binding actually happens. For each thermal device, once it is registered, it will try to bind possible cooling device using this xxx_bind operation. And normally, xxx_bind goes like this:

xxx_bind(struct thermal_zone_device *thermal, struct thermal_cooling_device *cdev)

{

  • /*first do some checking about parameters passed in*/
  • ...
  • /*find out the matched cooling device*/
  • ...
  • /*do actually binding*/
  • thermal_zone_bind_cooling_device(thermal, trip, cdev);

}

All the binding cooling device to a thermal one will be called to operate on certain thermal events, which is the basic way of how thermal and cooling device cooperate.

WorkingGroups/PowerManagement/Doc/ThermalFramework (last modified 2012-02-14 22:28:35)