LT8912B DSI-to-HDMI bridge: MIPI RX never locks input (sync counters stay 0) on Verdin iMX95 / Torizon — DSI host VPG also fails, upstream proven innocent

Hajun · June 4, 2026, 10:23am

**Hardware/Software**

- SoM: Toradex Verdin iMX95 Hexa 8GB WB IT V1.0B

- Carrier: custom carrier + custom DSI-to-HDMI option board based on LT8912B (U19, on i2c-2 @ 0x48/0x49)

- OS: Torizon OS 7.6.1+build.38, kernel 6.6.138-7.6.1

- Driver: lontium-lt8912b (loaded as module), bound to 2-0048

**Problem**

HDMI output is black. The LT8912B’s MIPI RX input sync/clock counters never increment — the chip never locks onto any DSI input.

0x48: 9a=00 9b=00 9c=ff 9d=ff 9e=00 9f=00

0x49: 04=00 05=00 06=00 07=00

**What I have already verified (please don’t suggest these):**

1. Chip is fully alive. On a clean cold boot, all init/config registers latch correctly to the driver’s values (0x48: 08=ff 0b=7c 31=b1 3e=d6 3f=d4; 0x49: 12=04 1a=03 1b=03 4e=ff). i2c read/write/latch all work.

2. Power rails OK — all VCCA rails measured at 1.8V.

3. Reset OK — reset GPIO statically released, correct polarity.

4. Driver enable path runs — kprobe confirms lt8912_bridge_enable → lt8912_video_on are called on every modeset, return 0, i2c writes ACK.

5. Upstream SoC display pipeline is healthy — clk_summary shows disp1pix 148.44 MHz (enabled, used by 4acf0000.dsi), dispaxi 800 MHz, mipiphypllref 24 MHz, mipiphycfg 24 MHz; crtc-0 enable=1 active=1.

6. DSI host computes PLL correctly on enable:

imx95-mipi-dsi: Fout = 445500000, best Fout = 445333333, m=167, n=9

imx95-mipi-dsi: adj clock 148500 for mode “1920x1080”

7. Schematic DSI lane mapping is clean — DSI_1_D0..D3/CK map straight to MIPI_RX0..3/CK with correct P/N polarity, no swap.

**The decisive test — DSI host VPG also fails:**

I enabled the DSI host’s built-in Video Pattern Generator (/sys/kernel/debug/4acf0000.dsi/vpg), which makes the DSI controller transmit its own test pattern, bypassing the DPU, pixel_interleaver, and pixel_link entirely. Even with vpg=1 and a fresh modeset, the LT8912B sync counters stay at 0 and the screen stays black.

=> This proves the entire upstream pipeline is innocent. The wall is strictly between the DSI PHY output and the LT8912B MIPI input — either a physical/lane issue or a DSI format the chip won’t lock onto.

**My questions:**

1. On i.MX95 (or i.MX8-family) DSI, is continuous DSI clock required for the LT8912B to lock its MIPI RX? Does the imx95-mipi-dsi / dw-mipi-dsi host default to non-continuous clock, and if so, how do I force continuous clock (DT property or driver flag)? My current symptom (counters all 0) matches a chip that never sees a clock.

2. Is there a known requirement for burst mode vs non-burst/sync-event with LT8912B on i.MX DSI? The upstream lontium-lt8912b driver attaches with MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_NO_EOT_PACKET (no burst). When I rebuilt the module with MIPI_DSI_MODE_VIDEO_BURST added, it panics in lt8912_video_on (regmap path) — which suggests the driver’s video_on timing isn’t written for burst. Has anyone gotten burst working with this bridge, and what timing changes were needed?

3. Is there any way, without a high-bandwidth scope (I can’t probe the 445 MHz differential pairs on the QFN64), to confirm whether the DSI PHY actually enters HS and toggles the clock lane? The dw_mipi_dsi / imx95_mipi_dsi modules have no dynamic_debug callsites for the PHY HS/PLL-lock stage, so I can’t trace it via dyndbg.

Any pointers on the clock-continuous setting or a known-good DSI configuration for LT8912B on Verdin iMX95 would be hugely appreciated.

ToradexAI · June 4, 2026, 10:23am

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 understand you’re experiencing MIPI DSI synchronization issues with the LT8912B bridge on your Verdin iMX95. Based on the community discussions and documentation, here are some insights that may help:

Clock Configuration and Continuous Clock Mode

For MIPI DSI clock configuration on Toradex modules, the clock settings are typically managed through device tree properties(1). The continuous clock requirement you mentioned is a common issue with DSI bridges. While the sources don’t specifically mention the iMX95 DSI controller’s continuous clock configuration, similar issues have been reported on other Verdin modules(2).

DSI Mode Configuration

The community discussions show that DSI mode configuration can be critical for proper bridge operation(2). Your current mode flags (MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_NO_EOT_PACKET) appear standard, but the panic when adding MIPI_DSI_MODE_VIDEO_BURST suggests timing incompatibility.

Debugging DSI PHY Activity

For debugging DSI PHY activity without high-bandwidth probes, the community has used kernel tracing methods(3). You can enable function tracing to monitor DSI driver calls:

echo function > /sys/kernel/tracing/current_tracer
echo "*dsi*" > /sys/kernel/tracing/set_ftrace_filter
echo 1 > /sys/kernel/tracing/tracing_on

(3)

Clock Verification

To verify clock status, you can examine the clock summary as you’ve done, and also check(4):

cat /sys/kernel/debug/clk/clk_summary

(4)

Recommendations

Given your thorough testing and the VPG test failure, this appears to be a low-level DSI PHY configuration issue. The fact that your sync counters remain at zero strongly suggests either:

Clock continuity issue - The DSI PHY may not be providing continuous clock
Lane mapping or differential signaling issue - Despite clean schematic mapping
DSI timing parameters - The bridge may require specific timing that differs from default

Next Steps

I’d recommend checking if there are any Verdin iMX95-specific device tree properties for DSI clock configuration. You might also want to examine the exact DSI timing parameters being sent to ensure they match the LT8912B’s requirements.

The community discussions suggest that MIPI DSI issues often require platform-specific configuration adjustments(2)(4).

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 · June 4, 2026, 3:11pm

Thank you for the suggestions, but I have already tried all four of these in my debugging, and I need to point out why they don’t apply here — I had hoped to avoid generic guidance by listing my prior work in the original post.

1. function tracer (echo function > current_tracer):

This kernel does NOT have the function tracer built in. On this board:

cat /sys/kernel/tracing/available_tracers

=> blk nop

So “echo function > current_tracer” returns “write error: Invalid argument”, and set_ftrace_filter is meaningless. I already worked around this using kprobe_events instead (p:lt8912_bridge_enable, p:lt8912_video_on with $retval), which confirmed the driver’s enable path runs and video_on returns 0.

2. clk_summary:

Already done and included in my original post. All display clocks are enabled and correct (disp1pix 148.44 MHz, dispaxi 800 MHz, mipiphypllref/mipiphycfg 24 MHz). This is exactly why I concluded the SoC-side clocking is healthy.

3. dynamic_debug for DSI PHY:

Already tried. The dw_mipi_dsi / imx95_mipi_dsi modules have NO dynamic_debug callsites for the PHY HS-entry / PLL-lock stage:

grep -c “lontium-lt8912b” /sys/kernel/debug/dynamic_debug/control => 0

The DSI host only logs PLL math (Fout/m/n), nothing about whether the PHY actually enters HS or toggles the clock lane. That is precisely the gap I asked about in question 3.

4. continuous clock “managed through device tree”:

This is the heart of my question, and “it’s a device tree property” is not an answer. WHICH property, on the imx95-mipi-dsi node, forces continuous clock? Is the default continuous or non-continuous on i.MX95? That specific detail is what I need.

To be clear about my setup and situation:

- I am NOT using an EVK. This is a custom carrier board + custom DSI-to-HDMI option board that I designed and built myself, which is exactly why platform-specific reference data matters and why generic checklists don’t resolve it.

- I am based in Korea, and I cannot even post to this forum from a Korean network connection — I have to go through a VPN every single time just to participate. This is a real and ongoing obstacle to reporting issues against your hardware.

With respect, an AI assistant repeating documentation links is not what I need here. The i.MX95 is a new SoC with very little field-tested DSI + external-bridge reference material, and I have already done the full upstream elimination (chip, power, reset, clocks, driver enable path, VPG bypass).

Could a human Toradex or NXP engineer with hands-on i.MX95 DSI experience please respond directly? Specifically:

- the exact DT property / default for continuous vs non-continuous DSI clock on imx95-mipi-dsi, and

- whether LT8912B is known to require continuous clock or burst mode on this controller.

I would really appreciate a real engineer taking a look.

ToradexAI · June 4, 2026, 3:11pm

I understand your frustration with the generic guidance. You’re absolutely right that you need specific technical details for the iMX95 DSI configuration, not general troubleshooting steps.

Verdin iMX95 DSI Configuration

Looking at the available Toradex documentation, the Verdin iMX95 does support DSI interfaces (1). However, the specific DSI controller configuration details you’re asking about (continuous vs non-continuous clock mode, burst mode requirements) are not explicitly documented in the available sources for the iMX95.

Available Overlays

The documentation shows that Verdin iMX95 has these DSI-related overlays available (1):

verdin-imx95_dsi-to-hdmi_overlay.dtbo
verdin-imx95_panel-cap-touch-10inch-dsi_overlay.dtbo
verdin-imx95_panel-cap-touch-7inch-dsi_overlay.dtbo

Community Experience with Similar Issues

From the community discussions, there are some relevant insights about DSI bridge configuration on other Toradex platforms (2):

Custom display setups often require specific device tree modifications beyond standard overlays
MIPI DSI interface configuration can be critical for bridge compatibility
Some bridges have specific requirements for clock modes and data transmission formats

Your Specific Technical Questions

Unfortunately, the available documentation doesn’t contain the specific technical details you need:

Continuous clock DT property: The exact device tree property name for forcing continuous clock on imx95-mipi-dsi is not documented in the available sources
LT8912B requirements: There’s no specific information about LT8912B compatibility or requirements with iMX95 DSI
Default clock mode: Whether iMX95 defaults to continuous or non-continuous clock mode is not specified

Recommendation

Given the technical depth of your question and the fact that you’ve already eliminated the upstream pipeline through VPG testing, this appears to require direct engineering support. The iMX95 is indeed a newer SoC with limited field documentation for complex DSI bridge scenarios.

You may find relevant discussions on the Toradex Community by searching for “iMX95 DSI” or “LT8912B”, though the specific technical parameters you need may require direct engineering consultation.

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.

alex.tx · June 4, 2026, 5:28pm

I can only confirm that a Verdin iMX95 Hexa 8GB WB IT V1.0C module, installed on a Toradex Verdin Development Board and running the 7.6.1 image, successfully initializes the LT8912B bridge and provides proper HDMI functionality when used with the Toradex DSI-to-HDMI Adapter and the verdin-imx95_dsi-to-hdmi_overlay.dtbo overlay.

The Toradex DSI-to-HDMI Adapter is based on the LT8912B MIPI DSI-to-HDMI bridge.

Please compare your schematic with either the Toradex DSI-to-HDMI Adapter or the Yavia carrier board, which includes the LT8912B bridge on-board. Please also verify your device tree configuration using the mentioned overlay as a reference.

Hajun · June 5, 2026, 12:14am

Thanks for confirming the working reference (V1.0C + Verdin Development Board + 7.6.1 + verdin-imx95_dsi-to-hdmi_overlay.dtbo + Toradex DSI-to-HDMI Adapter) and for the schematic/overlay pointers.

A few points and constraints from my side:

Carrier board: I only have the Mallow carrier, not the Verdin Development Board, and I don’t plan to purchase additional Toradex hardware for this. If I can’t get it working on the current setup, I’ll fall back to the Verdin iMX8M Plus.
HDMI adapter: I’m not using the genuine Toradex DSI-to-HDMI Adapter. I built my own LT8912B-based adapter module, and its schematic and hardware have already been verified. The only circuit-level difference from the reference is on the HDMI-input register side, which I’ve already accounted for in the device tree (only that part was changed).
Module revision: Per the official revision history, the only change from V1.0B to V1.0C is the eMMC vendor (SwissBit → Micron); the SoC silicon (B0), DSI PHY, and power-supply filtering are identical. So the B vs C difference doesn’t look like a plausible root cause for the DSI/HDMI behavior. Please correct me if there is a DSI-PHY-relevant change I’m missing.

For context, on my board the LT8912B initializes correctly (ID 0x12 / 0xb2, init and MIPI-bank registers latch as expected, i2c read/write/latch all fine), but it never detects MIPI input video sync (0x9a/9b/9e/9f = 0). This is identical across OS generations (Yocto 7.6.0 / kernel 6.6.129 and Torizon 7.6.1 / 6.6.138 both show 0x9c-0x9f = ff,ff,00,00), which makes a pure-software root cause unlikely. Even the DSI host’s internal Video Pattern Generator (VPG) - which bypasses the DPU, pixel-interleaver, and pixel-link entirely - produces no sync, so the whole upstream pipeline is cleared. The remaining gap is the “DSI PHY output ↔ LT8912B MIPI input” segment, most likely the differential routing of my custom adapter through the 24-pin 2 mm DSI header, which the direct Toradex adapter avoids.

My questions:

Is there any known fundamental limitation of the i.MX95 DSI PHY driving an external LT8912B over a custom adapter, compared to the validated direct-adapter reference? This directly affects our decision to stay on i.MX95 or move to the iMX8M Plus.
For the working reference, could you share the Toradex DSI-to-HDMI Adapter schematic, especially the DSI differential and connector-header routing, so I can compare it against my custom adapter?
In the reference overlay, what DSI settings are expected (number of data-lanes, continuous vs non-continuous clock, burst vs non-burst video mode)? I’ll diff my device tree against the dts you linked.

Thanks again for the help.

alex.tx · June 5, 2026, 5:41pm

I only suggested using the Toradex implementation as a known-good reference to verify your LT8912B integration. There was no intention to suggest that you need to purchase additional hardware.

We have tested the Verdin iMX95 with the Toradex DSI-to-HDMI Adapter on Verdin carrier boards and Dahlia carrier board. There is also an LT8912B-based implementation on the Yavia carrier board. Therefore, we are not aware of a fundamental limitation of the i.MX95 DSI PHY preventing operation with the LT8912B.

For a custom implementation, the main risk is an implementation mismatch in hardware, device tree, or driver configuration.

If the hardware and software integration are both correct, the LT8912B should work. We do not have any non-public or “secret” LT8912B configuration beyond what is used in our publicly available schematics and software sources.

All module changes are listed in the module revision history. In addition, the DSI signals are routed directly from the SoC to the module edge connector, so minor module revision changes are not expected to affect DSI functionality.

The adapter schematic is available on the product page. I posted the link in my previous reply.

The expected DSI configuration for the LT8912B is:

Data lanes: 4 lanes
Clock mode: continuous clock
Video mode: non-burst video mode
Sync mode: sync-event / non-burst mode

Please note that the number of DSI lanes is defined in the device tree endpoint, while mode flags such as burst/non-burst and continuous/non-continuous clock are typically set by the bridge or panel driver when it attaches to the DSI host, rather than directly by the overlay.