MIPI D-PHY Analysis Report

Generated: 2026-04-09 14:44:45  |  Scope: Captures 0469–0498  |  Model: claude-opus-4-6

# MIPI D-PHY Signal Integrity Analysis — Captures 0469–0498

## 1. Root Cause: Register Mismatch — Driver Not Programming Target Timings

This is the single most important finding. Every capture shows the same register values, and they do NOT match the target values:

| Register | Target | Actual | Impact |
|---|---|---|---|
| PHYTIMING (0xb4) | `0x00000306` | `0x00000305` | THS_EXIT=5 → 92.6 ns (spec ≥100 ns) ✗ |
| PHYTIMING1 (0xb8) | `0x03110A04` | `0x020e0a03` | TCLK_PREPARE=2→37ns (spec 38–95ns) ✗, TCLK_ZERO=14→259ns (spec ≥300ns) ✗, TCLK_TRAIL=3→55.6ns (spec ≥60ns) ✗ |
| PHYTIMING2 (0xbc) | `0x00040A03` | `0x00030605` | THS_PREPARE=5→92.6ns (spec max 99ns, marginal ✓ but overshot vs target 3), THS_ZERO=6→111ns (spec ≥168ns) ✗, THS_TRAIL=3→55.6ns (spec ≥69ns) ✗ |

### Critical Field-by-Field Decode (actual registers, at 18.518 ns/unit):

PHYTIMING (0x00000305):
- TLPX = 3 → 55.6 ns (spec ≥50 ns) ✓
- THS_EXIT = 5 → 92.6 ns (spec ≥100 ns) ✗ VIOLATION

PHYTIMING1 (0x020e0a03):
- TCLK_PREPARE = 2 → 37.0 ns (spec 38–95 ns) ✗ VIOLATION by 1 ns
- TCLK_ZERO = 0x0e = 14 → 259.3 ns (spec ≥300 ns) ✗ VIOLATION by 41 ns
- TCLK_POST = 0x0a = 10 → 185.2 ns (spec ≥60+52×UI ≈ 180 ns) ✓ marginal
- TCLK_TRAIL = 3 → 55.6 ns (spec ≥60 ns) ✗ VIOLATION

PHYTIMING2 (0x00030605):
- THS_PREPARE = 5 → 92.6 ns (spec 40+4×UI to 85+6×UI ≈ 49–99 ns) ✓ but high
- THS_ZERO = 6 → 111.1 ns (spec ≥145+10×UI ≈ 168 ns) ✗ VIOLATION by 57 ns
- THS_TRAIL = 3 → 55.6 ns (spec max(8×UI, 60+4×UI) ≈ 69 ns) ✗ VIOLATION

Seven out of eight critical timing fields are either violating spec or marginal. The driver (samsung-dsim / sec-dsim) is computing these values incorrectly at 432 Mbit/s, or a device-tree override is not being applied.

## 2. LP-Low Plateau Analysis — Flicker Correlation

### Distribution across all captures with LP data:

| LP-low plateau | Count | Flicker? |
|---|---|---|
| 0 ns (absent) | 4 (0469, 0478, 0485, 0488, 0494) | All 5 confirmed flicker |
| 57–108 ns | 7 (0472, 0474, 0479, 0480, 0482, 0487, 0491, 0493, 0496, 0497, 0498) | No flicker |
| 343 ns | 9 (0470, 0471, 0473, 0475, 0477, 0481, 0484, 0486, 0495) | No flicker |

Perfect correlation: every confirmed flicker event has LP-low = 0 ns. The SoT sequence (LP-11 → LP-01 → LP-00 → HS-0) is being completely skipped on data lanes in ~17% of startups. The SN65DSI83 never sees a valid Start-of-Transmission and fails to lock its MIPI receiver.

### Why the LP-low plateau is non-deterministic:

The THS_ZERO register is programmed to only 6 byte-clocks (111 ns) vs the required 168 ns minimum. Combined with TCLK_ZERO at 259 ns (41 ns short of spec), the CLK-to-DATA timing relationship during SoT is a race condition:

1. The CLK lane enters HS and starts toggling.
2. Data lanes are supposed to execute LP-11 → LP-01 → LP-00 → HS-0 with THS_PREPARE + THS_ZERO defining the low-state duration.
3. With THS_ZERO = 6 (111 ns) — 57 ns shorter than spec — the data lane transitions through LP-00 so fast that it's below the scope's LP capture resolution on some startups.
4. The non-determinism comes from the interaction between the PHY's analog startup jitter and the too-short digital timer: sometimes the LP transmitter manages to pull low long enough for the bridge to detect it; sometimes it doesn't.

The LP exit → HS measurement of 1–4 ns across nearly all captures (even non-flicker ones) confirms that the LP-01 state (where Dp goes low, Dn stays high) is essentially absent — the transition from LP-11 to LP-00 is happening in a single slew, not as two discrete LP state changes. This is consistent with THS_PREPARE being set to 5 (92.6 ns) which is at the very top of the spec window — the PHY holds LP-01 so briefly relative to its transition time that the scope can't resolve it.

## 3. Consistent Spec Concerns

### 3a. HS Amplitude — Marginal but Passing
- CLK: 175–177 mV consistently. Within spec (140–270 mV) but only 36 mV headroom above minimum.
- DAT: 186–199 mV. Healthier margin.
- Asymmetry on CLK: +191 / -162 mV consistently → ~15 mV common-mode offset. Within ±25 mV spec but persistent.
- Below-140mV sample counts on proto captures are concerning (up to 7811 on DAT), indicating ISI/transition dips that could cause bit errors at the bridge receiver. This is exacerbated by the short THS_TRAIL (55.6 ns vs 69 ns spec) which doesn't allow full settling before the next state.

### 3b. LP-11 Voltage: 1.014–1.016 V
- Spec: VOH ≥ 1.0 V for LP (assuming 1.2 V threshold with hysteresis at the receiver).
- At 1.015 V, this is only 15 mV above the absolute minimum. The SN65DSI83 datasheet specifies LP-high threshold at 880 mV (typ), so 1.015 V provides adequate margin for detection.
- However, the 1.015 V level (vs the expected ~1.2 V for a 1.8 V VDDIO driver) suggests the LP driver's pull-up impedance and the trace/termination loading are causing significant voltage division. This doesn't cause the flicker but reduces noise immunity.

### 3c. HS Single-Ended Amplitude Anomalies
Several captures show very low single-ended HS amplitude in LP captures:
- 0472: 48 mV, 0473: 36 mV, 0474: 29 mV, 0482: 23 mV, 0487: 36 mV, 0496: 24 mV

These are not flicker-correlated and likely represent the scope capturing a blanking interval or data idle period within the HS burst window, not an actual amplitude problem (the differential proto/sig captures consistently show proper 187–199 mV).

## 4. Trends Across Captures

| Parameter | Trend | Concern |
|---|---|---|
| CLK amplitude | Flat 176.4–176.9 mV | No drift, but low headroom |
| CLK jitter p-p | 98–149 ps | No trend; occasional spikes (0473: 140 ps, 0474: 140 ps, 0486: 149 ps) uncorrelated with flicker |
| DAT amplitude | 186–199 mV | No drift |
| LP-11 voltage | 1.014–1.016 V | Rock stable, no drift |
| 1.8 V supply | 1.7634–1.7656 V mean | No drift |
| Registers | Identical across all 30 captures | Confirming this is a static programming error, not a runtime corruption |

## 5. Supply Correlation Analysis

| Captures | Supply droop | LP-low plateau | Flicker? |
|---|---|---|---|
| 0469 (flicker) | 8.9 mV | 0 ns | Yes |
| 0478 (flicker) | 8.7 mV | 0 ns | Yes |
| 0485 (flicker) | 9.4 mV | 0 ns | Yes |
| 0488 (flicker) | 8.3 mV | 0 ns | Yes |
| 0494 (flicker) | 8.1 mV | 0 ns | Yes |
| 0470 (no flicker) | 17.2 mV | 343 ns | No |
| 0471 (no flicker) | 15.7 mV | 343 ns | No |
| 0475 (no flicker) | 11.5 mV | 343 ns | No |

There is NO correlation between supply droop and flicker. In fact, the two largest droops (17.2 mV and 15.7 mV) produced *good* SoT sequences. The supply is clean and well within spec (min 1.748 V vs 1.71 V limit). Ripple RMS is consistently 5.0–5.8 mV — negligible. The supply is not the cause.

## 6. WARNING/ERROR Explanations

| Warning | Cause | Action |
|---|---|---|
| `CLK lane is in continuous HS mode — LP states not expected on CLK` | Normal: samsung-dsim operates CLK in continuous HS mode per configuration. LP transitions only on data lanes. | None needed — expected behavior |
| `Only negative swings in capture window` | The sig/dat differential capture window happened to land on a run of identical bits (all-zero data). The DAT line shows only one polarity. | Not a real issue — the proto capture shows proper bidirectional swing |
| `No HS signal detected` (0473, 0474, 0487, 0497 sig/dat) | Scope triggered during blanking/LP period on data lane while CLK was active. | Not a real issue |
| `index 200000 is out of bounds` (0476, 0483, 0490, 0492) | LP capture buffer overflow — the LP→HS transition occurred outside the capture window, or the trigger was late. | Increase capture depth or adjust trigger position. These captures cannot be assessed for LP timing |
| `LP exit duration N ns below spec min 50 ns` | REAL ISSUE: THS_PREPARE + transition overlap makes LP-01 state unresolvable. The PHY's LP state machine is cycling through LP-01 too quickly due to register misconfiguration | Fix registers (see below) |
| `Settled samples below 140 mV` | ISI (inter-symbol interference) causing eye closure during transitions. Exacerbated by short THS_TRAIL not allowing full settling. Up to 7811 samples on DAT in worst case | Fix THS_TRAIL register; consider trace impedance review |

## 7. Actionable Recommendations

### PRIORITY 1 — Fix PHY Timing Registers (CRITICAL)

The samsung-dsim driver is not programming the target values. You must ensure the correct values are written:

```
# Target values (MIPI D-PHY v1.1 compliant at 432 Mbit/s):
PHYTIMING (0x32e100b4) = 0x00000306 # TLPX=3, THS_EXIT=6
PHYTIMING1 (0x32e100b8) = 0x03110A04 # TCLK_PREPARE=3, TCLK_ZERO=17, TCLK_POST=10, TCLK_TRAIL=4
PHYTIMING2 (0x32e100bc) = 0x00040A03 # THS_TRAIL=4, THS_ZERO=10, THS_PREPARE=3
```

Root cause of the mismatch: The samsung-dsim driver in mainline Linux computes timings using `samsung_dsim_set_phy_ctrl()` which derives values from the PLL frequency. At 432 Mbit/s (a relatively low rate for this IP), the integer rounding in the driver's calculations produces values that are 1 unit too low on multiple fields. The driver was validated at higher bit rates (≥1 Gbps) where the rounding errors are proportionally smaller.

Fix options (in order of preference):

1. Device-tree override: The `samsung,burst-clock-frequency` and `samsung,esc-clock-frequency` properties influence the calculation. However, the core computation is in the driver, so DT alone may not fix all fields.

1. Driver patch: Modify `samsung_dsim_set_phy_ctrl()` in `drivers/gpu/drm/bridge/samsung-dsim.c` to add +1 to `TCLK_ZERO`, `THS_ZERO`, `THS_EXIT`, `TCLK_TRAIL`, and `THS_TRAIL` calculations — or hardcode the values for this specific bit rate via a DT override mechanism.

1. Runtime fixup script (temporary workaround): Write the registers via memtool/devmem *before* enabling the display pipeline:
2. ```bash
3. # Before pipeline enable:
4. busybox devmem 0x32e100b4 32 0x00000306
5. busybox devmem 0x32e100b8 32 0x03110A04
6. busybox devmem 0x32e100bc 32 0x00040A03
7. ```
8. Caution: This must be done after the DSIM block is clocked but before `drm_panel_enable()` / CRTC enable. The driver may overwrite these during `atomic_enable`.

### PRIORITY 2 — Increase THS_ZERO to Eliminate LP-Low Variability

The most direct cause of the bistable flicker is THS_ZERO = 6 → 111 ns (actual) vs the required ≥168 ns. Increasing to the target value of 10 → 185 ns gives the SN65DSI83 a full 185 ns window to detect the LP-00 state, eliminating the race condition. Even increasing to 9 (167 ns) would be marginal — use 10 or higher.

### PRIORITY 3 — Consider Further Margin on TCLK_ZERO

The target TCLK_ZERO = 17 → 315 ns is only 15 ns above the 300 ns spec minimum. For a bridge that must lock its clock recovery PLL during this window, consider increasing to 18 or 19 (333–352 ns) for additional margin, especially given the SN65DSI83's known sensitivity to SoT timing.

### PRIORITY 4 — Investigate LP-11 Voltage

1. V from a 1.8 V driver suggests ~785 mV drop across the LP pull-up path. Check:

Tokens: 32867 in / 4095 out