MIPI D-PHY Analysis Report

Generated: 2026-04-10 08:01:00  |  Scope: Captures 0138–0167  |  Model: claude-opus-4-6

# MIPI D-PHY Signal Integrity Analysis Report

## 1. Executive Summary

The system has a critical SoT (Start-of-Transmission) timing defect that causes intermittent bridge lock failure at ~13% rate. The root cause is twofold: (a) the DSIM PHY timing registers are programmed with values significantly below your target spec, shortening THS_PREPARE and THS_ZERO to the point where LP-01→LP-00 states are marginally detectable; and (b) a non-deterministic race condition at the PHY level causes the LP-low plateau to occasionally collapse from ~342 ns to 0 ns, eliminating the SoT entry sequence entirely. The SN65DSI83 cannot detect SoT, fails to lock, and the display flickers for the entire session.

## 2. Register Analysis — The Smoking Gun

### Actual vs. Target Register Values

| Register | Target | Actual | Status |
|---|---|---|---|
| PHYTIMING (0xb4) | `0x00000306` | `0x00000305` | WRONG |
| PHYTIMING1 (0xb8) | `0x03110A04` | `0x020e0a03` | WRONG |
| PHYTIMING2 (0xbc) | `0x00040A03` | `0x00030605` | WRONG |

### Field-by-Field Decode (all 30 captures show identical wrong values)

| Field | Target (byte-clk) | Target (ns) | Actual (byte-clk) | Actual (ns) | Spec Min (ns) | Status |
|---|---|---|---|---|---|---|
| TLPX | 3 | 55.6 | 3 | 55.6 | 50 | ✓ OK |
| THS_EXIT | 6 | 111.1 | 5 | 92.6 | 100 | ✗ VIOLATION |
| TCLK_PREPARE | 3 | 55.6 | 2 | 37.0 | 38* | ⚠ Marginal |
| TCLK_ZERO | 17 (0x11) | 314.8 | 14 (0x0e) | 259.3 | 300 | ✗ VIOLATION |
| TCLK_POST | 10 (0x0a) | 185.2 | 10 (0x0a) | 185.2 | 60+52×UI ≈180 | ✓ OK |
| TCLK_TRAIL | 4 | 74.1 | 3 | 55.6 | 60 | ✗ VIOLATION |
| THS_PREPARE | 3 | 55.6 | 5 | 92.6 | 40+4×UI=49.3 / max 85+6×UI=98.9 | ⚠ Near max |
| THS_ZERO | 10 (0x0a) | 185.2 | 6 | 111.1 | 145+10×UI=168.2 | ✗ VIOLATION |
| THS_TRAIL | 4 | 74.1 | 3 | 55.6 | max(8×UI, 60+4×UI)=69.3 | ✗ VIOLATION |

Five timing parameters are out of spec. The driver is not applying your target values. This is consistent across all 30 captures — the samsung-dsim driver's timing calculation function is overriding your devicetree values with its own computed (incorrect) values, or the devicetree properties are not being parsed.

### Critical Impact of Wrong Registers on SoT

• THS_ZERO = 6 (111 ns) vs. spec min 168 ns: This is the duration data lanes hold LP-00 before HS-0. At 111 ns, it's 34% below spec minimum. The SN65DSI83's SoT detector needs to see LP-00 for at least one full internal sample window. At 111 ns, it's on the edge — sometimes it catches it, sometimes it doesn't.

• TCLK_ZERO = 14 (259 ns) vs. spec min 300 ns: The clock lane's HS preparation is also short, meaning the clock may not be stable when data SoT arrives.

• THS_EXIT = 5 (92.6 ns) vs. spec min 100 ns: The exit time from HS back to LP is too short, potentially corrupting the LP-11 idle state before the next SoT.

## 3. LP Timing Analysis — SoT Failure Mechanism

### LP-low Plateau Distribution (30 captures)

| LP-low plateau | Count | Flicker? |
|---|---|---|
| ~342-343 ns | 20 | 0/20 (0%) — all good |
| ~108 ns | 3 | 0/3 (0%) — good but marginal |
| 0 ns (absent) | 4 | 4/4 (100%) — all flicker |
| Parse error | 1 | Unknown |

Perfect 1:1 correlation: Every capture with LP-low = 0 ns produced flicker. Every capture with LP-low ≥ 108 ns was good. The mechanism is:

1. Normal case (~342 ns): PHY executes LP-11 → LP-01 → LP-00 (held ~342 ns) → HS-0. The SN65DSI83 detects the SoT sequence, locks, display works.

1. Marginal case (~108 ns): LP-00 hold is shortened to ~108 ns (roughly 6 byte clocks = actual THS_ZERO value). Still detectable by the bridge, but margin is thin.

1. Failure case (0 ns): The LP-00 state is entirely skipped — the PHY jumps directly from LP-11 to HS. The bridge cannot detect SoT, never locks, display flickers indefinitely.

### Why Does LP-low Occasionally Collapse to Zero?

The 2-3 ns "LP exit → HS" measurement appears in both good and bad captures, suggesting the measurement methodology flags any fast transition. However, the LP-low plateau measurement distinguishes the real failures:

• The Samsung DSIM PHY has an internal state machine that sequences LP-11 → LP-01 → LP-00 → HS-0. With THS_ZERO = 6 byte-clocks (111 ns) and THS_PREPARE = 5 byte-clocks (92.6 ns), the total LP-low window is ~200 ns.

• The non-deterministic failure (0 ns LP-low) suggests a clock-domain-crossing race condition inside the PHY: when the byte-clock and the PHY's internal LP sequencer are not phase-aligned at the exact moment of the first SoT, the LP-00 state can be entirely skipped. With the timers set to minimum values (below spec), the window for this race is widened.

• At your target values (THS_ZERO=10, THS_PREPARE=3), the total LP-low budget would be ~241 ns — enough to reliably survive any clock alignment variation.

## 4. HS Signal Quality Assessment

### Consistent Observations (All 30 Captures)

| Parameter | CLK Lane | DAT0 Lane | Assessment |
|---|---|---|---|
| Vdiff amplitude | 165-167 mV | 181-200 mV | ✓ Within 140-270 mV but low margin on CLK |
| Common mode | +27 to +31 mV | -6 to 0 mV | ✓ Acceptable |
| Rise time 20-80% | 164-165 ps | 159-188 ps | ✓ Within spec |
| Jitter p-p | 136-171 ps | — | ✓ Acceptable for 432 Mbit/s |
| Jitter RMS | 50-54 ps | — | ✓ Within budget |
| Clock frequency | 213-219 MHz | — | ⚠ Some variance |

### Concerns

1. CLK amplitude asymmetry: Positive swing +194 mV, negative swing -137 mV consistently. The ~57 mV imbalance (28 mV common-mode offset) is within spec but suggests slight impedance mismatch on CLK+ vs CLK- or a DC offset in the driver.

1. Below-140 mV samples: Present in virtually every capture on both CLK (7-174 samples) and DAT (19-3488 samples). These are transition-region samples and ISI-induced eye closure. The DAT lane count of 3488 (Capture 0166, a flicker event) is notably high, suggesting the failed SoT may cause the data pattern to degrade.

1. DAT0 "only negative swings": Many captures show DAT0 with only negative Vdiff in the sig window. This is a probe alignment/trigger issue — the oscilloscope window is capturing a run of identical bits. Not a hardware fault.

4. DAT0 proto showing 0 mV (Captures 0149, 0152 sig): These are captures where the data lane was idle or in LP during the proto window, likely because the scope triggered before HS data started. Capture 0152 is a flicker event — the bridge never locked, so data may have been intermittent.

## 5. Supply Rail Analysis

### 1.8 V VDDIO (All 30 Captures)

| Parameter | Range | Spec | Status |
|---|---|---|---|
| Mean voltage | 1.7647 – 1.7704 V | 1.71 – 1.89 V | ✓ |
| Min voltage | 1.7520 – 1.7600 V | 1.71 V | ✓ |
| Droop depth | 8.7 – 13.1 mV | — | ✓ Acceptable |
| Ripple RMS | 5.52 – 6.20 mV | — | ✓ Low |

Supply is NOT correlated with flicker. The four flicker captures (0141, 0147, 0152, 0166) show droop depths of 10.7, 9.8, 10.1, 10.1 mV respectively — entirely within the normal range of non-flicker captures. Mean voltage and ripple are similarly indistinguishable between good and bad sessions.

The 1.8 V rail is clean and stable. The LP-11 voltage of ~1.015 V (consistently across all captures) is within spec (1.0-1.45 V) but notably at the low end. This is normal for the i.MX 8M Mini PHY LP driver with 1.77 V supply — the LP pull-up impedance divides the voltage.

Conclusion: Supply is exonerated as a flicker cause.

## 6. Trend Analysis

### No Degradation Over Time

Across the 30-capture batch spanning ~10 minutes:
- CLK amplitude: rock-steady at 166 ±1 mV
- DAT amplitude: stable at 187-200 mV
- Jitter: no trend (136-171 ps p-p)
- Supply: stable ±5 mV
- LP-11 voltage: stable at 1.015 ±0.001 V

No thermal drift, no aging, no progressive degradation. The flicker events are randomly distributed in time, consistent with a non-deterministic race condition.

### LP-low Plateau Clustering

The three distinct LP-low durations observed (0, 108, 342 ns) correspond to:
- 342 ns ≈ THS_PREPARE + THS_ZERO = (5+6) × 18.5 ns × ~1.7 — this factor suggests the PHY may be using half-byte-clock granularity or there's additional internal pipeline delay
- 108 ns ≈ 6 × 18.5 ns — exactly THS_ZERO alone (LP-01 phase skipped or merged)
- 0 ns — complete SoT sequence skip

This trimodal distribution is characteristic of a PHY state machine with multiple failure modes at marginal timing settings.

## 7. Warnings and Errors Explained

| Warning | Captures | Cause | Action |
|---|---|---|---|
| "LP exit duration 2-4 ns below spec min 50 ns" | 24/28 valid | Measurement artifact partially, real failure for 0 ns plateau captures. The LP-11 → LP-01 transition is very fast (~2 ns slew) but the LP-01 → LP-00 → HS-0 sequence follows. The measurement picks up the initial falling edge, not the full LP-low duration. | Use LP-low plateau as the real metric |
| "Only negative swings in capture window" | ~20 captures | Scope trigger captures a run of identical data bits (e.g., all-zeros blanking period). | Not a fault. Ignore for amplitude assessment; use proto captures for true amplitude |
| "No HS signal detected" on sig/dat | 3 captures | Window captured LP or idle period. Captures 0149, 0152 (flicker), 0163. | Trigger refinement; for 0152 this is evidence of failed data lane activation |
| "CLK lane in continuous HS mode" | All captures | Expected — CLK runs continuously in video-mode DSI. No LP states on CLK. | Normal operation |
| "[lp_dat] ERROR: index out of bounds" | Capture 0154 | Analysis script buffer overrun — LP→HS transition was at the very edge of the capture window. | Extend capture window or adjust trigger delay |
| "29-3488 settled samples below 140 mV" | All captures | ISI (inter-symbol interference) causing eye closure during transitions. Count varies with data pattern. | Not critical at these counts vs. total samples, but CLK's consistent below-140mV samples indicate impedance mismatch worth investigating |

## 8. Actionable Recommendations

### PRIORITY 1 — Fix the PHY Timing Registers (ROOT CAUSE)

The samsung-dsim driver is computing its own timing values and ignoring your target. You must force the correct values:

Option A: Patch the driver timing calculation

In `drivers/gpu/drm/bridge/samsung-dsim.c` (or `sec-dsim.c` for NXP fork), locate `samsung_dsim_set_phy_timing()`. The driver computes timings from the bit rate using formulas that are known to be incorrect for lower bit rates. Override with:

```c
/* Force compliant timings for 432 Mbit/s */
reg = DSIM_PHYTIMING_LPX(3) | DSIM_PHYTIMING_HS_EXIT(6);
writel(reg, base + DSIM_PHYTIMING);

reg = DSIM_PHYTIMING1_CLK_PREPARE(3) | DSIM_PHYTIMING1_CLK_ZERO(17) |
DSIM_PHYTIMING1_CLK_POST(10) | DSIM_PHYTIMING1_CLK_TRAIL(4);
writel(reg, base + DSIM_PHYTIMING1);

reg = DSIM_PHYTIMING2_HS_TRAIL(4) | DSIM_PHYTIMING2_HS_ZERO(10) |
DSIM_PHYTIMING2_HS_PREPARE(3);
writel(reg, base + DSIM_PHYTIMING2);
```

Option B: Post-boot register override (temporary validation)

```bash
# After pipeline load, before display enable (if sequencing allows):
memtool mw -l 0x32e100b4=0x00000306
memtool mw -l 0x32e100b8=0x03110A04
memtool mw -l 0x32e100bc=0x00040A03
```

⚠ This may not work if the driver re-programs registers during enable. The driver patch is the reliable fix.

Option C: Device tree override (if driver supports it)

Check if the NXP BSP's samsung-dsim binding supports `samsung,phy-timing` properties. If so

Tokens: 32516 in / 4096 out