Introduce thermal consideration in cpufreq decisions

Registered by Amit Kucheria

Add thermal constraints to cpufreq to prevent overheating of system

Blueprint information

Status:
Complete
Approver:
Amit Kucheria
Priority:
Medium
Drafter:
Amit Kucheria
Direction:
Approved
Assignee:
Yong
Definition:
Approved
Series goal:
Accepted for 11.05
Implementation:
Implemented
Milestone target:
milestone icon 11.05-03
Started by
Amit Kucheria
Completed by
Amit Kucheria

Related branches

Sprints

Whiteboard

[amitk: 2/11/2010]
 * At LDS, it was unanimously agreed that tying thermal events to cpufreq wasn't desirable and that cpufreq was just one of many responses that might be taken in response to thermal overload. Others can be cpu hotplugging, restricting cpuidle states, etc.
 * Hence we will ensure that the output of the thermal sensors is available in a consistent way
 * It is then the job of the policy manager to determine what to do in case of thermal overload

[Earlier Discussion]
We need to take into account the thermal characteristics of the system for our frequency scaling decisions. If the system is too hot, we shouldn't scale up the frequency. There can be several ways to make cpufreq thermal-aware:
1. A thermal driver that sets a contraint using something similar to PM_QOS. The cpufreq driver is then made aware of these constraints
2. Add generic thermal-awareness to cpufreq. This needs the thermal API to be agreed upon.
3. Making the thermal driver affect cpufreq policy to restrict certain operating points.

Existing code in Linux related to thermal measurement:
 - hwmon class: drivers/hwmon/*
 - Thermal class: drivers/thermal/*
 - Intel Intelligent Power Sharing driver: drivers/platform/x86/intel_ips.c
 - driver/hwmon/coretemp.c
 - driver/hwmon/pkgtemp.c

After looking into the thermal framework, some basic ideas have come out:
1. Current existed framework drivers/thermal and drivers/cpufreq are enough to perform the task which is to let cpufreq driver be aware of runtime thermal condition.
2. Linux thermal framework enables a thermal sensor driver to polling its status periodically and in the meantime to update its binded cooling device to action on the real time temperature.
3. Cpufreq driver can register itself as a cooling device and update its own policy limitations according to the thermal framework's report.

Status:
In Progress

(?)

Work Items

Work items:
[yong.shen] study thermal frameworks which exist already: DONE
[yong.shen] work out a draft design to discuss within PM work group: DONE
[yong.shen] how are boards currently exposing thermal information - hwmon drivers, other interfaces?: DONE
[yong.shen] teach powerdebug about all the interfaces providing thermal info: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.