MIPI D-PHY Analysis Report

Generated: 2026-04-10 10:10:15  |  Scope: Captures 0472–0501  |  Model: claude-opus-4-6

# MIPI D-PHY Signal Integrity Analysis — Captures 0472–0501

## 1. Register Mismatch: The Primary Root Cause

### Actual vs. Target Registers

| Register | Target | Actual (all captures) | Impact |
|---|---|---|---|
| PHYTIMING (0xb4) | `0x00000306` | `0x00000305` | THS_EXIT=5 → 92.6 ns (spec ≥100 ns) ✗ |
| PHYTIMING1 (0xb8) | `0x03110A04` | `0x020e0a03` | TCLK_PREPARE=2→37 ns (spec 38–95 ns) ✗, TCLK_ZERO=14→259 ns (spec ≥300 ns) ✗, TCLK_TRAIL=3→55.6 ns (spec ≥60 ns) ✗ |
| PHYTIMING2 (0xbc) | `0x00040A03` | `0x00030605` | THS_PREPARE=5→92.6 ns (spec 40+4×UI=49.3–85+6×UI=98.9 ns) borderline, THS_ZERO=6→111 ns (spec ≥145+10×UI=168 ns) ✗ SEVERE, THS_TRAIL=3→55.6 ns (spec ≥max(8×UI,60ns+4×UI)=69.3 ns) ✗ |

Every single capture shows the WRONG register values. The target values (documented as MIPI D-PHY v1.1 compliant) are not being programmed. The samsung-dsim driver is computing its own timing values and overriding the device-tree or platform settings. This is the systemic defect underlying the flicker.

### Critical Field: THS_ZERO = 6 → 111 ns (needs ≥168 ns)

THS_ZERO controls how long the data lane transmitter holds LP-00 before driving HS-0. At 111 ns, it is 34% below the D-PHY v1.1 minimum of 168 ns. The SN65DSI83 receiver must detect the LP-00 state to recognise Start-of-Transmission. With THS_ZERO this short, the LP-00 plateau is a race condition: some startups catch it, some don't.

This directly explains:
- The bistable behaviour (SoT detected → good; SoT missed → stuck bad)
- The ~20% failure rate (the LP-00 window is short enough that receiver sampling jitter and internal delays occasionally miss it)
- The non-correlation with supply, temperature, or ongoing conditions (it's a one-shot timing race at SoT)

## 2. LP Timing Analysis: Flicker vs. Non-Flicker Captures

### LP-Low Plateau Distribution

| LP-low plateau | Captures (no flicker) | Captures (FLICKER) |
|---|---|---|
| ~342–343 ns | 0472, 0474, 0477, 0479, 0480, 0481, 0488, 0491, 0492, 0493, 0495, 0497, 0498, 0499 | 0487 (reported 0 ns — likely mismeasured) |
| ~108 ns | 0478, 0482, 0483, 0486, 0496, 0500 | — |
| 0 ns (absent) | — | 0475, 0476, 0489, 0490, 0501 |

Perfect correlation: All 6 flicker captures show LP-low plateau = 0 ns (absent) or anomalously short. The LP-00 state required for SoT detection is either completely missing or too brief for the SN65DSI83 to sample.

### Bimodal Plateau Distribution (Non-Flicker)

The non-flicker captures cluster at two values:
- ~342 ns (~18.5 byte-clocks): Consistent with the PHY executing the programmed THS_ZERO + THS_PREPARE sequence at full duration
- ~108 ns (~5.8 byte-clocks): Consistent with THS_ZERO=6 (111 ns) — the actual programmed value

The 342 ns group likely reflects additional PHY setup overhead or a different internal state machine path. The 108 ns group matches the (too-short) register value. Both work only because the SN65DSI83 happens to catch the LP-00 → HS transition. The 0 ns group represents cases where the PHY skipped or collapsed the LP-00 state entirely.

### LP Exit Duration

Every capture (except 0478, 0479, 0482, 0494) shows LP exit → HS of 0–4 ns — far below the 50 ns TLPX minimum. This means the LP-01 intermediate state (required before LP-00) is essentially absent. The PHY is transitioning from LP-11 directly to LP-00/HS-0 without a properly resolved LP-01 step.

This is consistent with TLPX=5 in the actual register (0xb4 field), which is 92.6 ns and should be adequate. However, the measurement of "LP exit → HS" at 0–4 ns suggests the Dp line is not cleanly stepping through LP-01 before LP-00. This could be:
- The probe is on Dn (not Dp), so LP-01 (Dp=high, Dn=low) looks like the start of LP-00
- Or the PHY is genuinely collapsing LP-01 due to the short THS_PREPARE/THS_ZERO chain

## 3. HS Signal Quality Assessment

### Consistent Characteristics (Stable Across All Captures)

| Parameter | CLK Lane | DAT0 Lane | Spec | Status |
|---|---|---|---|---|
| Vdiff amplitude | 165–167 mV | 186–198 mV | 140–270 mV | ✓ marginal on CLK |
| Common mode | +27–30 mV | −6 to +5 mV | ±25 mV (spec varies) | CLK borderline |
| Rise time 20-80% | 164–165 ps | 153–185 ps | 150 ps min | ✓ |
| Jitter p-p | 141–174 ps | — | <0.35 UI (811 ps) | ✓ |
| Jitter RMS | 50–56 ps | — | — | acceptable |

No amplitude drift or degradation trend across the 30 captures. HS signal quality is stable and adequate.

### CLK Lane Asymmetry

Consistently: Vpos ≈ +194 mV, Vneg ≈ −137 mV. The 30 mV positive common-mode offset on CLK is near the edge of spec. This is a PCB/termination asymmetry, not a flicker cause, but should be investigated for long-term reliability.

### Sub-140 mV Samples

Data lane shows 46–4946 samples below 140 mV across captures. This correlates with data pattern content (transitions through zero-crossing), not with flicker. The high counts (2000–5000) appear in captures with certain data patterns. Not a root cause concern at this bit rate.

## 4. Supply Rail Correlation

### 1.8V VDDIO During LP→HS Transition

| Parameter | Range | Spec | Status |
|---|---|---|---|
| Mean | 1.7644–1.7706 V | 1.71–1.89 V | ✓ (2% low of nominal) |
| Min | 1.7480–1.7600 V | ≥1.71 V | ✓ |
| Droop | 8.4–17.8 mV | — | acceptable |
| Ripple RMS | 5.49–6.20 mV | — | acceptable |

No supply correlation with flicker. Specifically:
- Flicker capture 0487: droop 17.8 mV (highest in set) — but non-flicker capture 0484 also shows 17.3 mV droop with no flicker
- Flicker captures 0475, 0476, 0490, 0501: droop 9.8–10.5 mV — identical to many non-flicker captures
- LP-11 voltage is rock-stable at 1.015–1.017 V across all captures (flicker and non-flicker)

The supply is not the cause. The 1.8V rail is clean and stable during the LP→HS transition. The LP driver voltage is well within spec. The failure mechanism is purely timing-based.

## 5. ERROR/WARNING Explanation

| Message | Captures | Cause | Action |
|---|---|---|---|
| `lp_dat ERROR: index 200000 out of bounds` | 0473, 0484, 0485 | Capture window ended before LP→HS transition completed; trigger timing placed the SoT at the very end of the acquisition buffer | Increase post-trigger depth or shift trigger offset. Not a hardware issue. |
| `No HS signal detected` on DAT0 sig | 0485, 0486, 0487, 0489, 0501 | Scope trigger captured a blanking interval or the data lane was in LP-idle during the high-res capture window | Non-actionable — sig captures are short windows and may miss active HS. The proto captures confirm HS is present. |
| `Only negative swings in capture window` | Most captures | The high-res sig window caught the DAT0 lane during a run of identical bit values (all-zero data). Normal for short captures on data lanes. | Non-actionable. |
| `CLK lane in continuous HS mode` | All captures | CLK is in continuous clock mode (expected for SN65DSI83 which requires continuous clock). LP transitions occur only on data lanes. | Correct behaviour. |
| `LP exit duration X ns below spec min 50 ns` | Most captures | THS_PREPARE + TLPX timing too short, or measurement artifact from probe placement (see Section 2). | Fix register values. |

## 6. Actionable Recommendations

### IMMEDIATE FIX — Priority 1: Correct PHY Timing Registers

The samsung-dsim driver is not applying the target register values. Force the correct values:

```
PHYTIMING (0xb4) = 0x00000306 → TLPX=3 (55.6ns), THS_EXIT=6 (111ns)
PHYTIMING1 (0xb8) = 0x03110A04 → TCLK_PREPARE=3 (55.6ns), TCLK_ZERO=17 (315ns),
TCLK_POST=10 (185ns), TCLK_TRAIL=4 (74ns)
PHYTIMING2 (0xbc) = 0x00040A03 → THS_TRAIL=4 (74ns), THS_ZERO=10 (185ns),
THS_PREPARE=3 (55.6ns)
```

The single most critical change is THS_ZERO: 6→10 (111 ns → 185 ns). This gives the SN65DSI83 a proper 185 ns LP-00 window to detect SoT, with 17 ns of margin above the 168 ns D-PHY minimum.

Implementation options (in order of preference):

1. Device tree override: Use `samsung,phy-timing` property if the samsung-dsim driver supports it. Check `samsung,dsim-phy-timing` or `phy-timing-*` bindings in the driver.

1. Driver patch: In `samsung_dsim_set_phy_timing()` (or equivalent), override the auto-calculated values with hardcoded constants for the 432 Mbit/s operating point. The auto-calculation is clearly producing sub-spec values.

1. Runtime memtool workaround (for validation only):
2. ```bash
3. # After DSI init but before display enable:
4. memtool mw -l 0x32e100b4=0x00000306
5. memtool mw -l 0x32e100b8=0x03110A04
6. memtool mw -l 0x32e100bc=0x00040A03
7. ```
8. Warning: This is fragile — the driver may re-program registers during enable. Use only to confirm the fix works.

### Priority 2: Investigate Driver Auto-Calculation

The samsung-dsim driver computes PHY timing from the HS clock rate. At 432 Mbit/s the computation produces:
- THS_ZERO=6 instead of 10 (off by 4 byte-clocks = 74 ns)
- TCLK_ZERO=14 instead of 17 (off by 3 byte-clocks = 56 ns)
- TCLK_PREPARE=2 instead of 3 (off by 1 byte-clock = 18.5 ns)
- Multiple trail parameters off by 1

This suggests the driver formula uses floor rounding instead of ceiling, or the base constants are wrong for the D-PHY v1.1 spec. File a bug against the `sec-dsim`/`samsung-dsim` driver with these specific field comparisons.

### Priority 3: Add Margin Beyond Minimum

Even the target values have thin margins (THS_ZERO: 185 ns vs 168 ns min = 10% margin). For a production system with the SN65DSI83 (which has known sensitivity to SoT timing), consider:

```
PHYTIMING2 (0xbc) = 0x00040C03 → THS_ZERO=12 (222ns), giving 32% margin
```

This costs negligible bandwidth at 432 Mbit/s video mode and eliminates any remaining race-condition risk.

### Priority 4: CLK Common-Mode Offset

The +28–30 mV CLK common-mode offset warrants checking:
- CLK lane termination resistor values and matching
- PCB trace length matching between CLK_P and CLK_N
- Not a flicker cause, but reduces noise margin

## 7. Summary

The flicker is caused by incorrect DSIM PHY timing register values — specifically THS_ZERO programmed at 6 byte-clocks (111 ns) instead of the required 10 (185 ns), leaving the LP-00 SoT state 34% below the D-PHY minimum of 168 ns. The samsung-dsim driver's auto-calculation is systematically under-programming all timing fields by 1–4 byte-clocks compared to the target values. This creates a non-deterministic SoT detection race at the SN65DSI83 receiver, producing the observed 20% flicker rate at pipeline load. Supply, HS amplitude, jitter, and LP-11 voltage are all nominal and uncorrelated with flicker.

Fix: Force PHYTIMING registers to the target values (especially THS_ZERO ≥ 10) via driver patch or device-tree override. This should eliminate flicker entirely. Validate by running ≥100 load/unload cycles and confirming zero LP-low plateau absences.

Tokens: 32465 in / 3851 out