NVIDIA Tegra
NVIDIA Tegra Linux Driver Package

Development Guide
32.1 Release


 
Power Management for Jetson Nano Devices
 
Interacting Features
Kernel Space Power Saving Features
Chipset Power States
Clock and Voltage Management
Regulator Framework
CPU Power Management
Frequency Management with cpufreq
Idle Management with cpuidle
Memory Power Management
Supported Modes and Power Efficiency
Thermal Management
Linux Thermal Framework
Thermal Zone
Configuring a Thermal Zone via the Device Tree
Thermal Cooling
Fan Management
Clock Throttling
Hardware Throttling
Impact
Throttle Points and Vector Configuration
Design Considerations
Thermal Shutdown
Software-Based Power Consumption Modeling
Related Tools and Techniques
Disabling 3D Frequency Scaling
Setting Frequencies
Maximizing Tegra Performance
Using CPU Hotplugging
The NVIDIA® Jetson Nano™ system-on-a-chip (SOC) and NVIDIA® Tegra® Board Support Package (BSP) provide 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:
Uniformly high performance
Excellent battery life
Perfect stability
Comfortable and cool to the touch
Interacting Features
Power, thermal, and electrical management features dynamically constrain knobs, such as:
Clock gate settings
Clock frequencies
Power gate (or regulator enable) settings
Voltages
Processor power state (i.e., which idle state is selected for the CPU)
Peripheral power state (i.e., which idle state is selected for an I/O controller)
Chipset power state
Availability of CPU cores to the OS
Some of these knobs are constrained by more than one feature. For example, cpufreq implements load based scaling based on 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, you must familiarize yourself with all of the power, thermal, and electrical management features in the BSP.
Kernel Space Power Saving Features
This section describes BSP features that 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 the user space.
Chipset Power States
The supported power states are listed in order of increasing flexibility or configurability:
Off state: There is only one way for a system to be off.
Deep Sleep (SC7) state: A deep sleep state with a small amount of configurability. For example, prior to entering Deep Sleep state, software can select which of the many hardware wake events may wake the chip.
Active state: Encompasses activity levels from low power audio playback through peak performance. Power consumption in Active state can range from tens of milliwatts to multiple watts.
Supported Power States
The supported power states are:
Power State
Properties
Characteristics
Off state
Power rails
None supplying the processor or DRAM.
State
None maintained in the processor or DRAM.
Exit
Into Active state via cold boot.
Deep Sleep (SC7) state
Power rails
VDD_RTC, VDDIO_DDR, VDDIO_SYS, and DRAM rails are powered on. VDD_CORE and VDD_CPU are powered off.
State
The processor maintains a limited amount of state information in the PMC block. DRAM maintains state.
Exit
Into Active state via a pre-selected set of wake events.
Active state
Power rails
VDD_RTC, VDDIO_DDR, VDDIO_SYS, VDD_CORE, and DRAM rails are powered on. Other power rails, including VDD_CPU and VDD_GPU, may be powered on.
State
Software actively manages the power states of the devices that make up the processor.
Exit
Software can initiate a transition from Active state to either Off state or Deep Sleep state.
Power State Mapping to Linux
BSP maps the hardware power states onto Linux power states as follows.
Chipset Power State
Linux Power State
Comments
Off state
Off state
Deep Sleep (SC7) state
Suspend
Software can choose whether to enter Deep Sleep state before the OS enters suspend.
Active state
Running/Idle (display on or off)
Many SoC devices may be idle or disabled under driver control. For example, VDD_CPU may be powered off and the companion CPU may be power-gated.
 
Note:
Jetson Nano uses SCy instead of LPx for the name of the chipset power state.
Clock and Voltage Management
Because frequency is proportional to voltage, dynamic voltage scaling is closely related to frequency scaling.
Most clock register manipulation on Jetson Nano is handled by the Linux kernel. The Linux kernel driver on the CPU exposes a simplified view of the physical clock tree to software on the main CPU via the Linux Common Clock Framework.
Regulator 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.
BSP configures the platform power tree appropriately for Jetson Nano. Additionally, drivers within BSP act as regulator consumers where appropriate.
When you port the BSP to a new platform, you must ensure that the platform power tree is configured to match the underlying hardware. Also ensure that all drivers for peripheral devices make correct 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.
CPU Power Management
Jetson Nano CPU power management strategy uses dynamic frequency scaling with dynamic voltage scaling, idle power states, and core management tuned for the Jetson Nano architecture.
Frequency Management with cpufreq
BSP implements CPU Dynamic Frequency Scaling (DFS) with the Linux cpufreq subsystem. The cpufreq subsystem comprises:
Platform drivers to implement the clock adjustment mechanism
Governors to implement frequency scaling policies
A core framework to connect governors to platform drivers
The policy for frequency scaling depends on which cpufreq governor is selected at runtime.
For details, see the information at:
<top>/kernel/kernel/kernel-4.9/Documentation/cpu-freq/
For each Jetson hardware reference design, NVIDIA selects a cpufreq governor and tunes it to achieve a balance between power and performance.
When a governor requests a CPU frequency change, the cpufreq platform driver reconciles that request with the constraints imposed by thermal and electrical limits and updates the CPU clock speed.
Jetson Nano 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.
Idle Management with cpuidle
The Linux cpuidle infrastructure supports the implementation of SoC-specific idle states for each CPU core. The 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 about the Linux cpuidle infrastructure, see:
<top>/kernel/kernel/kernel-4.9/Documentation/cpuidle/
NVIDIA provides an SoC-specific cpuidle driver that plugs into the cpuidle framework to enable CPU idle power management.
CPU Idle
The idle task is scheduled when there are no runnable tasks are left in the run queue 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 into a low power-state.
CCPLEX Idle States
The table below summarizes the different CPU core and cluster idle states available on Jetson Nano’s T210 processor and its software support for them.
Type of State
State
Meaning
Software support
Core state
C1
Clock-gating
Not supported
C7
Power-gating
Supported
Cluster state
CC1
Auto clock-gating
Not supported
CC4
Cluster retention
Not supported
CC6
Non-cpu power-gating
Not supported
CC7
Rail-gating
Not supported
Core states are denoted as Cx states, and cluster states are denoted as CCx states.
To enable cpuidle from the configuration file, set this option:
CONFIG_CPU_IDLE=y
To enable cpuidle from the device tree, use the following compatibility string:
cpuidle {
compatible = "nvidia,tegra210-cpuidle";
status = "okay";
};
To get and set a CPU’s core power state
To get the status of a core power state on CPU <x>, read the appropriate node. To set the status, write to the node.
Node pathnames have the form:
/sys/devices/system/cpu/cpu<x>/cpuidle/state<y>
Where:
<x> is the number of the CPU
<y> is a number that identifies a core state: 0 for C1, or 1 for C7
For reading, a pathname that returns a value of ASCII 1 indicates that a state is disabled, and ASCII 0 indicates that it is enabled. For writing, write ASCII 0 to the pathname to disable the state, or ASCII 1 to enable it.
Note:
Counterintuitively, ASCII 1 corresponds to “disabled,” and ASCII 0 to “enabled.”
To get cluster status
To get the status of the cluster states that are enabled for cluster A57 (the only cluster defined on Jetson Nano), run the command:
cat /sys/kernel/debug/cpuidle_t210/fast_cluster_states_enable
The value returned is a list of core and cluster idle states that are enabled by BSP:
To get per-core state usage statistics
To get a usage statistic for a specified core and a specified state, read the node:
cat /sys/devices/system/cpu/cpu<x>/cpuidle/state<y>/<statistic>
Where:
<x> is the number of the CPU
<y> is a number that indicates the state whose statistic is to be read: 0 for C1, or 1 for C7
<statistic> indicates the statistic to be read:
usage to get the number of times the kernel has requested this core to enter this state since boot
time to get the total time in microseconds that this core has spent in this state since boot
For example, to get the number of times that core 2 of cluster A57 has entered state C7, enter the command:
cat /sys/devices/system/cpu/cpu2/cpuidle/state1/usage
To get the total time in microseconds that core 2 of cluster A57 has spent in state C7:
cat /sys/devices/system/cpu/cpu2/cpuidle/state1/time
To disable cpuidle at boot time
Remove or disable the compatibility string nvidia,tegra210-cpuidle from the appropriate device tree file.
To disable a core/cluster power state at boot time
Remove or disable the appropriate core/cluster state nodes from the device trees in the DTSI file:
tegra210-soc-base.dtsi
Memory Power Management
The Jetson Nano chipset includes memory 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, 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 EMC 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.
EMC Frequency Scaling Policy
The following factors affect EMC frequency scaling policy at runtime:
The entries in the EMC DVFS table
The average memory bandwidth (utilization measured by the EMC activity monitor)
Requests made by various device drivers (cpufreq, graphics drivers, USB, HDMI™, and display)
Any limits dynamically imposed by thermal throttling
Supported Modes and Power Efficiency
Jetson Nano is designed with a high-efficiency Power Management Integrated Circuit (PMIC), voltage regulators, and power tree to optimize power efficiency. It supports two power modes, such as 5W and MaxN(10W). Each mode allows several configurations with various CPU frequencies and numbers of cores online.
You restrict the module to a predefined configuration by capping the memory, CPU, and GPU frequencies and number of cores online at pre-qualified values.
The following table shows the power modes predefined by NVIDIA and the associated caps on use of the module’s resources.
Mode Name
MaxN
5W
Power Budget
10W
5W
Mode ID
0
1
Online CPU
4
2
CPU Maximal Frequency (MHz)
1479
918
GPU TPC
1
1
GPU Maximal Frequency (MHz)
921.6
640
Memory Maximal Frequency (MHz)
1600
1600
The default mode is 10W (ID 0).
To change the power mode
Run the following command:
sudo /usr/sbin/nvpmodel -m <x>
Where <x> is the power mode ID, e.g. 0 or 1.
Once you set a power mode, the module stays in that mode until you change it. The mode persists across power cycles and SC7.
To display the current power mode
Enter the command:
sudo /usr/sbin/nvpmodel -q
To learn about other options
Enter the command:
/usr/sbin/nvpmodel -h
To define a custom mode
To define your own custom mode, add a mode definition to the file:
<top>/l4t/release/rfs/etc/nvpmodel/nvpmodel_t210_jetson-nano.conf
This is an example entry for mode 1:
< POWER_MODEL ID=1 NAME=5W >
CPU_ONLINE CORE_0 1
CPU_ONLINE CORE_1 1
CPU_ONLINE CORE_2 0
CPU_ONLINE CORE_3 0
CPU_A57 MIN_FREQ 0
CPU_A57 MAX_FREQ 918000
GPU_POWER_CONTROL_ENABLE GPU_PWR_CNTL_EN on
GPU MIN_FREQ 0
GPU MAX_FREQ 640000000
GPU_POWER_CONTROL_DISABLE GPU_PWR_CNTL_DIS auto
EMC MAX_FREQ 1600000000
The CPU’s unit of frequency is kilohertz (KHz). The GPU’s and EMMC’s unit is Hertz (Hz). You must assign each custom mode a unique ID in the ID field.
Test your custom mode to determine:
How many active cores to use
The frequencies to set for the GPU, EMC, and each CPU cluster
The frequencies you set are subject to the MaxN limit defined in mode 0.
Thermal Management
Thermal Management is essential for system stability and quality of user experience. Jetson Nano thermal management provides the following capabilities:
Sensing for temperature reporting
Cooldown for removing heat via the fan and for controlling heat via software clock throttling
Slowdown for hardware clock throttling
Shutdown for orderly software shutdown and hardware thermal reset
Jetson Nano thermal management is performed by software on the main CPU.
The following table identifies each thermal management action and the associated module for the Jetson Nano SoC.
Thermal Action
Linux Kernel Driver
Jetson Nano Implementation
Sensing
soctherm.c
Kernel software
aotag.c
Kernel software
Cooldown for software throttling
tegra_throttle.c
Kernel software
pwm_fan.c
Kernel software
Slowdown for hardware throttling
soctherm.c
Kernel software
Software shutdown
thermal_core.c
Kernel software
Hardware shutdown
soctherm.c
Kernel software
aotag.c
Kernel software
Linux Thermal Framework
The Linux thermal framework provides generic user space and kernel space interfaces for working with devices that measure or control temperatures. The central component of the framework is the Thermal Zone.
For more information about the Linux thermal framework, see:
<top>/kernel/Documentation/thermal/sysfs-api.txt
Thermal Zone
A thermal zone is a virtual object that represents an area on the die whose temperature is monitored and controlled. A thermal zone acts as an object with the following components:
Temperature sensor
Cooling device
Trip points
Governor
BSP includes drivers that provide interfaces to these components.
This topic introduces the components and demonstrates how they form a thermal zone on an NVIDIA SoC.
Configuring a Thermal Zone via the Device Tree
A thermal zone provides knobs to tune the thermal response of the zone. BSP provides several thermal zones tuned to provide optimum thermal performance. You can modify the provided thermal zones by editing the entries in the device tree. You can define sensors that monitor temperature limits and perform cooling actions on those limits. If a device becomes too hot, the situation can be resolved in most cases by tuning the thermal zone.
The following code snippet provides an example of a thermal zone definition for the Jetson Nano platform. This thermal zone monitors the temperature of the THERMAL_ZONE_CPU sensor. Clock throttling is performed using the CPU-balanced cooling device when the passive trip point cpu_throttle is crossed at 97° C.
CPU-therm {
thermal-zone-params {
governor-name = "step_wise";
};
trips {
cpu_critical {
temperature = <102000>;
hysteresis = <0>;
type = "critical";
writable;
};
cpu_heavy {
temperature = <100500>;
hysteresis = <0>;
type = "hot";
writable;
};
cpu_throttle {
temperature = <97000>;
hysteresis = <0>;
type = "passive";
writable;
};
};
cooling-maps {
map0 {
trip = <&{/thermal-zones/CPU-therm/trips/cpu_critical}>;
cdev-type = "tegra-shutdown";
cooling-device = <&{/soctherm@0x700E2000/throttle@critical}
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
map1 {
trip = <&{/thermal-zones/CPU-therm/trips/cpu_heavy}>;
cdev-type = "tegra-heavy";
cooling-device = <&throttle_heavy 1 1>;
};
map2 {
trip = <&{/thermal-zones/CPU-therm/trips/cpu_throttle}>;
cdev-type = "cpu-balanced";
cooling-device = <&{/bthrot_cdev/cpu_balanced}
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
};
};
For more information about thermal knobs, see:
<top>/kernel/Documentation/devicetree/bindings/thermal.txt
Temperature Sensors
A temperature sensor in a thermal zone is responsible for reporting the temperature. Temperature is reported in units of 0.001° C. Tegra has several types of temperature sensors spread across the die and board.
For more information, see the section Thermal Sensing in Linux.
Trip Points
Thermal management uses trip points to communicate with thermal zones. A 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.
Cooling Devices
A cooling device controls power dissipation by removing heat. There are essentially two types of cooling devices:
An active cooling device, such as a fan, removes heat by activating an external cooling device.
A passive cooling device, such as software/hardware clock throttling, removes heat by reducing device performance.
For more information, see Fan Management and Clock Throttling.
Governors
Thermal management requires a governer, some form of feedback control loop that keeps the device within a safe operating temperature. While the Linux thermal framework provides many different governors, BSP employs a simple Proportional Integral Derivative (PID) controller for all passive throttling needs.
BSP-Specific Thermal Zones
BSP defines a group of platform-specific thermal zones. 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 the Linux kernel as described in the following table.
Thermal Zone
Thermal Sensor
ABI Name
Cooling Action
Throttle Temperature
CPU-therm
THERMAL_ZONE_CPU
cpu_balanced
97.0° C
DFLL-cap
86.0° C
GPU-therm
THERMAL_ZONE_GPU
gpu-balanced
97.5° C
PLL-therm
THERMAL_ZONE_PLLX
Tegra_dram
70.0° C
AO-therm
THERMAL_ZONE_AO
GPU-cap
83.0° C
CORE-cap
85.0° C
thermal-fan-est
pwm_fan
51.0° C
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.
Thermal Cooling
Tegra BSP provides thermal management using fan control and throttling of various clocks in the system.
Fan Management
BSP provides fan management using active cooling in the form of fan control. The cooling device pwm-fan provides:
Fan speed control by programming the PWM controller
Ramp-up and ramp-down control to change the speed of the fan smoothly
Fan control during various power states
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 BSP sensors. As the temperature increases, the governor picks progressively deeper cooling states for the fan. This results in a higher RPM for the fan, which produces more cooling.
BSP’s thermal management uses the fan as the first line of defense to delay clock throttling until a much higher temperature is reached.
Clock Throttling
BSP provides thermal cooling by throttling various clocks in the system. When a thermal sensor’s temperature rises above a throttling trip point, clock throttling employs the DVFS capabilities of the clocks to reduce their operating frequencies, and thereby the voltages of the rails that power the clocks. This reduction in frequency and voltage reduces power consumption, which helps to control the temperature.
Because BSP provides cooling by reducing the clock frequency, it directly impacts performance and the user experience. If a device feels warm and seems sluggish, it may be due to thermal throttling on the clocks. You can remedy this by tuning the thermal zone provided in the following BSP balanced cooling devices:
gpu_balanced
cpu_balanced
emergency_balanced
Each of these balanced cooling devices provides several cooling states, each of which translates 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 a thermal zone as an input to the feedback control loop. Similarly, it uses the output of the control loop to set a new cooling state for the thermal zone’s cooling device. As the device heats up, the governor picks progressively higher cooling states, which result in higher frequency caps for all the clocks, and potentially greater cooling.
Hardware Throttling
Each element in a power delivery system includes limitations such as:
The amount of current a battery can supply without shutting down
The amount of current a regulator can provide before it fails to maintain its output voltage
The amount of ripple current an inductor in a switching regulator can tolerate without overheating
These limitations can result in fast transient electrical and thermal events such as:
Overcurrent at the battery
Voltage drop at the PMIC
Temperature spikes
The Linux kernel refers to these events as OC alarms and triggers hardware throttling of the clocks to handle them.
Impact
Like software throttling, hardware throttling may reduce performance. However, since the triggering events are rare and transient in nature, the user experience is minimally impacted.
The host OS is not notified of these events, but you can detect the resulting drop in clock rates using some performance measuring tools that sample the CPU cycle counters. While thermal management in the host OS seeks to control temperature on an ongoing basis, hardware throttling performs a clampdown of the clocks to handle events.
Throttle Points and Vector Configuration
The BPMP device tree binary holds the various throttle points and the throttle settings that govern when and how throttling is performed. The soctherm driver in the firmware programs the hardware and handles any interrupts resulting from these events. You can modify the throttle points by changing the kernel device tree.
The following table shows the throttle temperatures:
Thermal Zone
Hardware Throttle Limit
Hardware Throttling
CPU-therm
100.5° C
Heavy
GPU-therm
101° C
Heavy
The following table shows the hardware throttling levels:
Hardware Throttling
Clock Throttled Percentage
Heavy
87.5
Medium
75
Light
50
Throttle vectors are optimized for limiting peak current consumption while maximizing performance. To manage peak current consumption, the Linux kernel supports capping the CPU and GPU clocks at three levels (light, medium, and heavy) as described in the device tree bindings. Clock capping prevents the CPU and GPU from drawing more current than their voltage regulators can supply.
Design Considerations
Designing failsafe measures into Power Management Integrated Circuits (PMICs), or using the battery controller to shut down the device when the events described here occur, results in a bad user experience. Similarly, designing power delivery hardware for worst-case loads results in large and costly components.
Consequently, NVIDIA SoCs are designed for use with power delivery systems that are adequate for common loads. NVIDIA SoCs actively manage their components to avoid exceeding the capacity of such systems. When these events are transient in nature, the need for this design management system becomes more compelling.
Thermal Shutdown
Thermal zones also define a special type of trip point called a critical trip point which triggers a software shutdown. A critical trip point allows the operating system to save its state and perform an orderly shutdown before overheating causes a hardware shutdown. BSP defines a critical trip point for each thermal zone. You can set a lower temperature limit for the software shutdown.
A hardware shutdown (a thermtrip) occurs after all of the other cooling strategies have failed, and in particular, after software shutdown has failed to occur when it should. The SoC performs a hardware shutdown by asserting the reset pin on the PMIC. This is intended to be a rare event.
The shutdown limits for Jetson Nano are shown in the following table.
Thermal Zone
Software Shutdown Trip Point
Hardware Shutdown Trip Point
CPU-therm
102.0° C
102.5° C
GPU-therm
102.5° C
103.0° C
Software-Based Power Consumption Modeling
The Jetson Nano module has a three-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:
Command
Description
rail_name_<N>
Exports the rail name.
in_current<N>_input
Exports rail current in mA.
in_voltage<N>_input
Exports rail voltage in mV.
In_power<N>_input
Exports rail power in mW.
Where <N> is a channel number 0-2.
 
Note:
The INA driver may also present other nodes. Do not modify any INA sysfs node value. Modifying these values can result in damage to the device.
The sysfs nodes to read for rail names, voltage, current, and power are at:
/sys/bus/i2c/drivers/ina3221x/6-0040/iio:device0/
The rail names for I2C address 0x40 are:
Rail Name
Description
Channel 0: VDD_IN
Main module power input.
Channel 1: VDD_GPU
GPU power rail.
Channel 2: VDD_CPU
CPU power rail.
Examples
To read INA3221 at 0x40, the channel-0 rail name (i.e., VDD_IN), enter the command:
cat /sys/bus/i2c/drivers/ina3221x/61-0040/iio:device01/rail_name_0
To read VDD_IN voltage, current, and power, enter the commands:
cat /sys/bus/i2c/drivers/ina3221x/61-0040/iio:device01/in_current0_input
cat /sys/bus/i2c/drivers/ina3221x/61-0040/iio:device01/in_voltage0_input
cat /sys/bus/i2c/drivers/ina3221x/61-0040/iio:device01/in_power0_input
Note:
With regard to accuracy, assume a 5% guard band for INA measurements greater than 200 milliwatts. Below that, accuracy may deviate by as much as 15%.
Related Tools and Techniques
This section describes tools and techniques to manage power.
Disabling 3D Frequency Scaling
3D frequency scaling is enabled by default.
To disable 3D frequency scaling
Enter the command:
echo 0 > /sys/devices/57000000.gpu/enable_3d_scaling
To enable 3D frequency scaling
Enter the command:
echo 1 > /sys/devices/57000000.gpu/enable_3d_scaling
Setting Frequencies
To get system clock information
Enter the command:
cat /sys/kernel/debug/clk/clk_summary
To print the CPU lower bound, upper bound, and current frequency
Enter the commands:
cat /sys/devices/system/cpu/cpuX/cpufreq/cpuinfo_min_freq
cat /sys/devices/system/cpu/cpuX/cpufreq/cpuinfo_max_freq
cat /sys/devices/system/cpu/cpuX/cpufreq/cpuinfo_cur_freq
To change the CPU upper bound
Enter the command:
echo <cpu_freq> > /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq
To change the CPU lower bound
Enter the command:
echo <cpu_freq> > /sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq
To set the static CPU frequency
Enter the command:
echo <cpu_freq> > /sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq
echo <cpu_freq> > /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq
Where:
<cpu_freq> is the frequency value available at:
/sys/devices/system/cpu/cpu<x>/cpufreq/scaling_available_frequencies
<x> is the CPU core number
To print the GPU lower bound, upper bound, and current frequency
Enter the commands:
cat /sys/devices/57000000.gpu/devfreq/57000000.gpu/min_freq
cat /sys/devices/57000000.gpu/devfreq/57000000.gpu/max_freq
cat /sys/devices/57000000.gpu/devfreq/57000000.gpu/cur_freq
To change the GPU upper bound
Enter the command:
echo <gpu_freq> > /sys/devices/57000000.gpu/devfreq/57000000.gpu/max_freq
To change the GPU lower bound
Enter the command:
echo <gpu_freq> > /sys/devices/57000000.gpu/devfreq/57000000.gpu/min_freq
To set the static GPU frequency
Enter the command:
echo <gpu_freq> > /sys/devices/57000000.gpu/devfreq/57000000.gpu/min_freq
echo <gpu_freq> > /sys/devices/57000000.gpu/devfreq/57000000.gpu/max_freq
Where <gpu_freq> is the value available in:
/sys/devices/57000000.gpu/devfreq/57000000.gpu/available_frequencies
To print the EMC lower bound, upper bound, and current frequency
Enter the commands:
cat /sys/kernel/debug/tegra_bwmgr/emc_min_rate
cat /sys/kernel/debug/tegra_bwmgr/emc_max_rate
cat /sys/kernel/debug/tegra_bwmgr/emc_rate
To set static EMC frequency
Enter the commands:
echo <emc_freq> > /sys/kernel/debug/clk/override.emc/clk_update_rate
echo 1 > /sys/kernel/debug/clk/override.emc/clk_state
Where <emc_freq> is a frequency value between the EMC minimum and maximum frequencies.
Maximizing Tegra Performance
Tegra BSP provides the jetson_clocks.sh script to maximize Jetson Nano performance by setting the static maximum frequency of 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:
/usr/bin/jetson_clocks.sh
Use the command as follows:
jetson_clocks.sh [options]
Option
Description
--show
Displays the current settings.
--store [<file>]
Stores the current settings to a file.
The default filename is l4t_dfs.conf.
--restore [<file>]
Restores the saved settings from a file.
The default filename is l4t_dfs.conf.
To show the current settings
Enter the command:
sudo /usr/bin/jetson_clocks.sh --show
To store the current settings
Enter the command:
sudo /usr/bin/jetson_clocks.sh --store
To maximize Jetson Nano performance
Enter the command:
sudo /usr/bin/jetson_clocks.sh
To restore the previous settings
Enter the command:
sudo /usr/bin/jetson_clocks.sh --restore
Using CPU Hotplugging
You can manage CPU hotplugging as follows.
To turn a slave CPU on or off manually
Enter the command:
echo <b> > /sys/devices/system/cpu/cpu<x>/online
Where:
<b> is 1 to turn the CPU on, or 0 to turn it off
<x> is the number of the CPU core number
To check a CPU’s state
Enter the command:
cat /sys/devices/system/cpu/cpu<x>/online
Where <x> is the CPU core number.