HDMI ↔ MIPI/DP/DSI Bridges: EDID, HDCP, CDC & Formats
← Back to: USB / PCIe / HDMI / MIPI — High-Speed I/O Index
HDMI ↔ MIPI/DP/DSI bridges translate video at three layers—control (EDID/HPD/HDCP), pixel pipeline (format/timing/bit-depth), and clock/CDC—so the system can reliably connect sources to panels/cameras without black screens, color errors, or dropouts.
This page turns those layers into a bring-up and acceptance workflow: lock the control plane first, then validate pixel/timing, then prove clock/CDC margin with measurable pass criteria (X/Y/N).
H2-1 · Definition & Scope: What is an HDMI ↔ MIPI/DP/DSI Bridge?
An HDMI↔MIPI/DP/DSI bridge is an IC/module that closes the control-plane handshake (EDID/DDC/HPD/CEC and often HDCP) while translating the pixel pipeline (format/bit-depth/timing) into a different output interface (CSI-2, DSI, or DisplayPort).
Where it shows up
Common product archetypes (bridge-layer only)
- HDMI input → DSI panel: meeting-room boxes, embedded displays, industrial HMIs.
- CSI-2 camera → HDMI output: industrial vision adapters and debug displays.
- HDMI input → CSI-2 output: capture/encode front-ends and validation rigs.
- DP ↔ DSI/CSI: interface completion when the host lacks a native port.
The 3-plane model (fast failure classification)
Control plane
EDID/DDC/HPD/CEC (+ often HDCP). Responsible for “permission to stream”.
- Typical failures: black screen, intermittent blanking, hot-plug instability.
- First check: EDID read success, HPD level/timing, HDCP auth state.
Pixel plane
Format/bit-depth/timing conversion (optional CSC/scaler/buffering).
- Typical failures: snow/tearing, color shift, banding, “fails only at 4K”.
- First check: negotiated timing, pixel format, internal status/counters.
Output interface plane
Packetizer/lane mapping and output-side clocking (CSI-2 / DSI / DP).
- Typical failures: link flaps, dropouts under temperature/length, random frame loss.
- First check: lane map/count, FIFO/CDC flags, output lock indicators.
Directionality (do not assume symmetry)
- Unidirectional: HDMI→DSI (panel), HDMI→CSI (capture), CSI→HDMI (display).
- Bidirectional designs exist, but typically require separate personalities and configuration flows.
- Implication: “works one way” does not guarantee the reverse path is feasible.
Typical engineering metrics (selection & acceptance)
- Max pixel rate (or max resolution & frame rate) at the required format/bit-depth.
- Format support: RGB/YUV, 4:4:4 / 4:2:2 / 4:2:0, 8/10/12-bit.
- Latency class: line-buffer vs frame-buffer (scaler often implies buffering).
- Control plane: EDID storage/override, HPD behavior, HDCP role support.
- CDC robustness: PLL lock range, FIFO watermark behavior, error flags.
Scope contract (prevents cross-page overlap)
This page covers
- EDID/DDC/HPD/CEC behaviors and failure signatures.
- HDCP handling (roles, retry loops, trust boundary concepts).
- Clock-domain crossing (CDC), buffering, and stability observables.
- Pixel pipeline: color/format/bit-depth/timing conversion; optional scaler/CSC.
- Bring-up and debug workflow from symptom → first check → isolation.
This page does NOT cover
- HDMI electrical/PHY deep details (TMDS/FRL, equalization specifics). [link placeholder]
- MIPI D-PHY/C-PHY electrical timing deep details. [link placeholder]
- DisplayPort full link-training details. [link placeholder]
- Port protection/ESD/EMC component-level selection (except bridge-impact notes). [link placeholder]
H2-2 · Use-Case Map & Decision Tree: When is a Bridge the Right Tool?
This chapter prevents wasted bring-up cycles by separating “must bridge” cases from “avoid bridging” cases, then selecting a bridge class by hard constraints: direction/role, HDCP, timing adaptation, pixel formats, and latency.
Use-case map
Each card lists the constraints that drive architecture choice
CSI-2 camera → HDMI output
- Goal: camera stream displayed on standard HDMI sinks.
- Must-have: stable timing generation + consistent format mapping.
- First failure: black screen from EDID assumptions; color shift from CSC mismatch.
- Bridge class: CSI input + HDMI TX path (CSC optional).
HDMI input → DSI panel
- Goal: external HDMI source drives an embedded panel.
- Must-have: timing adaptation; DSI mode/initialization consistency.
- First failure: panel stays dark (init/timing mismatch) or tears (timing margins).
- Bridge class: HDMI RX + DSI TX; scaler recommended if inputs vary widely.
HDMI input → CSI-2 output (capture)
- Goal: HDMI source becomes a CSI-2 stream into a host SoC.
- Must-have: deterministic CDC/buffering + stable CSI packetization.
- First failure: frame drops from FIFO watermark; DT/VC mapping mismatch.
- Bridge class: HDMI RX + CSI-2 TX (buffering often required).
DP ↔ MIPI/DSI/CSI (interface completion)
- Goal: bridge a DP stream to panel/camera style ports.
- Must-have: stream mapping consistency + clean CDC boundary.
- First failure: intermittent blanking from control-plane assumptions.
- Bridge class: direction-specific DP personality + MIPI personality.
“Must bridge” triggers
- Port mismatch: native interface is unavailable on the platform.
- HDCP required: the bridge must own a defined authentication role/boundary.
- Timing adaptation: endpoint accepts a narrow timing set; scaler/timing engine is mandatory.
- Format translation: RGB↔YUV, subsampling, or bit-depth conversion is unavoidable.
- Observability: deterministic config and readable status/counters are required.
“Avoid bridging” triggers
- Latency is strict: buffering/scaling risk is unacceptable.
- Native port exists: direct routing or simpler interconnect is feasible.
- Thermal headroom is thin: added SerDes heat density and rails are high risk.
- Compliance ownership is unclear: HDCP/CTS responsibility is ambiguous.
Constraint-first decision logic (order matters)
- Direction & role: lock the exact conversion path (HDMI→DSI / HDMI→CSI / CSI→HDMI / DP→MIPI).
- HDCP: decide if required, then lock role (sink/source/repeater) and trust boundary.
- Timing constraints: confirm if endpoint requires fixed timing; decide if scaler is mandatory.
- Pixel format/bit-depth: lock RGB/YUV, subsampling, and bit-depth end-to-end.
- Latency class: line-buffer vs frame-buffer; treat buffering as an architectural choice.
- Observability: prefer deterministic configuration and readable error flags/counters.
Practical takeaway
Lock direction first, then treat HDCP and timing adaptation as top-level constraints. Keep EDID advertisement consistent with the internal pixel pipeline and the output interface configuration to avoid “link-up but no picture” failures.
H2-3 · Reference Architectures: Four System Archetypes (Bridge Layer Only)
These four archetypes form a system-level map. Every bring-up issue on this page can be anchored to one data path and one control closure, without diving into PHY-level details.
Archetype A1
CSI-2 Camera → Bridge → HDMI Output
- Data path: CSI-2 packets → internal pixel bus → HDMI TX stream.
- Control path: EDID/HPD drives output timing/format; camera config stays upstream.
- Risk points: format mapping (RGB/YUV), timing synthesis, CSC mismatch.
- Typical first failure: black screen with valid EDID reads → timing/format mismatch.
- Acceptance hook: stable video for X minutes with zero frame drops.
Archetype A2
HDMI Input → Bridge → DSI Panel
- Data path: HDMI RX → pixel normalize/convert → DSI video/command output.
- Control path: EDID/HPD closes with HDMI source; panel init/mode closes on DSI side.
- Risk points: fixed panel timing, command init, scaler requirement, CDC margins.
- Typical first failure: panel stays dark → DSI mode/init sequence mismatch.
- Acceptance hook: no tearing; timing stable within X ppm equivalent budget.
Archetype A3
HDMI Input → Bridge → CSI-2 Output (Capture)
- Data path: HDMI RX → CDC/buffer → CSI-2 packetizer → host receiver.
- Control path: EDID/HPD + (optional) HDCP closure on HDMI; CSI output config closure on host side.
- Risk points: FIFO watermark, underflow/overflow, DT/VC mapping consistency.
- Typical first failure: works briefly then drops frames → CDC/buffer stability issue.
- Acceptance hook: drop rate < X per Y minutes under sustained load.
Archetype A4
DP ↔ DSI/CSI Bridge (Direction-Specific)
- Data path: DP stream mapping ↔ internal pixel normalize ↔ MIPI packet/video output.
- Control path: DP personality closure + output personality closure (MIPI/DSI/CSI).
- Risk points: stream mapping assumptions, mode changes, CDC boundary placement.
- Typical first failure: intermittent blanking → control-plane assumption mismatch.
- Acceptance hook: stable mode switch within X seconds without lock loss.
H2-4 · Pixel Pipeline Fundamentals: What Happens Inside the “Black Box”
A bridge succeeds when the advertised capabilities (EDID/HDCP roles and timing promises) match the actual internal pixel pipeline and the output interface schedule. The pipeline can be decomposed into five verifiable stages.
Pipeline
Input → Normalize → Transform → Buffer/CDC → Packetize/Output schedule
1) Input Unpack
- Extract frame boundary, timing, and pixel stream from HDMI/DP/CSI/DSI input.
- Establish recovered clock domain and basic validity (lock / decode OK).
- Observable: lock indicators, decode errors, input timing readback.
2) Normalize (Internal Pixel Bus)
- Unify to a single internal representation: RGB/YUV, subsampling, bit-depth.
- Align “advertised” format with internal reality to avoid silent mismatches.
- Observable: negotiated format vs internal status flags.
3) Transform (CSC / Scaling / Dither)
- Color-space conversion (RGB↔YUV), subsampling conversion, bit-depth adaptation.
- Scaler/timing engine when sink accepts a narrow timing set.
- Observable: scaler enable state, CSC mode, banding/tearing signatures.
4) Buffer & CDC (Stability)
- Cross from recovered input clock to required output clock (async FIFO / PLL domain).
- Choose line-buffer vs frame-buffer by latency tolerance and jitter margin.
- Observable: FIFO watermark, underflow/overflow flags, CDC error counters.
5) Packetize & Output Schedule
- DSI video/command mode scheduling; CSI-2 DT/VC mapping; DP stream output mapping.
- Output lane mapping and configuration must match the receiving endpoint.
- Observable: output lock, lane status, receiver error flags/frame counters.
Latency budget
Express latency as sum of modules (use X placeholders)
End-to-end latency ≈ Tbuffer + Tscale + Tconv + Tcrypto + Tschedule
Tbuffer
Dominated by FIFO depth / line vs frame buffering.
Pass: ≤ X lines (or X frames)
Tscale
Appears when timing adaptation/scaler is enabled.
Pass: ≤ X ms @ target mode
Tconv
Color/format conversion and dithering pipeline depth.
Pass: no visible artifacts; mode stable across X toggles
Tcrypto
Applies when HDCP encryption/decryption is in the pixel path.
Pass: auth stable for X minutes (no retry storms)
Tschedule
Output scheduling window and receiver tolerance.
Pass: no frame drop; output error count ≤ X
Practical takeaway
Treat Normalize as the truth source (what pixels really are), treat Buffer/CDC as the stability boundary (what keeps frames continuous), and treat Packetize/Output as the receiver contract (what the sink/host expects).
H2-5 · EDID / DDC / CEC / HPD State Machine (Control Plane)
This chapter turns “screen lights up” into an executable control-plane sequence. It focuses on EDID/DDC/HPD/CEC behaviors and failure signatures, not PHY electrical deep details.
Scope
Covers control-plane sequence & observables. Excludes PHY equalization/eye/jitter deep dives.
- HDMI PHY deep detail: [link placeholder]
- MIPI D-PHY/C-PHY deep timing detail: [link placeholder]
Sub-card A
Executable state machine: Detect → HPD stable → Read EDID → (Optional) CEC → (Optional) Auth → Stream
S0 · Detect (5V / attach)
- Entry: HDMI 5V present or attach event.
- Action: clear stale EDID/cache flags; reset DDC engine if needed.
- Observable: attach flag, 5V valid, DDC idle.
- Fail→: remain in S0 if 5V unstable.
S1 · HPD stable (debounce)
- Entry: 5V valid; system ready to advertise capabilities.
- Action: drive HPD high after debounce window; optionally pulse HPD to force re-enumeration.
- Observable: HPD level, HPD glitch counter, pulse width within X ms.
- Fail→: go back to S0 on 5V drop or repeated HPD glitches.
S2 · Read EDID (source closure)
- Entry: HPD stable; DDC lines idle.
- Action: serve EDID via one of: internal EDID / external EEPROM / pass-through.
- Observable: I²C ACK rate, EDID checksum OK, block count consistent.
- Fail→: re-try with cooldown; avoid rapid retry storms (cooldown X s).
S3 · Optional CEC (policy)
- Entry: EDID read complete; CEC required by product policy.
- Action: choose pass-through or isolation mode; prevent CEC noise from disturbing DDC/HPD stability.
- Observable: CEC activity counter, error frames, isolation status.
- Fail→: disable CEC path and proceed (no impact to EDID/DDC).
S4 · Optional Auth gate
- Entry: EDID stable; policy requires content protection.
- Action: run auth sequence; rate-limit retries; keep control-plane stable.
- Observable: auth state, retry counter, blackout time < X s.
- Fail→: hold stream muted or fall back policy (product-specific).
S5 · Stream stable
- Entry: mode negotiated; output path ready.
- Action: keep HPD stable; avoid unnecessary EDID re-reads; monitor “stability observables”.
- Observable: no repeated HPD toggles; EDID cache valid; link stable for X minutes.
- Fail→: go to S1 (HPD reset) or S2 (EDID refresh) depending on symptom.
Sub-card B
Common failure signatures → first check point (fast isolation)
Black screen but HPD is high
- First check: EDID checksum & block completeness.
- Then: EDID “advertised mode” matches actual pixel pipeline capability.
- State focus: S2 (EDID) → S5 (Stream).
Works once; fails after hot-plug
- First check: HPD debounce + HPD pulse width (re-enumeration recognizable).
- Then: EDID cache stale vs forced re-read policy.
- State focus: S1 (HPD) ↔ S2 (EDID).
EDID read is flaky via MUX/level-shifter
- First check: DDC ACK/NAK pattern and bus “stuck low” incidents.
- Then: bus speed policy; avoid overspeed across translation boundaries.
- State focus: S2 (EDID) stability.
Intermittent blanking every few minutes
- First check: HPD glitch counter + unintended EDID re-read triggers.
- Then: optional auth retry storms (handshake cadence too aggressive).
- State focus: S5 (Stream) → S1/S2 transitions.
Pass criteria template: DDC stable (ACK rate ≥ X%), HPD stable (glitch count ≤ X per hour), no forced re-enumeration during X-minute run.
H2-6 · HDCP Handling & Security Boundary (Roles, Keys, Repeater Logic)
Treat HDCP as a system security boundary: role selection, key storage boundary, and retry cadence define whether the system stays stable or falls into blackouts and downgrade loops.
Sub-card A
Role & trust boundary (architectural view)
Role selection
- Sink-like: consumes protected input (auth closure with source).
- Source-like: produces protected output (auth closure with sink).
- Repeater: topology-aware bridging for switch/matrix fan-out.
- Common failure: role mismatch → stable link but black screen.
Key boundary
- Internal secure storage: keys remain inside secure zone.
- External secure element: keys isolated; control plane requests operations.
- Failure signature: auth starts, then repeats → boundary unavailable or policy blocked.
- Observable: auth retry counter, blackout duration < X s.
Repeater topology (switch/matrix)
- Event: downstream changes (plug/unplug/switch).
- Requirement: topology update + re-auth sequencing without storms.
- Failure signature: intermittent video during switching → retry cadence too aggressive.
- Observable: “topology update” count and recovery time < X s.
Sub-card B
Bring-up order (gated workflow): prove stability first, then enable protection
- Gate 0 · No HDCP: stream stable for X minutes, zero forced re-enumerations.
- Gate 1 · HDCP enabled, fixed mode: auth stable; retry count ≤ X per hour.
- Gate 2 · Mode change + hot-plug: recovery time < X s, no lock-up.
- Gate 3 · Repeater topology (if used): downstream change recovers within X s without storms.
Failure signatures → first check
- Black screen, link stays up: role mismatch or key boundary unavailable.
- Resolution downgrades: policy fallback triggered by unstable auth or capability mismatch.
- Intermittent video: retry cadence too aggressive (storm) during switching or disturbances.
H2-7 · Clocking & CDC (Clock Domains, Buffers, Jitter Accounting)
Many “bench OK, field unstable” cases are clock/CDC problems in disguise: clock source → PLL/CDR → async crossing → buffer margin decides whether the stream stays stable.
Scope
Internal clocking/CDC/buffer stability and observables. Excludes PHY eye/jitter template deep dives.
Sub-card A
CDC architecture choices (low latency vs high robustness)
Line buffer (minimum latency)
- Best for: stable clock ratios and short disturbance windows.
- Strength: low end-to-end delay.
- Risk: small margin to wander/ppm mismatch; watermark approaches quickly.
- Proof: FIFO level stays away from limits by ≥ X% over X minutes.
Frame buffer (maximum robustness)
- Best for: unstable ratios, larger wander, harsh environments.
- Strength: absorbs long-term drift and burst disturbances.
- Risk: higher latency; mode switching policies must be consistent.
- Proof: zero under/overrun events across X hot-plug cycles.
Async FIFO + watermark (common balance)
- Best for: mixed clock sources, medium latency budgets.
- Strength: decouples short-term jitter from output scheduling.
- Risk: watermark “ping-pong” if thresholds/recovery cadence are aggressive.
- Proof: watermark hit count ≤ X/hour with no visible artifacts.
Practical isolation order: PLL/CDR lock stability → FIFO level drift → under/overrun flags → clock ratio/ppm evidence.
Sub-card B
Observables (status pins / regs / counters) and what they prove
Clock health
- LOCK: stable lock bit; unlock count ≤ X/hour.
- Re-lock time: < X ms after disturbance.
- Clock switch events: unexpected source swaps flagged.
CDC margin
- FIFO level: mean and peak stay away from edges by ≥ X%.
- Watermark hits: low/high hits ≤ X/hour.
- Under/Over-run: counters remain 0 during X-minute run.
System correlation
- Reset cause: brownout / watchdog / software reset events correlated to video drops.
- Interrupt stamps: capture timestamp of lock loss or FIFO events.
- Error counters: “event storms” indicate overly aggressive recovery cadence.
Pass criteria template: unlock count ≤ X/hour, FIFO under/overrun = 0 across X minutes, watermark hits ≤ X/hour.
H2-8 · Color / Format / HDR Conversion (CSC, Subsampling, Bit Depth)
“Video shows up but colors look wrong” is usually a pipeline mismatch: CSC → subsample/resample → quantize/dither defines accuracy, banding risk, and HDR consistency.
Sub-card A
Conversion chain: CSC → Subsample/Resample → Dither/Quantize
CSC (RGB ↔ YUV, range)
- Purpose: matrix + range mapping.
- Risks: wrong range → lifted blacks / clipped highlights.
- Verify: ramp + black/white patches; range flag consistent end-to-end.
Subsample/Resample (4:4:4 ↔ 4:2:2 ↔ 4:2:0)
- Purpose: bandwidth shaping and format matching.
- Risks: chroma artifacts; edge color bleeding in high-contrast patterns.
- Verify: color bars and fine chroma transitions.
Dither/Quantize (8/10/12-bit)
- Purpose: bit-depth landing with minimal banding.
- Risks: banding if dither disabled or inserted at wrong stage.
- Verify: grayscale ramp; banding score ≤ X (template).
HDR handling boundary (internal view): metadata may be passed through, rewritten (when conversion changes dynamic behavior), or dropped (typically causing visual inconsistency).
Sub-card B
Symptom → likely cause → first measurement (fast triage)
Blacks look lifted / washed out
- Likely cause: range mismatch (full vs limited) in CSC stage.
- First measure: range mode flags + CSC selection consistency.
- Fix direction: align CSC matrix + range end-to-end.
Highlights clip / whites blow out
- Likely cause: clipping after conversion or HDR boundary inconsistency.
- First measure: conversion stage order + metadata pass-through/override status.
- Fix direction: consistent policy when CSC/scaling changes behavior.
Banding in gradients (gray ramp)
- Likely cause: bit-depth reduction without proper dither placement.
- First measure: output bit-depth + dither enable + insertion point.
- Fix direction: move/enable dither before final quantization.
Color edges look smeared / chroma artifacts
- Likely cause: subsampling/resampling mismatch or unexpected 4:2:x conversion.
- First measure: negotiated chroma format at input and output.
- Fix direction: lock format or use consistent resampling path.
Pass criteria template: grayscale ramp shows no visible banding beyond X level, color bars show no clipping at X% saturation, and black/white patches match reference within X.
H2-9 · Scaling / Framerate / Timing Adaptation (Resolution, Timing Margin, Mode Switching)
A bridge becomes “production-ready” only when it can keep output timing stable while input modes change: mode detect → (optional) scaling/buffering → timing generation → controlled reconfiguration.
Scope
Internal timing adaptation strategy and bring-up order. Excludes protocol timing rule tables.
Sub-card A
When scaling / timing adaptation becomes mandatory (practical checklist)
Scaler is required when…
- Panel has fixed timing: only accepts a narrow output window.
- Input mode varies: multiple resolutions or dynamic sources.
- Output bandwidth bound: lane count or link budget needs shaping.
- Acceptance needs uniformity: single output mode for test/QA.
- Verify: output stays in “sink window” with margin ≥ X%.
Frame buffer is required when…
- Frame rate conversion: async input/output cadence must be absorbed.
- Robust mode switching: avoid visible artifacts during reconfigure.
- Drift/wander: CDC needs long-term elasticity.
- Trade-off: added latency of X frame(s) (template).
- Verify: under/overrun = 0 across X minutes.
Scaling can be avoided if…
- Input is locked: a single known mode is enforced by the system.
- Sink tolerant: accepts multiple timings or wide margins.
- Switching disabled: no hot mode-change in production scenario.
- Verify: reconfig count = 0 during steady-state run.
Common pitfall: input mode changes but output policy does not trigger a controlled reconfigure, causing black screen, flicker, or “stuck in old timing”.
Sub-card B
Bring-up order: lock one mode first, then enable adaptation
Step 1 — fixed mode baseline
- Force a single input resolution / frame rate / format.
- Force a single output timing (known-good porch/sync set).
- Pass: no blackout over X minutes; reconfig count = 0.
Step 2 — enable scaler/buffer (still locked)
- Enable scaler (if needed) with fixed ratio.
- Enable buffer policy with conservative thresholds.
- Pass: watermark hits ≤ X/hour; artifacts = 0.
Step 3 — allow adaptation (controlled switching)
- Enable mode detect + reconfigure policy with debounce.
- Switch one variable at a time (resolution → then frame rate).
- Pass: blackout < X ms per switch; stable after X seconds.
Pass criteria template: output timing stays within sink window by ≥ X% margin, reconfig event rate ≤ X/hour, and visible artifacts = 0 during X switch cycles.
H2-10 · Interface Mapping Notes (CSI-2 vs DSI vs DP — Bridge-Level Essentials)
Mapping failures are often configuration consistency issues, not signal quality: input packet/stream → internal pixel bus → output packet + lane mapper must align in format, timing, and lane symmetry.
Scope
Bridge-level mapping only. Excludes electrical/PHY training details.
Sub-card A
Mapping checklist cards (Input → Internal → Output → risk note)
CSI-2 packet → pixel bus → DSI video
- Input: VC/DT used to select channel + format.
- Internal: pixel format/bit-depth fixed for output policy.
- Output: DSI video mode timing must match sink window.
- Risk note: VC selection mismatch → wrong stream or blank output.
HDMI/DP stream → pixel bus → CSI-2 output
- Input: stream ID / mode defines active timing.
- Internal: timing + format locked before packetizing.
- Output: packetize into CSI-2 with consistent lane count.
- Risk note: bandwidth deficit → drop/freeze even when link “up”.
DSI command vs video mode (bridge choice)
- Command: update semantics; init/refresh policy matters.
- Video: continuous stream; timing margin dominates.
- Bridge action: choose one semantic path; avoid mixed behavior.
- Risk note: wrong mode → black screen or tearing under load.
Sub-card B
The 5 most common configuration errors (and the first sanity check)
1) Lane count / bandwidth deficit
First check: required throughput vs configured lane count. Pass: utilization ≤ X% with margin.
2) Mode mismatch (DSI command vs video)
First check: output mode selection and refresh policy. Pass: stable picture for X minutes with no tearing.
3) Pixel clock / timing budget mismatch
First check: output timing generator vs sink window. Pass: margin ≥ X% and reconfig count = 0.
4) Format/bit-depth mismatch
First check: internal pixel bus format equals output packet format. Pass: no banding beyond X level.
5) “Control-plane trigger” missing for re-map
First check: re-map is gated by a control signal (mode detect/HPD/EDID/event). Pass: one reconfig per mode change with debounce.
Pass criteria template: lane/bandwidth margin ≥ X%, mapping consistent across input/internal/output, and error counters remain 0 for X minutes.
H2-11. Bring-up & Debug Playbook (Symptom-driven, no cross-page expansion)
Convert field issues into an executable flow:
Symptom → First check → Root-cause buckets → Next isolation step.
Start from the control plane, then pixel/timing, then clock/CDC.
Symptom 1 · Black screen, but DDC (I²C) toggles
First check: Is HPD asserted and stable (no bounce) during EDID read?
Likely buckets: HPD debounce/reset logic · EDID source mismatch (internal/EEPROM/passthrough) · DDC level/clock issue across mux/level-shifter.
Next isolation step: Force a known-good EDID (internal/EEPROM), lock one timing mode, then re-test with passthrough.
Symptom 2 · Image appears briefly then goes dark
First check: Does HDCP state retry repeatedly (auth storm) or does HPD drop?
Likely buckets: HDCP handshake/repeater boundary · HPD bounce/5V rail dip · FIFO underflow from CDC/scaler pipeline.
Next isolation step: Bring-up in stages: (1) run unprotected video (HDCP off) (2) freeze resolution (3) enable HDCP last.
Symptom 3 · Flicker / periodic link flap every few seconds
First check: Correlate flap period with PLL lock status and FIFO level watermark.
Likely buckets: PLL marginal lock · asynchronous FIFO watermark too tight · clock ratio drift (ref clock tolerance).
Next isolation step: Log: PLL lock bit + FIFO min/max + under/over-run flags; widen watermark or switch to deeper buffering mode.
Symptom 4 · Snow / sparkles / random pixel errors
First check: Is it mode-dependent (only certain timing/bit-depth) or load-dependent (thermal/power)?
Likely buckets: Timing margin too tight · pixel clock not aligned to output packing · CDC occasional underflow.
Next isolation step: Drop to a simpler format (RGB 8-bit, lower rate), then re-enable higher bit-depth and conversions stepwise.
Symptom 5 · Wrong colors (RGB↔YUV mix), washed blacks, or crushed highlights
First check: Verify color space and range mapping (RGB full/limited, YUV matrix selection).
Likely buckets: CSC matrix mismatch · 4:2:2/4:2:0 sampling assumption wrong · metadata path not aligned with pipeline.
Next isolation step: Freeze to a known test pattern pipeline (RGB 4:4:4), then enable CSC/subsample one knob at a time.
Symptom 6 · Banding / posterization (8/10/12-bit handling)
First check: Confirm output bit-depth and dither enable (and the dither position in the pipeline).
Likely buckets: Rounding without dither · bit-depth truncation after CSC/scaler · wrong packing mode (MSB/LSB alignment).
Next isolation step: Run grayscale ramps; compare with/without dither; validate bit packing at the output interface.
Symptom 7 · Drops only at one resolution / refresh rate
First check: Is the failure tied to output timing (porch/sync) or to pixel format (4:2:0 vs 4:4:4)?
Likely buckets: Timing adaptation margin · scaler mode transition bug · EDID advertises an unsupported combination.
Next isolation step: Lock a single known-good timing first; then enable auto mode switching after bring-up passes.
Symptom 8 · Random frame drops under stress (temperature, long run)
First check: Correlate drops with thermal flags, throttling states, or power rail sag.
Likely buckets: Thermal throttling (pixel clock reduction) · CDC watermark drift · internal buffer pressure.
Next isolation step: Record temperature + power + FIFO stats; increase headroom (heatsinking/airflow) before changing protocol-level knobs.
Symptom 9 · Works on bench, fails in system integration
First check: Identify what changed: EDID path, HPD routing, clock reference, or output lane mapping.
Likely buckets: DDC/HPD wiring differences · ref clock quality/grounding · lane swap/polarity mismatch at the panel/camera.
Next isolation step: Compare integration vs bench with a “minimal mode”: fixed timing + fixed format + HDCP off + stable HPD.
H2-12. Applications & IC Selection Logic (with concrete part numbers)
Application packs (by archetype)
- Camera → HDMI output: CSI-2/DSI source to HDMI display/capture chain.
- HDMI input → Panel: HDMI receiver to MIPI DSI panel interface.
- HDMI input → Capture: HDMI receiver to CSI-2 output for SoC/FPGA capture.
- DP/eDP ↔ MIPI/DSI: DisplayPort-family sources/panels bridged into embedded display interfaces.
Selection scorecard (strong constraints first)
1) Direction & role
Define source/sink/repeater boundary and one-way vs bi-directional requirements before checking resolution.
2) Max mode
Resolution / frame rate / bit-depth / chroma / HDR metadata boundary.
3) Pixel pipeline
Need scaler? CSC? frame-rate conversion? Each feature adds buffering, latency, and failure modes.
4) HDCP / security boundary
HDCP version support, key storage strategy, and repeater topology (switch/matrix) consistency.
5) Clocking & CDC
Recovered clock vs external ref, PLL margin, FIFO depth, watermark strategy (low latency vs robustness).
6) Control plane behavior
EDID source (internal/EEPROM/passthrough), HPD timing/debounce, CEC policy, DDC electrical limits.
7) Software bring-up cost
Register table complexity, scriptable init, diagnostics (status bits, counters, link states), and recovery hooks.
Candidate parts (examples, grouped by archetype)
A) HDMI input → MIPI CSI-2 output (HDMI capture to SoC/FPGA)
- Toshiba TC358743XBG (HDMI-to-CSI-2 bridge family example).
- Lontium LT6911UXC / LT6911UXE (HDMI-to-MIPI bridge family example).
B) HDMI input → MIPI DSI output (HDMI to panel)
- Toshiba TC358870XBG (HDMI-to-MIPI DSI bridge).
- Toshiba TC358779XBG (HDMI-to-MIPI DSI with scaler — legacy/discontinued, still useful as a feature reference).
- ITE IT6616E / IT6626E (HDMI-to-MIPI DSI bridge families — vendor portfolio examples).
C) MIPI CSI-2 / DSI input → HDMI output (camera/panel source to HDMI)
- Toshiba TC358840XBG (CSI-2 to HDMI bridge).
- Lontium LT8912 (MIPI-to-HDMI bridge family example; check HDCP/DDC boundaries in the datasheet).
D) DP / eDP ↔ embedded display bridges (DP family to panels / embedded links)
- NXP PTN3460 (DisplayPort to LVDS bridge).
- Parade PS8625V (DisplayPort to LVDS converter for embedded displays).
- TI SN65DSI86 (MIPI DSI to eDP bridge; useful when a panel side is eDP).
- ITE IT6510 (DisplayPort 1.2 to MIPI CSI/DSI converter family example).
Reusable support parts (EDID / DDC / security / port-side basics)
- EDID EEPROM: Microchip 24LC02B, ST M24C02, onsemi CAT24C02.
- DDC (I²C) level translation: TI PCA9306 (bidirectional level translator).
- Secure element (key/credential anchor): Microchip ATECC608A, NXP SE050, Infineon OPTIGA Trust M.
- Ultra-low-C port ESD (example families): TI TPD4E05U06, Littelfuse SP3012-06UTG (check availability/status).
- Common-mode choke (example): Würth 744232102, TDK ACM2012 series (choose by impedance/current vs eye margin).
Note: support parts are listed as reusable building blocks. Final choices must be validated against the exact data rate, capacitance budget, and compliance tests.
Request a Quote
H2-13. FAQs (field long-tail troubleshooting + acceptance criteria)
Scope: only close field issues and measurable pass/fail checks for HDMI ↔ MIPI/DP/DSI bridges.
Each answer is fixed to 4 lines: Likely cause / Quick check / Fix / Pass criteria.
1) EDID reads OK, but no video — check HDCP role mismatch or output timing not started?
Likely cause: HDCP role/boundary mismatch (source/sink/repeater) or stream start blocked by timing pipeline state.
Quick check: Log HDCP auth state + retry counter (X retries/min) AND confirm output timing enable flag is asserted within Y ms after EDID read.
Fix: Bring-up in stages: HDCP OFF → force a known-good timing → confirm stable video → enable HDCP last with correct role.
Pass criteria: Video starts within X ms of HPD high; HDCP auth completes within Y s; re-auth events ≤ N per hour (N≈0 ideal).
2) HPD is high, but EDID is read repeatedly — HPD bounce/debounce or state-machine reset loop?
Likely cause: HPD bounce (no debounce) or control-plane state machine resets due to 5V/rail dip or watchdog.
Quick check: Count EDID reads per minute (X/min) and measure HPD stability window (no toggles for Y ms) during read; watch reset reason flag.
Fix: Add/strengthen HPD debounce and ensure stable 5V/logic rails during hot-plug; clear caches only once per detect event.
Pass criteria: EDID read count = 1 per plug event; HPD remains stable for ≥ X ms; zero unexpected resets over Y hot-plugs (N/Y).
3) Video appears briefly then goes dark — HDCP re-auth storm or FIFO underflow?
Likely cause: HDCP re-auth storm (repeat handshake) or CDC/scaler pipeline causes FIFO underflow/overrun.
Quick check: Compare timestamps of “dark” events with (a) HDCP re-auth counter increments and (b) FIFO under/over-run flags within ±X ms.
Fix: Disable HDCP to validate the pixel path; then tune CDC watermarks/buffer depth; re-enable HDCP after stability.
Pass criteria: FIFO under/over-run count = 0 for Y minutes; HDCP re-auth events ≤ X per hour; no blanking events over N cycles.
4) Works at 1080p but fails at 4K — pixel clock margin or scaler/format path gating?
Likely cause: Insufficient pixel clock/bandwidth headroom, or 4K triggers a different scaler/CSC/packing path with stricter buffering.
Quick check: Record pixel clock setting + link mode + pipeline feature bits at 1080p vs 4K; check FIFO low-water hits (X hits/min).
Fix: Reduce complexity first (disable scaler/CSC, use RGB 8-bit) then step up: bit-depth → CSC → scaling; lock one timing set.
Pass criteria: 4K mode runs for Y minutes with 0 under/over-run; mode switch success ≥ N/N; no pipeline reconfig loops observed.
5) Only fails when switching resolutions — missing timing set or wrong reconfiguration ordering?
Likely cause: Target timing set not defined/loaded, or reconfiguration sequence toggles output before pipeline is ready.
Quick check: Capture the mode-change log: (a) requested mode ID, (b) selected timing set ID, (c) output enable timestamp; verify gaps ≤ X ms.
Fix: Enforce an ordered sequence: disable output → program pipeline → wait for ready flag → enable output; keep EDID cache stable.
Pass criteria: Mode switch completes ≤ X ms; success rate ≥ N/N; no black screen longer than Y ms during switching.
6) Sparkles/mosaic or random pixel corruption — packet/format mismatch or CDC watermark too tight?
Likely cause: Pixel packing mismatch (bit-depth/chroma) or intermittent CDC underflow/overflow causing partial-line corruption.
Quick check: Compare input vs output format registers (RGB/YUV, 4:4:4/4:2:2/4:2:0, 8/10/12) and check FIFO low-water hits (X/min).
Fix: Force a “safe baseline” (RGB 8-bit, no CSC, no scaler) then re-enable one feature at a time until corruption returns.
Pass criteria: Corruption events = 0 over Y minutes on stress pattern; FIFO hit rate ≤ X per hour (X≈0); format registers match expected values.
7) Video is stable for ~5 minutes then drops — thermal throttling or asynchronous clock ratio drift?
Likely cause: Thermal throttling changes internal clocks/modes, or async FIFO watermark drifts as clock ratio shifts with temperature.
Quick check: Log temperature/thermal flags + clock/PLL lock + FIFO level min/max every X seconds; correlate drop time with threshold crossing.
Fix: Increase thermal headroom (heatsink/airflow) and/or switch to deeper buffering CDC mode; avoid aggressive low watermark.
Pass criteria: No throttling events over Y minutes at worst-case ambient; FIFO under/over-run = 0; max junction estimate ≤ X °C.
8) Colors look washed — RGB↔YUV mismatch or limited/full range mapping?
Likely cause: CSC matrix mismatch or range mapping mismatch (full vs limited) along the bridge pixel pipeline.
Quick check: Validate CSC enable + matrix select + range flag at both input and output; test with a black/white clipping pattern.
Fix: Lock one consistent pipeline: RGB full-range end-to-end, then migrate to YUV/limited only if required by the sink.
Pass criteria: Black/white clipping thresholds match expected values within X code steps; no visible washout on reference pattern over Y minutes.
9) Banding/posterization in gradients — bit-depth truncation or dither disabled/misplaced?
Likely cause: Bit-depth truncation after CSC/scaler, or dither is disabled/misplaced relative to the truncation point.
Quick check: Run a grayscale ramp; toggle dither ON/OFF; confirm output bit-depth matches sink expectation (8/10/12) and packing mode.
Fix: Place dither immediately before bit-depth reduction; avoid multiple truncations in the chain; prefer one controlled reduction stage.
Pass criteria: No visible banding on ramp at viewing distance X; bit-depth registers match intended setting; dither state stable across N mode switches.
10) HDR content looks wrong — metadata passthrough boundary broken or forced SDR conversion path?
Likely cause: HDR metadata path is not passthrough/rewritten as intended, or pipeline forces an SDR conversion path unexpectedly.
Quick check: Verify metadata mode flag (passthrough/overwrite/none) and confirm pipeline color format/bit-depth remain consistent during HDR playback.
Fix: Decide a single boundary: passthrough OR explicit rewrite; then lock the pixel pipeline (format/bit-depth) to prevent silent down-conversion.
Pass criteria: Metadata mode remains unchanged for Y minutes; no unexpected format/bit-depth toggles; HDR test clips show no clipping beyond X% of frames.
11) CSI-2/DSI side is “alive” but image is wrong — lane count/mapping inconsistency or pixel packing mismatch?
Likely cause: Lane count/mapping settings inconsistent between bridge and endpoint, or packet/pixel packing mismatch (DT/VC/format).
Quick check: Confirm configured lane count equals endpoint expectation; verify lane map/polarity settings; log packet type/format selection for the active mode.
Fix: Start with minimal lanes and a known format; lock lane mapping; then scale lanes/format stepwise with one change per test.
Pass criteria: Stable image with no frame corruption over Y minutes; lane count/mapping unchanged across N reboots; packet type matches expected mode.
12) Hot-plug works on bench but fails in product — HPD/5V sequencing or EDID source mismatch?
Likely cause: Different HPD/5V sequencing or EDID source behavior (EEPROM vs passthrough) between bench wiring and product integration.
Quick check: Measure HPD rise relative to 5V and reset release (Δt = X ms); record EDID source selection; count failures over N hot-plugs.
Fix: Enforce deterministic sequencing: stable 5V → release reset → assert HPD after debounce; standardize EDID source and caching policy.
Pass criteria: Hot-plug success ≥ N/N; EDID read exactly once per plug; video starts within Y ms after HPD; zero unexpected resets.
