2008-01-17 14:51:08 +07:00
|
|
|
Generic Thermal Sysfs driver How To
|
2009-10-26 14:38:59 +07:00
|
|
|
===================================
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
Written by Sujith Thomas <sujith.thomas@intel.com>, Zhang Rui <rui.zhang@intel.com>
|
|
|
|
|
|
|
|
Updated: 2 January 2008
|
|
|
|
|
|
|
|
Copyright (c) 2008 Intel Corporation
|
|
|
|
|
|
|
|
|
|
|
|
0. Introduction
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
The generic thermal sysfs provides a set of interfaces for thermal zone
|
|
|
|
devices (sensors) and thermal cooling devices (fan, processor...) to register
|
|
|
|
with the thermal management solution and to be a part of it.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
This how-to focuses on enabling new thermal zone and cooling devices to
|
|
|
|
participate in thermal management.
|
|
|
|
This solution is platform independent and any type of thermal zone devices
|
|
|
|
and cooling devices should be able to make use of the infrastructure.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
The main task of the thermal sysfs driver is to expose thermal zone attributes
|
|
|
|
as well as cooling device attributes to the user space.
|
|
|
|
An intelligent thermal management application can make decisions based on
|
|
|
|
inputs from thermal zone attributes (the current temperature and trip point
|
|
|
|
temperature) and throttle appropriate devices.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
[0-*] denotes any positive number starting from 0
|
|
|
|
[1-*] denotes any positive number starting from 1
|
|
|
|
|
|
|
|
1. thermal sysfs driver interface functions
|
|
|
|
|
|
|
|
1.1 thermal zone device interface
|
2013-04-24 23:59:22 +07:00
|
|
|
1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *type,
|
2012-07-25 09:10:58 +07:00
|
|
|
int trips, int mask, void *devdata,
|
2013-04-24 23:59:22 +07:00
|
|
|
struct thermal_zone_device_ops *ops,
|
|
|
|
const struct thermal_zone_params *tzp,
|
|
|
|
int passive_delay, int polling_delay))
|
2009-10-26 14:38:59 +07:00
|
|
|
|
|
|
|
This interface function adds a new thermal zone device (sensor) to
|
|
|
|
/sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the
|
|
|
|
thermal cooling devices registered at the same time.
|
|
|
|
|
2013-04-24 23:59:22 +07:00
|
|
|
type: the thermal zone type.
|
2009-10-26 14:38:59 +07:00
|
|
|
trips: the total number of trip points this thermal zone supports.
|
2012-07-25 09:10:58 +07:00
|
|
|
mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
|
2009-10-26 14:38:59 +07:00
|
|
|
devdata: device private data
|
|
|
|
ops: thermal zone device call-backs.
|
|
|
|
.bind: bind the thermal zone device with a thermal cooling device.
|
|
|
|
.unbind: unbind the thermal zone device with a thermal cooling device.
|
|
|
|
.get_temp: get the current temperature of the thermal zone.
|
2012-07-25 09:11:00 +07:00
|
|
|
.get_mode: get the current mode (enabled/disabled) of the thermal zone.
|
|
|
|
- "enabled" means the kernel thermal management is enabled.
|
|
|
|
- "disabled" will prevent kernel thermal driver action upon trip points
|
2009-10-26 14:38:59 +07:00
|
|
|
so that user applications can take charge of thermal management.
|
2012-07-25 09:11:00 +07:00
|
|
|
.set_mode: set the mode (enabled/disabled) of the thermal zone.
|
2009-10-26 14:38:59 +07:00
|
|
|
.get_trip_type: get the type of certain trip point.
|
|
|
|
.get_trip_temp: get the temperature above which the certain trip point
|
|
|
|
will be fired.
|
2013-02-04 07:30:15 +07:00
|
|
|
.set_emul_temp: set the emulation temperature which helps in debugging
|
|
|
|
different threshold temperature points.
|
2013-04-24 23:59:22 +07:00
|
|
|
tzp: thermal zone platform parameters.
|
|
|
|
passive_delay: number of milliseconds to wait between polls when
|
|
|
|
performing passive cooling.
|
|
|
|
polling_delay: number of milliseconds to wait between polls when checking
|
|
|
|
whether trip points have been crossed (0 for interrupt driven systems).
|
|
|
|
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
This interface function removes the thermal zone device.
|
|
|
|
It deletes the corresponding entry form /sys/class/thermal folder and
|
|
|
|
unbind all the thermal cooling devices it uses.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
1.2 thermal cooling device interface
|
|
|
|
1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name,
|
2009-10-26 14:38:59 +07:00
|
|
|
void *devdata, struct thermal_cooling_device_ops *)
|
|
|
|
|
|
|
|
This interface function adds a new thermal cooling device (fan/processor/...)
|
|
|
|
to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
|
|
|
|
to all the thermal zone devices register at the same time.
|
|
|
|
name: the cooling device name.
|
|
|
|
devdata: device private data.
|
|
|
|
ops: thermal cooling devices call-backs.
|
|
|
|
.get_max_state: get the Maximum throttle state of the cooling device.
|
|
|
|
.get_cur_state: get the Current throttle state of the cooling device.
|
|
|
|
.set_cur_state: set the Current throttle state of the cooling device.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
1.2.2 void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
This interface function remove the thermal cooling device.
|
|
|
|
It deletes the corresponding entry form /sys/class/thermal folder and
|
|
|
|
unbind itself from all the thermal zone devices using it.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
1.3 interface for binding a thermal zone device with a thermal cooling device
|
|
|
|
1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
|
2012-06-26 15:35:57 +07:00
|
|
|
int trip, struct thermal_cooling_device *cdev,
|
|
|
|
unsigned long upper, unsigned long lower);
|
2008-01-17 14:51:08 +07:00
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
This interface function bind a thermal cooling device to the certain trip
|
|
|
|
point of a thermal zone device.
|
|
|
|
This function is usually called in the thermal zone device .bind callback.
|
|
|
|
tz: the thermal zone device
|
|
|
|
cdev: thermal cooling device
|
|
|
|
trip: indicates which trip point the cooling devices is associated with
|
|
|
|
in this thermal zone.
|
2012-06-26 15:35:57 +07:00
|
|
|
upper:the Maximum cooling state for this trip point.
|
|
|
|
THERMAL_NO_LIMIT means no upper limit,
|
|
|
|
and the cooling device can be in max_state.
|
|
|
|
lower:the Minimum cooling state can be used for this trip point.
|
|
|
|
THERMAL_NO_LIMIT means no lower limit,
|
|
|
|
and the cooling device can be in cooling state 0.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
|
2009-10-26 14:38:59 +07:00
|
|
|
int trip, struct thermal_cooling_device *cdev);
|
2008-01-17 14:51:08 +07:00
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
This interface function unbind a thermal cooling device from the certain
|
|
|
|
trip point of a thermal zone device. This function is usually called in
|
|
|
|
the thermal zone device .unbind callback.
|
|
|
|
tz: the thermal zone device
|
|
|
|
cdev: thermal cooling device
|
|
|
|
trip: indicates which trip point the cooling devices is associated with
|
|
|
|
in this thermal zone.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
2012-09-18 12:35:06 +07:00
|
|
|
1.4 Thermal Zone Parameters
|
|
|
|
1.4.1 struct thermal_bind_params
|
|
|
|
This structure defines the following parameters that are used to bind
|
|
|
|
a zone with a cooling device for a particular trip point.
|
|
|
|
.cdev: The cooling device pointer
|
|
|
|
.weight: The 'influence' of a particular cooling device on this zone.
|
|
|
|
This is on a percentage scale. The sum of all these weights
|
|
|
|
(for a particular zone) cannot exceed 100.
|
|
|
|
.trip_mask:This is a bit mask that gives the binding relation between
|
|
|
|
this thermal zone and cdev, for a particular trip point.
|
|
|
|
If nth bit is set, then the cdev and thermal zone are bound
|
|
|
|
for trip point n.
|
2013-07-17 02:26:28 +07:00
|
|
|
.limits: This is an array of cooling state limits. Must have exactly
|
|
|
|
2 * thermal_zone.number_of_trip_points. It is an array consisting
|
|
|
|
of tuples <lower-state upper-state> of state limits. Each trip
|
|
|
|
will be associated with one state limit tuple when binding.
|
|
|
|
A NULL pointer means <THERMAL_NO_LIMITS THERMAL_NO_LIMITS>
|
|
|
|
on all trips. These limits are used when binding a cdev to a
|
|
|
|
trip point.
|
2012-09-18 12:35:06 +07:00
|
|
|
.match: This call back returns success(0) if the 'tz and cdev' need to
|
|
|
|
be bound, as per platform data.
|
|
|
|
1.4.2 struct thermal_zone_params
|
|
|
|
This structure defines the platform level parameters for a thermal zone.
|
|
|
|
This data, for each thermal zone should come from the platform layer.
|
|
|
|
This is an optional feature where some platforms can choose not to
|
|
|
|
provide this data.
|
|
|
|
.governor_name: Name of the thermal governor used for this zone
|
2013-08-15 22:34:17 +07:00
|
|
|
.no_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface
|
|
|
|
is required. when no_hwmon == false, a hwmon sysfs interface
|
|
|
|
will be created. when no_hwmon == true, nothing will be done.
|
|
|
|
In case the thermal_zone_params is NULL, the hwmon interface
|
|
|
|
will be created (for backward compatibility).
|
2012-09-18 12:35:06 +07:00
|
|
|
.num_tbps: Number of thermal_bind_params entries for this zone
|
|
|
|
.tbp: thermal_bind_params entries
|
|
|
|
|
2008-01-17 14:51:08 +07:00
|
|
|
2. sysfs attributes structure
|
|
|
|
|
|
|
|
RO read only value
|
|
|
|
RW read/write value
|
|
|
|
|
2008-04-22 07:50:09 +07:00
|
|
|
Thermal sysfs attributes will be represented under /sys/class/thermal.
|
|
|
|
Hwmon sysfs I/F extension is also available under /sys/class/hwmon
|
|
|
|
if hwmon is compiled in or built as a module.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
Thermal zone device sys I/F, created once it's registered:
|
2008-04-22 07:50:09 +07:00
|
|
|
/sys/class/thermal/thermal_zone[0-*]:
|
2009-10-26 14:38:59 +07:00
|
|
|
|---type: Type of the thermal zone
|
|
|
|
|---temp: Current temperature
|
|
|
|
|---mode: Working mode of the thermal zone
|
2012-09-18 12:35:06 +07:00
|
|
|
|---policy: Thermal governor used for this zone
|
2009-10-26 14:38:59 +07:00
|
|
|
|---trip_point_[0-*]_temp: Trip point temperature
|
|
|
|
|---trip_point_[0-*]_type: Trip point type
|
2012-07-25 09:10:59 +07:00
|
|
|
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
|
2013-02-04 07:30:15 +07:00
|
|
|
|---emul_temp: Emulated temperature set node
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
Thermal cooling device sys I/F, created once it's registered:
|
2008-04-22 07:50:09 +07:00
|
|
|
/sys/class/thermal/cooling_device[0-*]:
|
2009-10-26 14:38:59 +07:00
|
|
|
|---type: Type of the cooling device(processor/fan/...)
|
|
|
|
|---max_state: Maximum cooling state of the cooling device
|
|
|
|
|---cur_state: Current cooling state of the cooling device
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
Then next two dynamic attributes are created/removed in pairs. They represent
|
|
|
|
the relationship between a thermal zone and its associated cooling device.
|
|
|
|
They are created/removed for each successful execution of
|
|
|
|
thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
/sys/class/thermal/thermal_zone[0-*]:
|
|
|
|
|---cdev[0-*]: [0-*]th cooling device in current thermal zone
|
|
|
|
|---cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with
|
2008-01-17 14:51:08 +07:00
|
|
|
|
2008-04-22 07:50:09 +07:00
|
|
|
Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
|
2009-10-26 14:38:59 +07:00
|
|
|
the generic thermal driver also creates a hwmon sysfs I/F for each _type_
|
|
|
|
of thermal zone device. E.g. the generic thermal driver registers one hwmon
|
|
|
|
class device and build the associated hwmon sysfs I/F for all the registered
|
|
|
|
ACPI thermal zones.
|
|
|
|
|
2008-04-22 07:50:09 +07:00
|
|
|
/sys/class/hwmon/hwmon[0-*]:
|
2009-10-26 14:38:59 +07:00
|
|
|
|---name: The type of the thermal zone devices
|
|
|
|
|---temp[1-*]_input: The current temperature of thermal zone [1-*]
|
|
|
|
|---temp[1-*]_critical: The critical trip point of thermal zone [1-*]
|
|
|
|
|
2008-04-22 07:50:09 +07:00
|
|
|
Please read Documentation/hwmon/sysfs-interface for additional information.
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
***************************
|
|
|
|
* Thermal zone attributes *
|
|
|
|
***************************
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
type
|
|
|
|
Strings which represent the thermal zone type.
|
|
|
|
This is given by thermal zone driver as part of registration.
|
|
|
|
E.g: "acpitz" indicates it's an ACPI thermal device.
|
|
|
|
In order to keep it consistent with hwmon sys attribute; this should
|
|
|
|
be a short, lowercase string, not containing spaces nor dashes.
|
|
|
|
RO, Required
|
|
|
|
|
|
|
|
temp
|
|
|
|
Current temperature as reported by thermal zone (sensor).
|
|
|
|
Unit: millidegree Celsius
|
|
|
|
RO, Required
|
|
|
|
|
|
|
|
mode
|
2012-07-25 09:11:00 +07:00
|
|
|
One of the predefined values in [enabled, disabled].
|
2009-10-26 14:38:59 +07:00
|
|
|
This file gives information about the algorithm that is currently
|
|
|
|
managing the thermal zone. It can be either default kernel based
|
|
|
|
algorithm or user space application.
|
2012-07-25 09:11:00 +07:00
|
|
|
enabled = enable Kernel Thermal management.
|
|
|
|
disabled = Preventing kernel thermal zone driver actions upon
|
|
|
|
trip points so that user application can take full
|
|
|
|
charge of the thermal management.
|
2009-10-26 14:38:59 +07:00
|
|
|
RW, Optional
|
|
|
|
|
2012-09-18 12:35:06 +07:00
|
|
|
policy
|
|
|
|
One of the various thermal governors used for a particular zone.
|
|
|
|
RW, Required
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
trip_point_[0-*]_temp
|
|
|
|
The temperature above which trip point will be fired.
|
|
|
|
Unit: millidegree Celsius
|
|
|
|
RO, Optional
|
|
|
|
|
|
|
|
trip_point_[0-*]_type
|
|
|
|
Strings which indicate the type of the trip point.
|
|
|
|
E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
|
|
|
|
thermal zone.
|
|
|
|
RO, Optional
|
|
|
|
|
2012-07-25 09:10:59 +07:00
|
|
|
trip_point_[0-*]_hyst
|
|
|
|
The hysteresis value for a trip point, represented as an integer
|
|
|
|
Unit: Celsius
|
|
|
|
RW, Optional
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
cdev[0-*]
|
|
|
|
Sysfs link to the thermal cooling device node where the sys I/F
|
|
|
|
for cooling device throttling control represents.
|
|
|
|
RO, Optional
|
|
|
|
|
|
|
|
cdev[0-*]_trip_point
|
|
|
|
The trip point with which cdev[0-*] is associated in this thermal
|
|
|
|
zone; -1 means the cooling device is not associated with any trip
|
|
|
|
point.
|
|
|
|
RO, Optional
|
2009-10-26 14:39:00 +07:00
|
|
|
|
|
|
|
passive
|
|
|
|
Attribute is only present for zones in which the passive cooling
|
|
|
|
policy is not supported by native thermal driver. Default is zero
|
|
|
|
and can be set to a temperature (in millidegrees) to enable a
|
|
|
|
passive trip point for the zone. Activation is done by polling with
|
|
|
|
an interval of 1 second.
|
|
|
|
Unit: millidegrees Celsius
|
2009-10-26 14:39:02 +07:00
|
|
|
Valid values: 0 (disabled) or greater than 1000
|
2009-10-26 14:39:00 +07:00
|
|
|
RW, Optional
|
2009-10-26 14:38:59 +07:00
|
|
|
|
2013-02-04 07:30:15 +07:00
|
|
|
emul_temp
|
|
|
|
Interface to set the emulated temperature method in thermal zone
|
|
|
|
(sensor). After setting this temperature, the thermal zone may pass
|
|
|
|
this temperature to platform emulation function if registered or
|
|
|
|
cache it locally. This is useful in debugging different temperature
|
|
|
|
threshold and its associated cooling action. This is write only node
|
|
|
|
and writing 0 on this node should disable emulation.
|
|
|
|
Unit: millidegree Celsius
|
|
|
|
WO, Optional
|
|
|
|
|
2013-03-27 04:38:34 +07:00
|
|
|
WARNING: Be careful while enabling this option on production systems,
|
|
|
|
because userland can easily disable the thermal policy by simply
|
|
|
|
flooding this sysfs node with low temperature values.
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
*****************************
|
|
|
|
* Cooling device attributes *
|
|
|
|
*****************************
|
|
|
|
|
|
|
|
type
|
|
|
|
String which represents the type of device, e.g:
|
|
|
|
- for generic ACPI: should be "Fan", "Processor" or "LCD"
|
|
|
|
- for memory controller device on intel_menlow platform:
|
|
|
|
should be "Memory controller".
|
|
|
|
RO, Required
|
|
|
|
|
|
|
|
max_state
|
|
|
|
The maximum permissible cooling state of this cooling device.
|
|
|
|
RO, Required
|
|
|
|
|
|
|
|
cur_state
|
|
|
|
The current cooling state of this cooling device.
|
|
|
|
The value can any integer numbers between 0 and max_state:
|
|
|
|
- cur_state == 0 means no cooling
|
|
|
|
- cur_state == max_state means the maximum cooling.
|
|
|
|
RW, Required
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
3. A simple implementation
|
|
|
|
|
2009-10-26 14:38:59 +07:00
|
|
|
ACPI thermal zone may support multiple trip points like critical, hot,
|
|
|
|
passive, active. If an ACPI thermal zone supports critical, passive,
|
|
|
|
active[0] and active[1] at the same time, it may register itself as a
|
|
|
|
thermal_zone_device (thermal_zone1) with 4 trip points in all.
|
|
|
|
It has one processor and one fan, which are both registered as
|
|
|
|
thermal_cooling_device.
|
|
|
|
|
|
|
|
If the processor is listed in _PSL method, and the fan is listed in _AL0
|
|
|
|
method, the sys I/F structure will be built like this:
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
/sys/class/thermal:
|
|
|
|
|
|
|
|
|thermal_zone1:
|
2009-10-26 14:38:59 +07:00
|
|
|
|---type: acpitz
|
|
|
|
|---temp: 37000
|
2012-07-25 09:11:00 +07:00
|
|
|
|---mode: enabled
|
2012-09-18 12:35:06 +07:00
|
|
|
|---policy: step_wise
|
2009-10-26 14:38:59 +07:00
|
|
|
|---trip_point_0_temp: 100000
|
|
|
|
|---trip_point_0_type: critical
|
|
|
|
|---trip_point_1_temp: 80000
|
|
|
|
|---trip_point_1_type: passive
|
|
|
|
|---trip_point_2_temp: 70000
|
|
|
|
|---trip_point_2_type: active0
|
|
|
|
|---trip_point_3_temp: 60000
|
|
|
|
|---trip_point_3_type: active1
|
|
|
|
|---cdev0: --->/sys/class/thermal/cooling_device0
|
|
|
|
|---cdev0_trip_point: 1 /* cdev0 can be used for passive */
|
|
|
|
|---cdev1: --->/sys/class/thermal/cooling_device3
|
|
|
|
|---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
|cooling_device0:
|
2009-10-26 14:38:59 +07:00
|
|
|
|---type: Processor
|
|
|
|
|---max_state: 8
|
|
|
|
|---cur_state: 0
|
2008-01-17 14:51:08 +07:00
|
|
|
|
|
|
|
|cooling_device3:
|
2009-10-26 14:38:59 +07:00
|
|
|
|---type: Fan
|
|
|
|
|---max_state: 2
|
|
|
|
|---cur_state: 0
|
2008-04-22 07:50:09 +07:00
|
|
|
|
|
|
|
/sys/class/hwmon:
|
|
|
|
|
|
|
|
|hwmon0:
|
2009-10-26 14:38:59 +07:00
|
|
|
|---name: acpitz
|
|
|
|
|---temp1_input: 37000
|
|
|
|
|---temp1_crit: 100000
|
2010-10-27 05:03:29 +07:00
|
|
|
|
|
|
|
4. Event Notification
|
|
|
|
|
|
|
|
The framework includes a simple notification mechanism, in the form of a
|
|
|
|
netlink event. Netlink socket initialization is done during the _init_
|
|
|
|
of the framework. Drivers which intend to use the notification mechanism
|
2011-11-04 16:31:04 +07:00
|
|
|
just need to call thermal_generate_netlink_event() with two arguments viz
|
2013-01-02 22:29:39 +07:00
|
|
|
(originator, event). The originator is a pointer to struct thermal_zone_device
|
|
|
|
from where the event has been originated. An integer which represents the
|
|
|
|
thermal zone device will be used in the message to identify the zone. The
|
2010-10-27 05:03:29 +07:00
|
|
|
event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL,
|
|
|
|
THERMAL_DEV_FAULT}. Notification can be sent when the current temperature
|
|
|
|
crosses any of the configured thresholds.
|
2012-09-18 12:35:06 +07:00
|
|
|
|
|
|
|
5. Export Symbol APIs:
|
|
|
|
|
|
|
|
5.1: get_tz_trend:
|
|
|
|
This function returns the trend of a thermal zone, i.e the rate of change
|
|
|
|
of temperature of the thermal zone. Ideally, the thermal sensor drivers
|
|
|
|
are supposed to implement the callback. If they don't, the thermal
|
|
|
|
framework calculated the trend by comparing the previous and the current
|
|
|
|
temperature values.
|
|
|
|
|
|
|
|
5.2:get_thermal_instance:
|
|
|
|
This function returns the thermal_instance corresponding to a given
|
|
|
|
{thermal_zone, cooling_device, trip_point} combination. Returns NULL
|
|
|
|
if such an instance does not exist.
|
|
|
|
|
2013-04-24 04:48:14 +07:00
|
|
|
5.3:thermal_notify_framework:
|
2012-09-18 12:35:06 +07:00
|
|
|
This function handles the trip events from sensor drivers. It starts
|
|
|
|
throttling the cooling devices according to the policy configured.
|
|
|
|
For CRITICAL and HOT trip points, this notifies the respective drivers,
|
|
|
|
and does actual throttling for other trip points i.e ACTIVE and PASSIVE.
|
|
|
|
The throttling policy is based on the configured platform data; if no
|
|
|
|
platform data is provided, this uses the step_wise throttling policy.
|
|
|
|
|
|
|
|
5.4:thermal_cdev_update:
|
|
|
|
This function serves as an arbitrator to set the state of a cooling
|
|
|
|
device. It sets the cooling device to the deepest cooling state if
|
|
|
|
possible.
|