Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: mobile-power-thermal-optimzations

• Packages affected:

Summary

Thermal extension The platform thermal solution depends on the kernel framework for controlling the device performing state and monitor thermal sensor for the platform. The kernel thermal monitoring and controlling mechanism is spread across acpi thermal driver and non acpi thermal sensor driver, and the thermal algorithm are embedded in the kernel driver. The proposed patch is to extend the thermal driver and unify various thermal sensing/controlling property through sysfs interface so that platform level thermal related decision can be made at user space.

Release Note

Thermal extension The current thermal zone driver is modified to expose thermal properties of platform through Sysfs. A new thermal Sysfs driver is introduced which will export two interface for the platform specific sensor driver and component throttle driver. The cpu thermal driver will work as it is, but will interface with the thermal Sysfs driver.

Rationale

Thermal extension Linux notebooks today use a combination of ACPI and native-device thermal control. System uses ACPI’s CRT/HOT trip point for critical system shutdown, since on a handheld, shutdown and hibernate to disk (if one even exists) are likely to be synonymous. Active trip points are of no use on systems which have no fans. That leaves the single PSV trip point. ACPI 2.0 can associate (only) a processor throttling device with a trip point. But the processor isn’t expected to always be the dominant contributor to thermal footprint on handhelds like it often is on notebooks. ACPI 2.0 includes the _TZD method to associate devices with thermal zones. However, ACPI doesn’t say anything about how to throttle non-processor devices—so that must be handled by native device drivers.

Use Cases

Assumptions

Design

Thermal Extension

Thermal monitoring will be done using inexpensive thermal sensors—polled by a low-power EC.

• Thermal management policy decisions will be made from user space, as the user has a comprehensive view of the platform.
• The kernel provides only the mechanism to deliver thermal events to user space, and the mechanism for user space to communicate its throttling decisions to native device drivers.

Figure 1

Figure 1 shows the thermal control software stack. The thermal management policy control application sits on top. It receives netlink messages from the kernel thermal zone driver. It then implements device-specific thermal throttling via sysfs. Native device drivers supply the throttling controls in sysfs and implement device-specific throttling functions.

Thermal zone module

The thermal zone module has two components — a thermal zone sysfs driver and thermal zone sensor driver.

The thermal zone sysfs driver is platform-independent, and handles all the sysfs interaction. The thermal zone sensor driver is platform-dependent. It works closely with the platform BIOS and sensor driver, and has knowledge of sensor information in the platform.

Thermal zone sysfs driver

The thermal sysfs driver exports two interfaces (thermal_control_register() and thermal_control_deregister()) to component drivers, which the component drivers can call to register their control capability to the thermal zone sysfs driver. The thermal sysfs drier also exports two interfaces—

* thermal_sensor_register() * thermal_sensor_deregister()

to the platform-specific sensor drivers, where the sensor drivers can use this interface to register their sensor capability. This driver is responsible for all thermal Sysfs entries. It interacts with all the platform specific thermal sensor drivers and component drivers to populate the sysfs entries. The thermal zone driver also provides a notification-of-temperature service to a component driver. The thermal zone sensor driver as part of registration exposes its sensing and thermal zone capability.

Thermal Zone sensor driver

The thermal zone sensor driver provides all the platform-specific sensor information to the thermal sysfs driver. It is platform-specific in that it has prior information about the sensors present in the platform. The thermal zone driver directly maps the ACPI 2.0 thermal zone definition. The thermal zone sensor driver also handles the interrupt notification from the sensor trips and delivers it to user space through netlink socket. Component Throttle driver All the component drivers participating in the given thermal zone can register with the thermal driver, each providing the set of thermal ops it can support. The thermal driver will redirect all the control requests to the appropriate component drivers when the user programs the throttling level. Its is up to the component driver to implement the thermal control. For example, a component driver associated with DRAM would slow down the DRAM clock on throttling requests.

Thermal Zone Sysfs Property

Table 1 shows the directory structure exposing each thermal zone sysfs property to user space. The intent is that any combination of ACPI and native thermal zones may exist on a platform, but the generic sysfs interface looks the same for all of them. Thus, the syntax of the files borrows heavily from the Linux hwmon subsystem.

Each thermal zone provides its current temperature and an indicator that can be used by user-space to see if the current temperature has changed since the last read. If a critical trip point is present, its value is indicated here, as well as an alarm indicator showing whether it has fired. If a passive trip point is present, its value is indicated here, as well as an alarm indicator showing whether it has fired. There are symbolic links to the device nodes of the devices associated with the thermal zone. Those devices will export their throttling controls under their device nodes.

Throttling Sysfs Properties

Devices that support throttling will have two additional properties associated with the device nodes: throttling and throttling_max. A value of 0 means maximum performance, though no throttling. A value of throttling_ max means maximum power savings in the deepest throttling state available before device state is lost.

Events will be passed from the kernel to userspace using the Linux netlink facility. Interrupts from the sensor or EC are delivered to user-space through a netlink socket.

Table 1

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Outstanding Issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec