MIPI DSI Flicker — Root Cause Investigation

1. The problem

An i.MX 8M Mini SoC drives a SN65DSI83 MIPI-DSI → LVDS bridge into an LCD panel. Under steady-state operation the display sometimes flickers. Initial hypothesis: a MIPI bit-error or signal-integrity issue on the CLK or data lanes.

2. Investigation summary

3. Key data

3.1 Continuous video (hold) — baseline

3.2 Video on/off cycling

3.3 Unlock pulse-width distribution

4. Mechanism

                  PUT /video stop arrives
                      │
                      │ ~5 ms     HTTP / Flask processing
                      │ ~50-150ms App + GStreamer pipeline tears down
                      │           (state goes to NULL)
                      ▼
              DSIM driver disables HS_CLK_EN  ──────►  ~230 ms after stop
                      │
                      ▼
              MIPI CLK lane goes to LP-11
                      │
                      ▼
              SN65DSI83 sees no reference clock
                      │
                      ▼
              PLL drops lock          ◄── csr_e5.pll_unlock = 1 caught here
                                            (pulse width 15-45 ms)
                      │
                      ▼
              PLL re-acquires to "no-signal" idle state
                      │
                  (~500 ms OFF window)
                      │
                  PUT /video start
                      ▼
              DSIM re-enables HS_CLK_EN; MIPI traffic resumes
                      │
                      ▼
              SN65DSI83 PLL has to re-acquire to the new clock
                      │      (~10-30 ms, LVDS output is garbage during this)
                      ▼
              ──── visible flicker on the panel ────

The bridge is behaving correctly: a PLL is expected to lose lock when its reference clock disappears. The defect is upstream — the act of stopping the video drops the MIPI HS-clock, which puts the bridge through an unlock-relock cycle every time, and the next start has to re-acquire from cold. That re-acquisition window is the visible flicker.

5. Recommended fix

Two orthogonal options. Either should eliminate the flicker.

5.1 Don't tear the pipeline down

In the device-side video stack, change the "stop" path from a full teardown to a soft pause that keeps the DSI HS-clock running. For GStreamer:

// Today  (causes flicker):
gst_element_set_state(pipeline, GST_STATE_NULL);

// Proposed:
gst_element_set_state(pipeline, GST_STATE_PAUSED);

PAUSED retains the pipeline graph and buffers — and, importantly, doesn't trigger the bridge-disable path in the i.MX DSIM driver, so HS-CLK stays on and the SN65 PLL stays locked through the transition. Resume is near-instant and visually clean.

5.2 Don't stop video in production

If the only reason /video stop is called in real deployments is the flicker test harness itself, the flicker mode is purely an artefact of the test. Production code that starts the stream once at boot and leaves it running will see zero PLL unlocks (confirmed empirically — 0 unlocks in 10 min 51 s of continuous video).

5.3 Verify the fix

Once the device server gains a soft-stop action (e.g. {"action": "pause"}), compare_stops.py in this repo runs an A/B test automatically:

STYLES = [
    ("stop_full",  {"action": "start", "mode": "static-pink"}, {"action": "stop"}),
    ("stop_pause", {"action": "start", "mode": "static-pink"}, {"action": "pause"}),
]
$ python3 compare_stops.py --cycles 30

A successful fix will show ~0.5 unlocks/cycle for stop_full and 0.00 for stop_pause.

6. Tools developed

7. Open questions

• The rare catastrophic black-screen mode. Most unlocks recover cleanly within ~40 ms. Twice during the investigation a flicker resulted in a persistent black screen. That is presumably the same root cause but where PLL re-acquisition fails outright; eliminating the trigger should eliminate the rare variant too, but worth confirming with extended runs.
• The 8 % of "good" sessions that contained early unlock activity. One f press on 11 May (08:33:28) had zero PLL activity in the preceding minute, suggesting either an observation false-positive or a separate, sub-poll-rate fault path. Worth keeping the sn65_monitor running in any future regression testing to catch.
• Device-side endpoint additions. Three small additions would close out the diagnostic kit:
  • POST /video support for action=pause (GStreamer GST_STATE_PAUSED)
  • /registers to expose the runtime DSIM registers DSIM_STATUS, DSIM_CLKCTRL, DSIM_INTSRC, DSIM_FIFOCTRL alongside the existing PHY-timing config registers
  • GET /video/state exposing the GStreamer pipeline state (NULL / READY / PAUSED / PLAYING), which would let us time-correlate the actual pipeline state transitions with the PLL unlock window