Mipi-dsi stop working

Technical Support
, ,
1

Hi there! We detect MipiDsi display, its been affected to board power restarts; this made display stop working.

Here its my tdx-info:

root@verdin-imx8mp-08742115:~# tdx-info 

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.94-7.3.0-devel #1 SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025
Kernel command line:      root=PARTUUID=3edd6186-02 ro rootwait console=tty1 console=ttymxc2,115200
Distro name:              NAME="TDX Wayland with XWayland"
Distro version:           VERSION_ID=7.3.0-devel-20250723124532-build.0
Distro variant:           -
Hostname:                 verdin-imx8mp-08742115
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Ivy
Toradex version:          0070 V1.1A
Serial number:            08742115
Processor arch:           aarch64
------------------------------------------------------------

Device tree
------------------------------------------------------------
Device tree enabled:      imx8mp-verdin-wifi-ivy.dtb
Compatible string:        toradex,verdin-imx8mp-wifi-ivytoradex,verdin-imx8mp-wifitoradex,verdin-imx8mpfsl,imx8mp
Device trees available:
                          imx8mp-verdin-nonwifi-dahlia.dtb
                          imx8mp-verdin-nonwifi-dev.dtb
                          imx8mp-verdin-nonwifi-ivy.dtb
                          imx8mp-verdin-nonwifi-mallow.dtb
                          imx8mp-verdin-nonwifi-yavia.dtb
                          imx8mp-verdin-wifi-dahlia.dtb
                          imx8mp-verdin-wifi-dev.dtb
                          imx8mp-verdin-wifi-ivy.dtb
                          imx8mp-verdin-wifi-mallow.dtb
                          imx8mp-verdin-wifi-yavia.dtb
------------------------------------------------------------

Device tree overlays
------------------------------------------------------------
Overlays enabled:         fdt_overlays=verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo
Overlays available:
                          verdin-imx8mp_dsi-to-hdmi_overlay.dtbo
                          verdin-imx8mp_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dtbo
                          verdin-imx8mp_dsi-to-lvds_panel-lvds-dual-channel-1080p_overlay.dtbo
                          verdin-imx8mp_hdmi_overlay.dtbo
                          verdin-imx8mp_hmp_overlay.dtbo
                          verdin-imx8mp_mezzanine_ov5640-27mhz-alt-jumpers_overlay.dtbo
                          verdin-imx8mp_mezzanine_ov5640-27mhz-default-jumpers_overlay.dtbo
                          verdin-imx8mp_mezzanine_ov5640-alt-jumpers_overlay.dtbo
                          verdin-imx8mp_mezzanine_ov5640-default-jumpers_overlay.dtbo
                          verdin-imx8mp_mezzanine_panel-cap-touch-10inch-lvds_overlay.dtbo
                          verdin-imx8mp_mezzanine_panel-lvds-dual-channel-1080p_overlay.dtbo
                          verdin-imx8mp_nau8822-btl_overlay.dtbo
                          verdin-imx8mp_ov5640-27mhz_overlay.dtbo
                          verdin-imx8mp_ov5640_overlay.dtbo
                          verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo
                          verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dtbo
                          verdin-imx8mp_panel-cap-touch-7inch-dsi_overlay.dtbo
                          verdin-imx8mp_spidev_overlay.dtbo
------------------------------------------------------------

And the kernel errors reported to dmesg related to mipi and capacitive touch:

[    6.791780] imx8mp-pinctrl 30330000.pinctrl: pin MX8MP_IOMUXC_SAI3_TXD already requested by leds; cannot claim for backlight-verdin-dsi
[    6.804609] imx8mp-pinctrl 30330000.pinctrl: pin-115 (backlight-verdin-dsi) status -22
[    6.815533] imx8mp-pinctrl 30330000.pinctrl: could not request pin 115 (MX8MP_IOMUXC_SAI3_TXD) from group i2s2doutdsi1bklengrp  on device 303
30000.pinctrl
[    6.830452] pwm-backlight backlight-verdin-dsi: Error applying setting, reverse things back
...

[    9.565254] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    9.574601] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    9.603900] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops 0xffffffc080ccecc0)
[    9.612126] imx_sec_dsim_drv 32e60000.mipi_dsi: version number is 0x1060200
[    9.619668] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    9.627999] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    9.661958] tpm_tis_spi spi1.1: 2.0 TPM (device-id 0x1B, rev-id 22)
[    9.671465] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops 0xffffffc080ccecc0)
...

[   35.549785] i2c i2c-1: <i2c_imx_read> read timedout
[   35.554737] ilitek_ts 1-0041: get touch info failed, err:-110
[   35.560560] ilitek_ts 1-0041: [ilitek_i2c_isr] err:-110
[   35.566052] ilitek_ts 1-0041: get touch info failed, err:-6
[   35.571706] ilitek_ts 1-0041: [ilitek_i2c_isr] err:-6
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Based on your tdx-info output, you’re running Verdin iMX8M Plus with a MIPI DSI display overlay on TorizonOS 7.3.0-devel(1). The errors indicate two main issues:

Pin Conflict Issue

The first error shows a pin multiplexing conflict(1):

pin MX8MP_IOMUXC_SAI3_TXD already requested by leds; cannot claim for backlight-verdin-dsi

This suggests the same pin is being claimed by both the LED driver and the DSI backlight driver(1). This type of conflict occurs when overlays don’t properly resolve pin conflicts(1).

MIPI DSI Bridge Attachment Failure

The second set of errors shows the MIPI DSI bridge failing to attach:

imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517

Error -517 typically indicates EPROBE_DEFER, meaning the driver is waiting for dependencies that aren’t ready(2).

Touch Controller Communication Issues

The I2C timeout errors for the touch controller suggest communication problems with the display’s touch interface:

i2c i2c-1: <i2c_imx_read> read timedout
ilitek_ts 1-0041: get touch info failed, err:-110

Troubleshooting Steps

  1. Check overlay conflicts: You’re using verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo(1). Verify no other overlays are conflicting with the same pins(1).

  2. Verify power connections: Since this started after power restarts, check all power supply connections to the display module.

  3. Test with different overlay: Try switching to the DSI-to-HDMI overlay temporarily to isolate if the issue is specific to your display:

    verdin-imx8mp_dsi-to-hdmi_overlay.dtbo

  4. Check device tree loading: Ensure your overlay is loading correctly by examining the boot log for device tree compilation errors(1).

  5. Review pin assignments: The pin conflict suggests you may need to disable conflicting interfaces in your device tree overlay(1).

Would you be able to share the contents of your overlay file or try testing with the HDMI overlay to help isolate the issue?

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

@ToradexAI Asume that this setup works in some moment and fail after power reset

4

Based on your scenario where the MIPI DSI setup worked initially but fails after power reset, this points to a hardware initialization or power sequencing issue rather than a configuration problem(1).

Power-Related Root Causes

Since the setup worked initially, the most likely causes are:

  1. Incomplete power initialization: The display may not be receiving proper power sequencing after reset
  2. I2C communication timing: The touch controller timeouts suggest the I2C bus isn’t stable during boot
  3. Pin state conflicts: The pin conflict error indicates overlapping resource claims that weren’t present during the initial working state

Immediate Troubleshooting Steps

Check Applied Overlays Status

First, verify if your overlay was applied successfully after the power reset(2):

# ls /proc/device-tree/chosen/overlays/
# cat /proc/device-tree/chosen/overlays/verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo

If the value is 0, the overlay applied successfully. Any other value indicates an application failure(2).

Verify Overlay Loading

Check if the overlay is still enabled in your configuration(2):

cat /proc/cmdline

Look for the OSTree deployment hash, then check:

ls /sysroot/boot/ostree/torizon-<hash>/dtb/overlays
cat /sysroot/boot/ostree/torizon-<hash>/dtb/overlays.txt

Recovery Options

If the overlay loading fails, you can bypass it temporarily using U-Boot(2):

setenv skip_fdt_overlays 1
boot

This will boot without any overlays to help isolate the issue(2).

Hardware Verification

Since this is power-reset related:

  1. Check display power connections: Ensure all power rails to the display are stable
  2. Verify I2C pull-ups: The touch controller timeouts suggest I2C signal integrity issues
  3. Measure power sequencing: Use an oscilloscope to verify proper power-on timing

The pin conflict error (MX8MP_IOMUXC_SAI3_TXD already requested by leds) suggests the overlay may not be properly disabling conflicting interfaces as required(1).

Would you be able to check the overlay application status and share the results of the /proc/device-tree/chosen/overlays/ check?

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Mi board image its managed by the yocto environment not the TorizonOs aproximation @ToradexAI

6

\

Thank you for clarifying that you’re using a Yocto-based Linux BSP image rather than TorizonOS. This changes the troubleshooting approach significantly.

Yocto BSP Device Tree Overlay Troubleshooting

Since you’re working with the Yocto-based Linux BSP, the overlay management is different from TorizonOS(1). Your setup shows the overlay is enabled correctly:

Overlays enabled: fdt_overlays=verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo

Pin Conflict Resolution

The primary issue is the pin conflict error(1):

pin MX8MP_IOMUXC_SAI3_TXD already requested by leds; cannot claim for backlight-verdin-dsi

This suggests multiple overlays or device tree nodes are claiming the same pin. In certain cases, multiple overlays may configure the same interfaces or hardware resources(1). When this happens, enabling more than one overlay for the same interface may lead to undesired behavior(1).

Immediate Steps for Yocto BSP

1. Check Boot Partition Overlays

Verify your overlay files in the boot partition(1):

ls /boot/overlays
cat /boot/overlays.txt

2. Remove Conflicting Overlays

Ensure that any overlapping overlays are removed before enabling the desired one(1). You can edit the overlays.txt file to disable conflicting overlays:

# Remove conflicting entries from overlays.txt
# Then sync and reboot
sync
reboot

3. U-Boot Environment Check

If the overlay loading fails, you can bypass it using U-Boot(1):

setenv skip_fdt_overlays 1
boot

4. Removing Conflicting DTO

If you find yourself with a non-working kernel after applying overlays, you can remove conflicting overlays by(1):

  • Setting up a USB-OTG connection and running UMS functionality
  • Deleting the conflicting .dtbo and corresponding item in overlays.txt

Hardware-Specific Considerations

Since this worked initially but fails after power reset, and you’re using the 10-inch DSI display, verify:

  1. Power sequencing: The display may require specific power-on timing
  2. I2C communication: The touch controller timeouts suggest bus instability
  3. Pin multiplexing: The SAI3_TXD pin conflict needs resolution at the device tree level

The error -517 (EPROBE_DEFER) in the MIPI DSI driver suggests dependencies aren’t ready during initialization, which is common after power resets when timing changes.

Would you be able to check the contents of /boot/overlays.txt and verify if any other overlays might be conflicting with the DSI display overlay?

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

7

@ToradexAI the content of overlays.txt file is

root@verdin-imx8mp-08742115:~# cat /boot/overlays.txt 
fdt_overlays=verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo

And the connected display its the official Capacitive Touch Display 10.1" DSI provided by Toradex

8

Thank you for confirming you’re using the official Capacitive Touch Display 10.1" DSI. Your overlay configuration is correct, and the issue appears to be a pin conflict that’s preventing proper initialization after power reset(1).

Root Cause Analysis

The core issue is the pin conflict error:

pin MX8MP_IOMUXC_SAI3_TXD already requested by leds; cannot claim for backlight-verdin-dsi

This suggests the SAI3_TXD pin is being claimed by both the LED driver and the DSI backlight driver(1). Since this worked initially but fails after power reset, the initialization order or timing has changed.

Troubleshooting Steps for Yocto BSP

1. Check Device Tree Loading

First, verify if the overlay loaded successfully:

dmesg | grep -i overlay
dmesg | grep -i device.tree

2. Examine Pin Conflicts

The pin conflict suggests that you need to disable any previous interface that used the same pin to avoid resource conflicts(1). Check which device is claiming the SAI3_TXD pin:

grep -r "SAI3_TXD" /sys/kernel/debug/pinctrl/

3. Verify Display Power Sequencing

Since this is power-reset related, check the display initialization:

# Check if the DSI controller is detected
ls /sys/class/drm/
cat /sys/class/drm/card*/status

4. I2C Touch Controller Debug

The touch controller timeouts suggest I2C communication issues:

# Check I2C bus status
i2cdetect -y 1
# Look for device at address 0x41 (ilitek touch controller)

Hardware Considerations

For the Verdin iMX8M Plus with the official 10.1" DSI display(2):

  • MIPI DSI output: Converted using the DSI display adapter
  • DRM Connector: Should appear as DSI-1
  • Touch Controller: Connected via I2C at address 0x41

The error -517 (EPROBE_DEFER) indicates the MIPI DSI driver is waiting for dependencies that aren’t ready during boot(2).

Immediate Resolution Steps

  1. Temporarily disable conflicting interfaces: You may need to modify your device tree to disable the LED driver that’s claiming the SAI3_TXD pin(1).

  2. Check power supply stability: Verify that all power rails to the display are stable after power reset.

  3. Test with minimal configuration: Try booting without the overlay to confirm the base system works:

    # In U-Boot
setenv skip_fdt_overlays 1
boot

  4. Verify overlay integrity: Check if the overlay file is corrupted:

    ls -la /boot/overlays/verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo

Since you’re using the official Toradex display with the correct overlay, the issue is likely related to pin resource conflicts that need to be resolved at the device tree level(1). The fact that it worked initially suggests a timing or initialization order issue that appeared after the power reset.

Would you be able to share the output of the dmesg | grep -i overlay and i2cdetect -y 1 commands to help identify the specific conflict?

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

9

@ToradexAI How GPIO conflict explain that in some moment display correctly launch and others not? And Why it is not explicit reference in Ivy mipi-dsi first step document

10

You raise an excellent point. The GPIO/pin conflict doesn’t fully explain the intermittent behavior you’re experiencing.

Why Pin Conflicts Can Be Intermittent

Pin conflicts can appear intermittent due to several factors(1):

  1. Driver Loading Order: Linux drivers load asynchronously, and the order can vary between boots. Sometimes the LED driver claims the pin first, sometimes the DSI backlight driver does(1).

  2. Timing Dependencies: The error -517 (EPROBE_DEFER) indicates the MIPI DSI driver is waiting for dependencies that may not be ready at the same time on every boot(2).

  3. Power-On Reset Timing: After a power reset, hardware initialization timing can vary, affecting which driver successfully claims resources first(1).

Documentation Gap Analysis

You’re correct that the pin conflict isn’t explicitly documented in standard MIPI DSI setup guides. This suggests the conflict may be specific to:

  • Your particular BSP version
  • Custom device tree modifications
  • Carrier board-specific configurations

The official Toradex overlays should handle pin conflicts properly, but custom modifications or BSP variations might introduce these issues(1).

Root Cause Investigation

Since this worked initially but fails intermittently after power resets, the most likely causes are:

  1. Hardware State Persistence: Some hardware states from the working session may persist until a full power cycle
  2. Initialization Race Conditions: Multiple drivers competing for the same resources with variable timing
  3. Power Supply Sequencing: The display may require specific power-on timing that varies after resets

Debugging Steps

To isolate the actual cause:

# Check driver loading order
dmesg | grep -E "(leds|backlight|mipi|dsi)" | head -20

# Verify pin usage
cat /sys/kernel/debug/pinctrl/30330000.pinctrl/pinmux-pins | grep SAI3_TXD

The intermittent nature suggests this isn’t a simple configuration error but rather a timing or initialization sequence issue that the pin conflict error is masking.

Would you be able to share the output of the driver loading sequence to help identify the actual initialization timing issue?

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

11

Hello @d.lozano,

This error does look like a device tree misconfiguration.
However, your tdx-info looks correct.

Can you try the following?

  • Reseat the DSI cable
  • Reflash the OS image

If none work, could you elaborate more on what happened before this issue started?
You mentioned board power restarts, what exactly happened?

Best Regards,
Bruno

12

Hey there! Yes it looks like, I disable the leds into DTSI file, and seems its the main conflict, but i really havent done because the documentation its really straightforward with the display bring up, and image its based yocto image with no hardware modifications.