stm32mp257 Applying RT patches ，RT time abnormal

[bugman]

I applied real-time patches to the Linux kernel, but when I measured the RT performance using rt-tests, I found that these two services were affecting it:

"stm32mp-calibration.service" 

"stm32mp-calibration.timer."

What is the reason for this?

Is it appropriate to disable them?

thanks~~

[GatienC]

Hi,

The clock calibration daemon is invoking an OP-TEE service. The transition time between non-secure world <=> secure world is indeed impacting the RT performance as there is a context switch and probable interrupt masking . To minimize the latency, this service should be disabled. Clock calibration support can also be removed from OP-TEE (CFG_STM32_CLKCALIB=n (stm32mp1x) or CFG_STM32MP2_CLK_CAL=n (stm32mp2x). Isn't there a "-perf-rt" flavor?

I will enhance the wiki for the next release.

I hope this helps,
Gatien

[mike-john]

The stm32mp-calibration.service and its associated timer are likely performing periodic hardware calibration tasks specific to the STM32MP platform, such as clock or voltage calibration. These operations can introduce latency spikes or interrupt CPU scheduling, which affects real-time (RT) performance.

Yes, it is generally appropriate to disable them if:

You're running a dedicated real-time workload, and

The calibration is not critical for your specific use case or hardware stability.

However, ensure:

The system remains stable without them.

You test for any downstream effects (e.g., clock drift, peripheral instability).

You can disable them with:

sudo systemctl disable stm32mp-calibration.timer
sudo systemctl disable stm32mp-calibration.service

Then reboot and rerun your rt-tests.

[bugman]

How significant is the impact of disabling this service on the system?

Has ST conducted any evaluation or collected relevant data?

I expect the peripheral devices to operate normally under standard conditions.​

[GatienC · Accepted solution]

That's a good question to ask. Disabling this service means that the HSI clock will derive. If you have devices such as UARTs that are clocked with the HSI and this clock is not trimmed, you risk facing loss of data (Could be a derivation close to +/- 10%).

As we'll only support deep low-power modes (no wakeup from UART) with the RT flavor, I suggest to clock the peripherals with HSE (if you have a custom board, that's guessing you have one), that do not require calibration. The use of HSI is relevant, for example, when supporting light low-power modes when the CPU is in IDLE and you want to wakeup fast when typing a character in the console.

Extract from stm32mp257c datasheet :

If better tolerance is needed (for example for UART kernel clock usage), the HSI could be trimmed during run time by measuring its frequency with a better reference like HSE crystal. The HSI trimming must be done regularly or whenever there is significant variation on supply voltage or temperature.

I will enter a ticket internally so that we provide a RT device tree that do not clock UARTs with HSI.

Best regards,

Gatien

[bugman]

Thank you for your reply. I will also think about how to handle it, as well as other changes from you.