123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491 |
- Generic Thermal Sysfs driver How To
- ===================================
- 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
- 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.
- 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.
- 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.
- [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
- 1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *type,
- int trips, int mask, void *devdata,
- struct thermal_zone_device_ops *ops,
- const struct thermal_zone_params *tzp,
- int passive_delay, int polling_delay))
- 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.
- type: the thermal zone type.
- trips: the total number of trip points this thermal zone supports.
- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
- 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.
- .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
- so that user applications can take charge of thermal management.
- .set_mode: set the mode (enabled/disabled) of the thermal zone.
- .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.
- .set_emul_temp: set the emulation temperature which helps in debugging
- different threshold temperature points.
- 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).
- 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
- 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.
- 1.2 thermal cooling device interface
- 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name,
- 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.
- 1.2.2 void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
- 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.
- 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,
- int trip, struct thermal_cooling_device *cdev,
- unsigned long upper, unsigned long lower, unsigned int weight);
- 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.
- 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.
- weight: the influence of this cooling device in this thermal
- zone. See 1.4.1 below for more information.
- 1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
- int trip, struct thermal_cooling_device *cdev);
- 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.
- 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 relative to the rest of the cooling
- devices. For example, if all cooling devices have a
- weight of 1, then they all contribute the same. You can
- use percentages if you want, but it's not mandatory. A
- weight of 0 means that this cooling device doesn't
- contribute to the cooling of this zone unless all cooling
- devices have a weight of 0. If all weights are 0, then
- they all contribute the same.
- .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.
- .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.
- .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
- .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).
- .num_tbps: Number of thermal_bind_params entries for this zone
- .tbp: thermal_bind_params entries
- 2. sysfs attributes structure
- RO read only value
- RW read/write value
- 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.
- Thermal zone device sys I/F, created once it's registered:
- /sys/class/thermal/thermal_zone[0-*]:
- |---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
- |---emul_temp: Emulated temperature set node
- |---sustainable_power: Sustainable dissipatable power
- |---k_po: Proportional term during temperature overshoot
- |---k_pu: Proportional term during temperature undershoot
- |---k_i: PID's integral term in the power allocator gov
- |---k_d: PID's derivative term in the power allocator
- |---integral_cutoff: Offset above which errors are accumulated
- |---slope: Slope constant applied as linear extrapolation
- |---offset: Offset constant applied as linear extrapolation
- Thermal cooling device sys I/F, created once it's registered:
- /sys/class/thermal/cooling_device[0-*]:
- |---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
- 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.
- /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
- |---cdev[0-*]_weight: Influence of the cooling device in
- this thermal zone
- Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
- 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.
- /sys/class/hwmon/hwmon[0-*]:
- |---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-*]
- Please read Documentation/hwmon/sysfs-interface for additional information.
- ***************************
- * Thermal zone attributes *
- ***************************
- 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
- One of the predefined values in [enabled, disabled].
- 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.
- 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.
- 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
- 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
- trip_point_[0-*]_hyst
- The hysteresis value for a trip point, represented as an integer
- Unit: Celsius
- RW, Optional
- 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
- cdev[0-*]_weight
- The influence of cdev[0-*] in this thermal zone. This value
- is relative to the rest of cooling devices in the thermal
- zone. For example, if a cooling device has a weight double
- than that of other, it's twice as effective in cooling the
- thermal zone.
- RW, Optional
- 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
- Valid values: 0 (disabled) or greater than 1000
- RW, Optional
- 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
- 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.
- sustainable_power
- An estimate of the sustained power that can be dissipated by
- the thermal zone. Used by the power allocator governor. For
- more information see Documentation/thermal/power_allocator.txt
- Unit: milliwatts
- RW, Optional
- k_po
- The proportional term of the power allocator governor's PID
- controller during temperature overshoot. Temperature overshoot
- is when the current temperature is above the "desired
- temperature" trip point. For more information see
- Documentation/thermal/power_allocator.txt
- RW, Optional
- k_pu
- The proportional term of the power allocator governor's PID
- controller during temperature undershoot. Temperature undershoot
- is when the current temperature is below the "desired
- temperature" trip point. For more information see
- Documentation/thermal/power_allocator.txt
- RW, Optional
- k_i
- The integral term of the power allocator governor's PID
- controller. This term allows the PID controller to compensate
- for long term drift. For more information see
- Documentation/thermal/power_allocator.txt
- RW, Optional
- k_d
- The derivative term of the power allocator governor's PID
- controller. For more information see
- Documentation/thermal/power_allocator.txt
- RW, Optional
- integral_cutoff
- Temperature offset from the desired temperature trip point
- above which the integral term of the power allocator
- governor's PID controller starts accumulating errors. For
- example, if integral_cutoff is 0, then the integral term only
- accumulates error when temperature is above the desired
- temperature trip point. For more information see
- Documentation/thermal/power_allocator.txt
- RW, Optional
- slope
- The slope constant used in a linear extrapolation model
- to determine a hotspot temperature based off the sensor's
- raw readings. It is up to the device driver to determine
- the usage of these values.
- RW, Optional
- offset
- The offset constant used in a linear extrapolation model
- to determine a hotspot temperature based off the sensor's
- raw readings. It is up to the device driver to determine
- the usage of these values.
- RW, Optional
- *****************************
- * 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
- 3. A simple implementation
- 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. Both are considered to have the same
- effectiveness in cooling the thermal zone.
- 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:
- /sys/class/thermal:
- |thermal_zone1:
- |---type: acpitz
- |---temp: 37000
- |---mode: enabled
- |---policy: step_wise
- |---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 */
- |---cdev0_weight: 1024
- |---cdev1: --->/sys/class/thermal/cooling_device3
- |---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
- |---cdev1_weight: 1024
- |cooling_device0:
- |---type: Processor
- |---max_state: 8
- |---cur_state: 0
- |cooling_device3:
- |---type: Fan
- |---max_state: 2
- |---cur_state: 0
- /sys/class/hwmon:
- |hwmon0:
- |---name: acpitz
- |---temp1_input: 37000
- |---temp1_crit: 100000
- 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
- just need to call thermal_generate_netlink_event() with two arguments viz
- (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
- 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:thermal_notify_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.
|