Starting from SDK11.0 (or earlier), the Linux SDK began to incorporate the Linux VTM driver. The Linux kernel VTM and the chip's hardware VTM are two unrelated concepts. The kernel VTM framework uses the configuration in the device tree (k3-am62-thermal.dtsi, defined by the kernel thermal binding documentation) to monitor sensor temperatures and take corresponding actions, such as reducing CPU frequency, shutting down, or rebooting Linux. The sensor temperature used by Linux is acquired by the AM62x hardware VTM module.

The definition/configuration in the kernel device tree k3-am62a-thermal.dtsi is only an example, and customers can modify it according to project requirements, such as shutting down or rebooting Linux. Using the default settings in the kernel device tree k3-am62a-thermal.dtsi, the kernel will trigger a shutdown sequence when the temperature reaches 105°C. Taking Linux SDK11.0 as an example, the Linux VTM driver also defines interrupt thresholds similar to the hardware VTM. Up to 3 threshold temperatures can be programmed and set, of which 2 are used for greater-than thresholds and 1 is used for a less-than threshold, so that the VTM can alert the kernel to take action. For example, when the first threshold is exceeded, the kernel can be alerted to start reducing the CPU's voltage and clock speed, thereby stabilizing the overall temperature of the SoC. If the SoC temperature continues to rise, we can use the second threshold to take more aggressive measures. For example, we can issue a poweroff command after exceeding the second threshold to completely turn off the device. The threshold temperatures can be set in the kernel using the values we define in the device tree. This can be used to: set a "critical" temperature at which the kernel will shut down. The SoC issues a "passive" alert to the kernel when overheating, and the MPU frequency can be reduced by registering the cpufreq driver as a cooling device. The threshold for software thermal protection can be changed by modifying the following code, such as changing the shutdown temperature from 105°C to 125°C, correspondingly switching the software protection from the industrial-grade shutdown temperature to the automotive-grade temperature. The following code indicates a critical temperature of 55°C with a 5°C hysteresis control. Upon reaching 55°C, it enters a "passive" state to initiate heat dissipation measures, and immediately protects and shuts down upon reaching 125°C (with a 2°C hysteresis control).

/* From arch/arm64/boot/dts/ti/k3-am62a-thermal.dtsi */
thermal_zones: thermal-zones {
        main0_thermal: main0-thermal {
                polling-delay-passive = <250>; /* milliSeconds */                
                polling-delay = <500>; /* milliSeconds */                
                thermal-sensors = <&wkup_vtm0 0>;
                trips {
                        main0_alert: main0-alert {
                                temperature = <95000>;
                                hysteresis = <2000>;
                                type = "passive";
                        };
                        main0_crit: main0-crit {
                                temperature = <105000>;     /* milliCelsius */
                                hysteresis = <2000>;       /* milliCelsius */
                                type = "critical";
                        };
                };
                cooling-maps {
                        map0 {
                                trip = <&main0_alert>;
                                cooling-device = 
                                                   <&cpu0 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
                                                   <&cpu1 THERMAL_NO_LIMIT  
THERMAL_NO_LIMIT>,
                                <&cpu2 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
                                              <&cpu3 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
                        };
                };
        };

When the kernel enters the "passive" state, it can adopt the method of killing low-priority processes to reduce the load of the corresponding core. For some critical tasks, it can adopt the method of reducing the operating frequency to lower power consumption. Dynamic Frequency Selection (DFS) is an excellent way to reduce CPU frequency based on needs. For DFS details, please refer to this tutorial.

The DFS method can currently easily change the frequency of the A core. The method for changing the frequencies of other cores is provided below. First, identify the clock source/PLL and divider associated with the core from the chip's TRM (clocking section). Modify the divider according to the PLL to make the final output clock conform to the speed grade.

The following is an example of how to change the C7x core clock of AM62A. The PLL is identified as MAIN_PLL7 HSDIV0, and this content can be obtained in the TRM of the corresponding device. Therefore, the changes made are as follows. This modification divides the previous 1GHz main frequency clock to become 500MHz. Frequency changes for other cores can also be modified using this method. After the modifications are completed, the corresponding clock frequency can be verified in Linux using the K3conf command. Similarly, customers can use the K3conf set clock $CLOCKID $FREQ command to change the clock. The Device IDs corresponding to different devices may need to be modified. For example, the IDs corresponding to C7x in AM62A are 208 and 211.

k3conf dump clock 208
k3conf dump clock 211
output:
|----------------------------------------------------------------------------------------------|
| Device ID | Clock ID | Clock Name        | Status                | Clock Frequency |
|----------------------------------------------------------------------------------------------|
| 208 | 0 | DEV_C7X256V0_C7XV_CORE_0_C7XV_CLK | CLK_STATE_READY | 500000000 |
|----------------------------------------------------------------------------------------------|
| 211 | 0 | DEV_C7X256V0_CLK_C7XV_CLK         | CLK_STATE_READY | 500000000 |
| 211 | 7 | DEV_C7X256V0_CLK_PLL_CTRL_CLK      | CLK_STATE_READY | 500000000 |

diff --git a/source/drivers/device_manager/rm_pm_hal/rm_pm_hal_src/pm/soc/am62ax/clocks.c
b/source/drivers/device_manager/rm_pm_hal/rm_pm_hal_src/pm/soc/am62ax/clocks.c
index 2122081..7438db5 100644
--- a/source/drivers/device_manager/rm_pm_hal/rm_pm_hal_src/pm/soc/am62ax/clocks.c
+++ b/source/drivers/device_manager/rm_pm_hal/rm_pm_hal_src/pm/soc/am62ax/clocks.c
@@ -2440,7 +2440,7 @@ static const struct clk_data_div_reg clk_data_hsdiv0_16fft_main_7_hsdiv0 = {
 static const struct clk_data_div_reg clk_data_hsdiv0_16fft_main_7_hsdiv0 = {
 	.data_div		= {
 		.n		= 128,
-		.default_div	= 2,
+		.default_div	= 4,
 	},
 	.reg			= 0x00680000UL + (0x1000UL * 7UL) + 0x80UL + (0x4UL * 0UL),
 	.bit			= 0,

It should be noted that after modifying the above code, a clean build of the lib files in the SDK is required. Furthermore, since the modified code runs on the DM (Device Management) core, it is also necessary to re-clean build the firmware corresponding to the DM core.