linaro-pm-wg team mailing list archive

[Amit Kucheria <amit.kucheria@xxxxxxxxxxxxx>]

Blueprint changed by Amit Kucheria:

Whiteboard changed:
  [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:
  [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
- [yong.shen] port a sample hwmon driver to use thermal framework: POSTPONED

-- 
Introduce thermal consideration in cpufreq decisions
https://blueprints.launchpad.net/linaro-pm-wg/+spec/cpufreq-thermal-management