[Verdin iMX95 BSP 7.6.0] DSI-to-HDMI (LT8912B) No Display — imx95-pixel-interleaver fails to create device link with display-controller (fw_devlink cycle)

Hajun · May 7, 2026, 12:10pm

[Verdin iMX95] DSI-to-HDMI (LT8912B) Not Working — imx95-pixel-interleaver Failed to Create Device Link

Environment

Item	Detail
SoM	Verdin iMX95 Hexa 8GB WB IT V1.0B (S/N: 12594470)
Carrier Board	Custom carrier board (Mallow-compatible socket)
DSI Adapter	Custom expansion module with Lontium LT8912B (DSI-to-HDMI bridge)
OS Image	TDX Wayland with XWayland 7.6.0+build.14 (Reference Multimedia Image)
Kernel	6.6.129-7.6.0
Base DTB	`imx95-verdin-wifi-dev.dtb`
Active Overlays	`verdin-imx95_dsi-to-hdmi_overlay.dtbo`, `verdin-imx95_spidev_overlay.dtbo`

Background / Setup

This setup uses a custom carrier board (not the official Dahlia or Mallow) designed around the Mallow SOM socket. The board has the following relevant hardware:

LT8912B DSI-to-HDMI bridge connected to I2C_2_DSI (SODIMM pins 53/55, lpi2c3, 42530000.i2c, bus i2c-2) at addresses 0x48 and 0x49
DSI signals all routed to the LT8912B expansion module socket
No on-board GPIO expander at i2c-1 (0x21) — only the SOM-internal pca953x 0-0020 is present

Image Recovery

The board was originally running a minimal image. Since the custom board lacks USB pinctrl for RNDIS/UMS recovery and has no recovery button or accessible SODIMM Pin 246, USB-based TEZI recovery was not possible.

Recovery was performed manually via USB RNDIS (usb0: 192.168.11.1/24) using HTTP + dd:

Flashed imx-boot to /dev/mmcblk0boot0
Extracted rootfs.bootfs.tar.xz to mmcblk0p1 (FAT)
Extracted rootfs.tar.xz to mmcblk0p2 (ext4)
Applied u-boot-initial-env-sd via fw_setenv -s

After recovery, the board boots successfully into TDX Wayland with XWayland 7.6.0+build.14.

Overlay Modification

The stock verdin-imx95_dsi-to-hdmi_overlay.dtbo references lpi2c4 (42540000.i2c), but the LT8912B is physically connected to lpi2c3 (42530000.i2c, i.e., i2c-2). This was corrected by decompiling the DTB overlay with dtc, changing lpi2c4 → lpi2c3 in __fixups__, recompiling, and deploying.

Verification:

i2cdetect -y 2
# 0x48, 0x49 detected (UU — driver bound)
ls -la /sys/bus/i2c/devices/2-0048/driver
# → .../bus/i2c/drivers/lt8912

LT8912B is correctly detected and driver-bound on i2c-2.

Problem Description

Despite the LT8912B driver binding successfully, HDMI output never works. Weston fails to start, and no CRTC is created.

Key dmesg errors (every boot):

[9.223] imx95-dpu 4b400000.display-controller: [drm] Cannot find any crtc or sizes
[9.237] imx95-dpu 4b400000.display-controller: [drm] Cannot find any crtc or sizes
[9.239] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller

Weston log:

DRM: head 'HDMI-A-1' found, connector 41 is connected
Failed to lookup init function: /lib/libgbm.so.1: undefined symbol: gbm_surface_get_in_fence_fd
no available modes for HDMI-A-1
Cannot configure an output using weston_drm_output_api.

DRM state:

ls /sys/class/drm/card0/crtc*
# (empty — no CRTC registered)

cat /sys/class/drm/card0-HDMI-A-1/status
# connected

Root Cause Analysis

Source code review

After reviewing the BSP kernel source (toradex_6.6-2.2.x-imx):

imx95-pixel-interleaver.c: No device_link_add call found. The driver only calls drm_bridge_add() and of_drm_find_bridge().
dpu95-kms.c (dpu95_kms_prepare → dpu95_kms_init_encoder_per_crtc): Calls drm_bridge_attach() which traverses the full bridge chain (DPU → pixel-interleaver → pixel-link → MIPI-DSI → LT8912B).

Actual cause: `fw_devlink` circular dependency

The Failed to create device link (0x180) error originates from the Linux fw_devlink subsystem (not the driver code itself), which automatically creates device links from DTB phandle references. The display pipeline has a circular dependency:

/soc/display-controller@4b400000  ←→  /soc/bridge@4b0d0000/channel@0

Both devices reference each other via OF graph endpoints. When fw_devlink tries to enforce probe ordering, it detects the cycle and the device_link_add call fails with -EINVAL, causing imx95-pixel-interleaver probe to fail. Without a registered bridge, imx95-dpu cannot build the DRM pipeline and reports “Cannot find any crtc or sizes”.

Confirmed by kernel boot log:

[0.041] /soc/bridge@4b0d0000/channel@0: Fixed dependency cycle(s) with /soc/display-controller@4b400000
[0.041] /soc/display-controller@4b400000: Fixed dependency cycle(s) with /soc/bridge@4b0d0000/channel@0

Attempted Workarounds

1. `fw_devlink=off`

fw_setenv tdxargs "fw_devlink=off"

Result: Circular dependency resolved — but new error appeared:

imx95-pixel-interleaver 4b0d0000.bridge: failed to request irq: -13 (EACCES)
imx95-pixel-interleaver: probe of 4b0d0000.bridge failed with error -13

With fw_devlink=off, irq_imx_irqsteer (the interrupt mux for the display subsystem) probes after imx95-pixel-interleaver, so the IRQ request fails with -EACCES.

2. `fw_devlink=permissive`

fw_setenv tdxargs "fw_devlink=permissive"

Result: Same as default — Failed to create device link (0x180) still occurs. permissive mode does not suppress the cycle detection failure.

3. Manual unbind/bind

echo "4b0d0000.bridge" > /sys/bus/platform/drivers/imx95-pixel-interleaver/unbind
echo "4b0d0000.bridge" > /sys/bus/platform/drivers/imx95-pixel-interleaver/bind
echo "4b400000.display-controller" > /sys/bus/platform/drivers/imx95-dpu/unbind
echo "4b400000.display-controller" > /sys/bus/platform/drivers/imx95-dpu/bind

Result: imx95-dpu rebind fails with -EEXIST because lt8912 already registered its DSI device during the first probe attempt (devm_mipi_dsi_device_register_full), and the second attempt finds a duplicate entry.

Additional Context

Same issue exists on SMARC iMX95 with DSI-to-HDMI adapter (community thread)
The mainline kernel patch series (October 2025, Marek Vasut) reworks pixel-interleaver and pixel-link drivers to remove inter-channel dependencies, and confirms: “Both DSI-to-HDMI path using LT8912 bridge and LVDS single-lane were tested on Toradex i.MX95 Verdin EVK v1.2” — but these changes are not yet in the Toradex BSP 7.6.0

Questions

Is there a known fix or patch for imx95-pixel-interleaver probe failure due to fw_devlink circular dependency in BSP 7.6.0?
Is there a pre-built kernel-devsrc or cross-compilation SDK available to rebuild the imx95_pixel_interleaver.ko module with a fix (e.g., returning -EPROBE_DEFER instead of -EINVAL on device_link_add failure)?
Is BSP 7.7.0 or a nightly build expected to include the mainline pixel-interleaver rework that resolves this?

Full dmesg (display-related excerpt)

[    8.670] lt8912 2-0048: supply vccmipirx not found, using dummy regulator
[    8.697] lt8912 2-0048: supply vcchdmipll not found, using dummy regulator
[    9.174] [drm] Initialized imx95-dpu 1.0.0 20230213 for 4b400000.display-controller on minor 0
[    9.188] imx95-dpu 4b400000.display-controller: [drm] Cannot find any crtc or sizes
[    9.201] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller
[    9.214] imx95-dpu 4b400000.display-controller: [drm] Cannot find any crtc or sizes

Posted by: Verdin iMX95 custom carrier board developer BSP: 7.6.0+build.14 | Kernel: 6.6.129-7.6.0 | Date: May 2026

ToradexAI · May 7, 2026, 12:10pm

Hi, I’m the Toradex AI Assistant.

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

I’d be glad to help with your Verdin iMX95 DSI-to-HDMI display issue! Could you let me know which OS and version you are using?

To help me provide the most accurate guidance for your specific setup, please also run the tdx-info command on your device and share the output. You can find more information about this command at https://developer.toradex.com/software/development-resources/tdx-info/.

Common platforms include:

Hardware: Verdin i.MX8M Plus, Verdin AM62, Aquila AM69, Apalis i.MX8QP, Colibri i.MX8X, Ivy Carrier Board, Ixora Carrier Board, Mallow Carrier Board, IMX95
Operating System: Yocto 7.2.0, Torizon 6.8.2, Torizon OS 6, BSP 7, BSP 6, Torizon OS 7.2.0-build.13
Implementation: Docker, Chromium, Qt, weston
Integration: Device tree, gpio, spi, can, hdmi, display, camera, recovery mode, device driver, kernel patch, ethernet, rpmsg, lvds

Once I have this information, I can provide specific guidance for your DSI-to-HDMI configuration and the fw_devlink circular dependency issue you’re experiencing.

Best regards, Toradex AI Assistant.

Did you like my answer?

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

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

Hajun · May 8, 2026, 12:17am

root@verdin-imx95-12594470:~# sh /tmp/tdx-info

Software summary

Bootloader: U-Boot

Kernel version: 6.6.129-7.6.0 #1 SMP PREEMPT Thu Mar 26 15:16:22 UTC 2026
Kernel command line: root=PARTUUID=5805e274-02 ro rootwait console=tty1 console=ttyLP2,115200 fw_devlink=permissive
Distro name: NAME=“TDX Wayland with XWayland”
Distro version: VERSION_ID=7.6.0-build.14
Distro variant: -
Hostname: verdin-imx95-12594470

Hardware info

HW model: Toradex Verdin iMX95 WB on Verdin Development Board

Toradex version: 0089 V1.0B
Serial number: 12594470
Processor arch: aarch64
Available block devices:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 28.8G 0 disk
mmcblk0p1 179:1 0 48M 0 part /boot\x0a/run/media/BOOT-mmcblk0p1
mmcblk0p2 179:2 0 28.8G 0 part /
mmcblk0boot0 179:8 0 31.5M 1 disk
mmcblk0boot1 179:16 0 31.5M 1 disk

root@verdin-imx95-12594470:~# tdx-info -dt

Device tree

Device tree enabled: imx95-verdin-wifi-dev.dtb

Compatible string: toradex,verdin-imx95-wifi-devtoradex,verdin-imx95-wifitoradex,verdin-imx95fsl,imx95
Device trees available:
imx95-verdin-nonwifi-dahlia.dtb
imx95-verdin-nonwifi-dev.dtb
imx95-verdin-nonwifi-ivy.dtb
imx95-verdin-nonwifi-mallow.dtb
imx95-verdin-nonwifi-yavia.dtb
imx95-verdin-wifi-dahlia.dtb
imx95-verdin-wifi-dev.dtb
imx95-verdin-wifi-ivy.dtb
imx95-verdin-wifi-mallow.dtb
imx95-verdin-wifi-yavia.dtb

Device tree overlays

Overlays enabled: fdt_overlays=verdin-imx95_dsi-to-hdmi_overlay.dtbo verdin-imx95_spidev_overlay.dtbo

Overlays available:
verdin-imx95_dsi-to-hdmi_overlay.dtbo
verdin-imx95_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx95_mezzanine_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx95_mezzanine_panel-lvds-dual-channel-1080p_overlay.dtbo
verdin-imx95_nau8822-btl_overlay.dtbo
verdin-imx95_ov5640-27mhz_overlay.dtbo
verdin-imx95_ov5640_overlay.dtbo
verdin-imx95_panel-cap-touch-10inch-dsi_overlay.dtbo
verdin-imx95_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx95_panel-cap-touch-7inch-dsi_overlay.dtbo
verdin-imx95_reserve-cm7-uart_overlay.dtbo
verdin-imx95_spidev_overlay.dtbo

ToradexAI · May 8, 2026, 12:18am

Thank you for providing the detailed information! I can see you’re running TDX Wayland with XWayland 7.6.0-build.14 on a Verdin iMX95 Hexa 8GB WB IT V1.0B with the DSI-to-HDMI overlay enabled.

Issue Analysis

Based on your detailed description and the available documentation, you’re encountering a known issue with the fw_devlink circular dependency between the display controller and pixel interleaver on Verdin iMX95 (1). The error you’re seeing:

imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller

This is indeed related to the circular dependency in the device tree graph between the display pipeline components (1).

Current Status and Recommendations

Device Tree Overlay Configuration

Your current overlay configuration shows you’re using the correct overlay for DSI-to-HDMI functionality (2):

Enabled: verdin-imx95_dsi-to-hdmi_overlay.dtbo (2)
Base DTB: imx95-verdin-wifi-dev.dtb

The documentation confirms that this overlay is available for Verdin iMX95 starting from BSP version 7.3.0 (2).

Troubleshooting Steps

Verify I2C Connection: Since you mentioned the LT8912B is connected to lpi2c3 instead of lpi2c4, ensure your modified overlay correctly targets the right I2C bus.
Check Display Pipeline: The Verdin iMX95 uses a complex display pipeline that includes the pixel interleaver component (1).

Alternative Approaches

Given the complexity of the fw_devlink issue you’re experiencing, you might consider:

Try Different Base DTB: Test with other available device trees like imx95-verdin-wifi-mallow.dtb since you mentioned using a Mallow-compatible socket.
Overlay Combinations: The documentation shows several display-related overlays available for Verdin iMX95 (2). You might try temporarily disabling the spidev overlay to isolate the display issue.

Support Resources

This appears to be a complex kernel-level issue that may require specific patches or kernel modifications. Based on the community discussion, similar fw_devlink issues have been reported (3).

For this specific kernel-level fw_devlink circular dependency issue, I recommend reaching out to Toradex support directly through the official channels, as this may require:

Specific kernel patches for the pixel interleaver driver
Updated device tree configurations
Potential BSP updates

The issue you’re experiencing appears to be at the kernel driver level and may need specialized support beyond what can be addressed through standard configuration changes.