Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Thermal: Add documentation for platform layer data

Browse source 
This patch adds documentation for thermal_bind_params
and thermal_zone_params structures. Also, adds details
on EXPORT_SYMBOL APIs.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This commit is contained in:
Durgadoss R 2012-09-18 11:05:06 +05:30 committed by Zhang Rui
parent f2b4caafd4
commit 6ea083b18d
1 changed files with 64 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

64
Documentation/thermal/sysfs-api.txt
View file

@ -112,6 +112,29 @@ temperature) and throttle appropriate devices.
trip: indicates which trip point the cooling devices is associated with
in this thermal zone.
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.
.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
.num_tbps: Number of thermal_bind_params entries for this zone
.tbp: thermal_bind_params entries
2. sysfs attributes structure
RO read only value
@ -126,6 +149,7 @@ Thermal zone device sys I/F, created once it's registered:
|---type: Type of the thermal zone
|---temp: Current temperature
|---mode: Working mode of the thermal zone
|---policy: Thermal governor used for this zone
|---trip_point_[0-*]_temp: Trip point temperature
|---trip_point_[0-*]_type: Trip point type
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
@ -187,6 +211,10 @@ mode
charge of the thermal management.
RW, Optional
policy
One of the various thermal governors used for a particular zone.
RW, Required
trip_point_[0-*]_temp
The temperature above which trip point will be fired.
Unit: millidegree Celsius
@ -264,6 +292,7 @@ method, the sys I/F structure will be built like this:
|---type: acpitz
|---temp: 37000
|---mode: enabled
|---policy: step_wise
|---trip_point_0_temp: 100000
|---trip_point_0_type: critical
|---trip_point_1_temp: 80000
@ -305,3 +334,38 @@ to a thermal_zone_device when it registers itself with the framework. The
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.
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.
5.3:notify_thermal_framework:
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.
5.5:thermal_register_governor:
This function lets the various thermal governors to register themselves
with the Thermal framework. At run time, depending on a zone's platform
data, a particular governor is used for throttling.
5.6:thermal_unregister_governor:
This function unregisters a governor from the thermal framework.