Last edited 6 days ago

DRM KMS troubleshooting grid

Applicable for STM32MP13x lines, STM32MP15x lines, STM32MP25x lines

The table below contains some typical issues related to the DRM/KMS framework, as well as solutions or debugging methods.

If your issue is not listed, refer to the articles in the DRM/KMS or troubleshooting grids categories.


Symptom Resolution
 ./myQtApplication
Could not queue DRM page flip! (Permission denied)
Could not queue DRM page flip! (Permission denied)

The psplash-drm userland splash screen is running and is then the DRM master, avoiding other DRM applications to access to DRM/KMS. Stop this psplash-drm application with the command below before running your use case:

 psplash-drm-quit

Note: You may need to enter "export QT_QPA_EGLFS_ALWAYS_SET_MODE=1" before running your Qt application. For further information, refer to the Qt documentation.

 echo 32 > /sys/class/backlight/5a000000.dsi.0/brightness
sh: write error: No such device or address

On this board, the panel backlight is related to a MIPI® DSI panel. This backlight can be modified only if the panel is already powered on. That is probably not the case here.
The panel must restart before modifying its backlight. To do so, start any display-related application. For further information, refer to DRM KMS overview and Wayland Weston overview articles.

I/TC: Resumed
E/TC:0   tzc_it_handler:79 TZC permission failure
E/TC:0   dump_fail_filter:417 Overrun violation on filter 0
E/TC:0   dump_fail_filter:420 Permission violation on filter 0
E/TC:0   dump_fail_filter:425 Violation @0xdce1ff80, non-secure
unprivileged read, AXI ID 403
E/TC:0   Panic at core/arch/arm/plat-stm32mp1/plat_tzc400.c:84
<tzc_it_handler>
E/TC:0   TEE load address @ 0xde000000

This trace indicates that the TZC internal peripheral is detecting a "permission violation" made by the master whose AXI ID is 0x403. It corresponds to the LTDC internal peripheral (LTDC NSAID=0b0011. For further information, refer to the STM32 reference manuals).
Some Linux® Kernel DRM/KMS module drivers are probably missing in the system. As there is probably a display splashscreen in U-Boot, the LTDC display internal peripheral is clocked and is running. When the user initiates the power sequence, as there is no DRM/KMS driver in the system, the display-related clocks are not switched off. The LTDC then continues to make erratic illegal accesses to the memory, that are catched by the TZC internal peripheral. OP-TEE/TZC detects this abnormal behavior and then stops the system and logs this trace.
To fix this issue, please update your Linux® Kernel configuration with all the missing drivers.

 dmesg | grep -i ltdc
[  341.85] [drm] ltdc fifo underrun: please verify display mode
[ 1045.48] [drm] ltdc fifo underrun: please verify display mode

The "LTDC fifo underrun" messages occur when the LTDC input fifo is not filled fast enough. These messages may appear occasionally (during the display initialization for instance) and are often non-blocking. However, it happens that these messages are numerous, generating display problems like visual artifacts and this can come from:

  • the system configuration: maybe some parameters are missing or are incorrect in the DDR controller, the DDR driver or the AXI configuration
  • the system dynamic performance: maybe the dynamic voltage and frequency scaling (DVFS) policy is improper for the use case
  • a too high display pixel clock frequency due to a too important display resolution for the platform
  • a too complex display configuration using several LTDC "layers" for the display composition
  • a use case that is too “heavy” for the platform, using too much of the DDR bandwidth (high cpu load, large ethernet transfer, usb, gpu, npu...) and leaving too little DDR bandwidth for LTDC
  • a combination of the above cases

To fix this problem, check your DDR & AXI system parameters, adjust the DVFS policy, decrease the display resolution, use a single LTDC layer for the display composition, monitor the system with Linux monitoring tools and the DDR usage with DDRPERFM internal peripheral, "simplify" the use case...