NVIDIA® Tegra® system-on-a-chip (SOC) and NVIDIA® Tegra® Board Support Package (BSP) provides many features related to power management, thermal management, and electrical management. These features deliver the best user experience possible given the constraints of a particular platform. The target user experience ensures the perception that the device provides:

Power, thermal, and electrical management features dynamically constrain knobs, such as:

Some of these knobs are constrained by more than one feature. For example, cpufreq implements load based scaling based on the how busy the CPU is and adjusts the CPU frequency accordingly. CPU thermal management, however, can override the target frequency of cpufreq. Consequently, before attempting to debug power, performance, thermal, or electrical problems, familiarize yourself with all of the power, thermal, and electrical management features present in the BSP.

This section describes the features that Tegra implements several features to save power and extend battery life. Many of these features are implemented by the Linux kernel, with support from firmware and hardware, and without significant involvement from user-space.

The supported power states are listed in order of increasing flexibility or configurability:

The supported power states are as follows:

Tegra BSP maps these hardware power states onto Linux Power States as follows.

Because frequency is proportional to voltage, dynamic voltage scaling is closely related to frequency scaling. For example, higher frequencies require higher voltages and vice versa.

Most clock register manipulation on Tegra X1 is handled by Linux Kernel. The Linux kernel driver on the CPU exposes simplified view of the physical clock tree to software on the main CPU via the Linux Common Clock Framework.

The Linux regulator framework provides an abstraction that allows regulator consumer drivers to dynamically adjust voltage or current regulators at runtime, without knowledge of the underlying hardware power tree.

The framework provides a mechanism that platform initialization code can use to declare a power tree topology and assign a driver that provides regulators for each node in the hardware power tree. Such a driver is called a regulator provider driver.

Tegra BSP configures the platform power tree appropriately for Tegra devices. Additionally, drivers within Tegra BSP act as regulator consumers, where appropriate.

When porting Tegra BSP to a new platform, ensure that the platform power tree is configured correctly to match the underlying hardware. Additionally, ensure that all drivers for peripheral devices correctly make use of the regulator consumer APIs. BSP drivers registering as regulator consumers can cause I/O pads on the chip to be unavailable for other functions. Ensure that the Device Tree and board configuration file information for your new platform avoids conflicts between functions using the same I/O pads.

Tegra CPU power management strategy includes dynamic frequency scaling with dynamic voltage scaling, idle power states, and core management tuned for the Tegra X1 architecture.

Tegra BSP implements CPU Dynamic Frequency Scaling (DFS) with the Linux cpufreq subsystem. The cpufreq subsystem comprises:

The policy for frequency scaling depends on which cpufreq governor is selected at runtime.

For details consult the information available at:

For each Tegra hardware reference design, a cpufreq governor is selected and tuned to achieve a balance between power and performance.

When a governor requests a CPU frequency change, the Tegra-specific cpufreq platform driver reconciles that request with limits imposed by thermal or electrical limits. The driver updates the clock speed of the CPU.

Tegra X1 uses an DFLL to clock each CPU. Hardware (with the assistance of the Linux Kernel) ensures that the CPU voltage is appropriate for the DFLL to deliver requested CPU frequencies.

The Linux cpuidle infrastructure supports the implementation of SoC-specific idle states for each CPU core. cpuidle lacks direct support for idle states applicable to an entire CPU cluster and for idle states extending beyond a CPU cluster.

For more information on the Linux cpuidle infrastructure, see:

NVIDIA provides a Tegra-specific cpuidle driver that plugs into the cpuidle framework to enable CPU idle power management.

The Tegra cpuidle driver exposes two per-core CPU idle states as follows:

When the final core within a cluster transitions to idle, the Tegra-specific cpuidle driver can transition the CPU cluster to a cluster idle state.

Additionally, as the final core within a cluster transitions to idle, the Tegra cpuidle driver optionally disables any SoC resources where the CPU was the last active user.

For example, the final CPU core transitioning to idle can optionally do one or more of the following:

The idle task is scheduled when there are no runnable tasks left in the runqueue for a particular core. This task, through the cpuidle driver and cpuidle governor, selects the core and puts it into a low-power state, where it stays until an interrupt wakes it up to process more work.

When the last active core in a CPU cluster goes into an idle or offline state, the idle task puts the entire CPU cluster in a low power-state.

Core states are denoted Cx states, cluster states are denoted as CCx states, and CCPlex states are denoted as CCPx states. The table below summarizes the different states available on the T210.

Use KConfig and the Device Tree node to enable cpuidle.

Tegra chipsets include power saving features whose operation is largely invisible to software at runtime. Most of those features are statically enabled at boot, according to settings in the boot configuration table (BCT).

Additionally, Tegra BSP implements EMC frequency scaling, which is dynamic frequency scaling for the memory controller (EMC/MC) and DRAM. This is a critical power saving feature that requires tuning and characterization for each new printed circuit board design.

The calibration results include a BCT and an EMC DVFS table specific to the board design. The EMC DVFS table must be included in the platform kernel device tree file.

The following factors affect EMC frequency scaling policy at runtime:

Thermal Management is essential for system stability and quality of user experience. The Tegra X1 thermal management provides the following capabilities:

Tegra X1 thermal management is performed by the software on the main CPU.

The following table identifies each thermal management action and the associated module for the Tegra chip.

The Linux thermal framework provides generic user-space and kernel-space interfaces for working with devices that measure temperature and devices used to control temperatures. The central component of the framework is the Thermal Zone.

More information about the Linux thermal framework is available at:

A thermal zone is a virtual object that represents an area on the die whose temperature is monitored and controlled. Essentially, a working thermal zone is more than a sensor, but acts as an object with the following components:

Tegra BSP includes drivers that provide interfaces defined by these components.

This topic introduces these components and demonstrates how they form a thermal zone on a Tegra-based device.

The thermal zone provides knobs to tune the thermal response of the zone. Tegra BSP provides several thermal zones tuned to provide optimum thermal performance. These provided thermal zones can be modified by editing the entries in the device tree. Users can define sensors to use temperature limits and cooling actions on those limits. When a device becomes too hot, in most cases, it can be resolved by tuning the thermal zone.

The following code snippet provides an example of a thermal zone for the TX1 platform. This thermal zone monitors the temperature of the THERMAL_ZONE_CPU sensor. The clock throttling is performed using the CPU-balanced cooling device when the passive trip point, cpu_throttle, is crossed at 97 degrees Celsius.

More information about thermal knobs is available at:

A temperature sensor in a thermal zone is responsible for reporting the temperature in milli-Celsius. Tegra has several types of temperature sensors spread across on the die and board.

For more information see Thermal Sensing in Linux.

Trip points are used to communicate with the thermal zone. The trip point identifies the temperature at which to perform a thermal action. Trip points are classified as active or passive, based on the type of cooling they trigger. A trip point is classified as critical if it triggers a thermal shutdown. A cooling map specifies how a cooling device is associated with certain trip points. Tegra BSP supports fan and clock throttling.

A cooling device does not actually remove any actual heat; only fan cooling device can remove heat. The Linux thermal framework makes this distinction by classifying fan cooling as an “active” cooling device. Clock throttling, which is the other type of cooling device, is classified as a “passive” cooling device.

For more information see Fan Management and Clock Throttling.

Thermal management requires some form of feedback control system that keeps the device within a safe operating temperature. The governor implements this feedback control loop. While the Linux thermal framework provides many different governors, Tegra BSP provides a simple Proportional Integral Derivative (PID) controller for all passive throttling needs.

Platform specific thermal zones are provided in the Tegra BSP. They are tuned to provide the best performance within the thermal constraints of the device. Each thermal zone uses a temperature sensor that is controlled by Linux kernel as described in the following table.

All gains achieved by tuning are limited by the Thermal Design Power (TDP) of the system. Tuning cannot remedy a faulty TDP, and removing all the thermal zones does not guarantee maximum performance because it can cause irreversible damage to the device and/or resets.

The Tegra platform includes several drivers for temperature sensing.

Tegra BSP includes a driver for devices such as:

These devices can sense their own temperature as well as sensing the temperature of a remote diode. Tegra platforms have these sensors setup as follows:

Tegra BSP configures this sensor to operate in an extended mode to increase the temperature range to 64 Degrees Celsius to 191 degrees Celsius.

On many platforms, the voltage rail that powers the sensor is gated when Tegra enters SC7 state. Consequently, the sensor is stopped when Tegra enters SC7 and turned back on when Tegra exits SC7 state.

The NCT sensors generate thermal events for:

The NCT sensors allow software to program a static offset temperature for the remote sensor. This accounts for any inaccuracy that may be present in the sensor hardware. Tegra BSP reads the offset from the Device Tree and programs into the offset register on boot. The offset is calculated and validated via oil bath experiments.

Tegra BSP provides thermal management using fan control and throttling of various clocks in the system.

Fan management in Tegra BSP is provided using active cooling in the form of fan control. The cooling device pwm-fan provides:

The PWM-RPM mapping, and the various ramp rates, are stored as part of the device tree binary. The pwm-fan cooling device maps these PWM values to a cooling state. The fan cooling device can be attached to monitor the temperature of any of the Tegra BSP sensors. As the temperature increases, the governor progressively picks a deeper cooling state for the fan. This results in a higher RPM for the fan which then results in more cooling.

Tegra thermal management uses the fan as the first line of defense to delay clock throttling until a much higher temperature.

Tegra BSP provides thermal cooling by throttling various clocks in the system. When a rising temperature crosses a trip point, clock throttling relies on the DVFS capabilities of the clocks to reduce their operating frequency, and thereby the voltage of the rail that powers the clock. This lowered frequency and voltage reduces the power consumption which then helps in controlling the temperature.

Because cooling is achieved by reducing the clock frequency, there is a direct impact on the performance and user experience. If a device feels warm and seems sluggish, it may be due to thermal throttling on the clocks. This can be remedied by tuning the thermal zone provided in the following Tegra BSP balanced cooling devices:

Each of these balanced cooling devices provides several cooling states that translate to a maximum allowable operating frequency for the CPU, GPU, and EMC clocks. These frequencies are optimized to provide the best possible performance at a given temperature. The frequency tables for these clocks are part of the device tree binary.

The governor uses the current temperature of the sensor as an input to the feedback control loop. Similarly, the governor uses the output is as the new cooling state for the operation of the cooling device. As the device heats up, the governor progressively picks a higher cooling which then results in a higher frequency cap for all the clocks, and potentially higher cooling. Tegra BSP performs this thermal throttling of the clocks to maintain the junction temperature of the die within the recommended safe limits.

The thermal zones also define a special type of trip point called a critical trip point that triggers a software shutdown. This special trip point allows the operating system to save its state and perform an orderly shutdown before a hardware reset due to high temperature rates. Tegra BSP defines one critical trip point per thermal zone. Users can set the lower limit for the orderly shutdown. A thermal shutdown occurs after all the other cooling strategies have failed. It is considered a rare event. The shutdown limits are as follows.

The Jetson TX1 module has 3-channel INA3221 power monitor at I2C address 0x40.

The information from the INA3221 power monitor can be read using sysfs nodes. The naming convention for sysfs nodes is as follows:

The sysfs nodes to read for rail names, voltage, current, and power are at:

The rail names for I2C address 0x40 are:

The Jetson TX1 Developer Kit carrier board has 3-channel INA3221 power monitors at I2C addresses 0x42 and 0x43. The sysfs nodes to read rail name, voltage, current and power are at:

The rail names for I2C address 0x42 are:

The rail names for I2C address 0x43 are:

The tools and techniques to manage power are as follows.

3D frequency scaling is enabled by default.

Tegra BSP provides the jetson_clocks.sh script to maximize Jetson-TX1 performance by setting static maximum frequency to the CPU, GPU, and EMC clocks. Use the script to show current clock settings, store current clock settings into a file, and restore clock settings from a file.

The script is available at:

The command usage is as follows:

You can manage the CPU hotplug as follows.

Where <X> is the CPU core number.