# Linux Thermal Control Disabled

In this first experiment, the Linux thermal control is disabled:

# echo disabled > /sys/class/thermal/thermal_zone0/mode

During the first state of this experiment, the Linux CPU frequency scaling governor chooses the “powersafe” policy due to the low CPU activity. The system settles as follows:

• fCPU = 90 MHz
• VDDCPU = 1.05V
• CPU load = 48% (as reported by the “top” monitoring program)
• TJ = 86.5°C

During the second state, the frequency scaling governor switches to the “performance” policy. The system variables are as follows:

• fCPU = 1GHz
• CPU load = 100% (as reported by the “top” monitoring program)
• TJ increases up to 92.6°C.
Figure 1. Junction Temperature Response to a CPU Load Step

As shown in the figure above, the SAMA7G54 junction temperature varies very slowly. It takes around six seconds for TJ to reach 60% of its final value. This time constant should be compared to the application activity burst duration. If activity bursts are shorter than the thermal time constant, these will be “filtered out” by the thermal inertia of the system and TJ will never settle to its final value.

To illustrate this, the following figure shows TJ impulse response to a CPU processing burst. From the Linux Idle state, the CPU executes a 3-second long processing burst, and then resumes its initial state.

Figure 2. Junction Temperature Response to a CPU Load Burst

The two responses above show how important dynamics are in a system. Studying a power budget in steady state conditions without accounting for response times may result in erroneous conclusions. It all depends on how the system rate of change compares to its thermal time constant.