[Lunar Lake] Protocol Error (-71) and I2C Speed Bottleneck on OV08X40 via Synaptics SVP7500 Bridge

[tjchan001]

Hardware Environment

• System: Dell Lunar Lake (Core Ultra Series 2 / Ultra 7 268V)
• Bridge: Synaptics SVP7500 (USB-to-I2C/MIPI Bridge)
• Sensor: OmniVision OV08X40 (ID: OVTI08F4:00)
• Driver: intel_ipu7 (Staging) / i2c_usbio / ivsc-csi

Issue Description

Attempts to stream from the OV08X40 sensor result in a Protocol error (-71) at STREAMON. Following the error, the Synaptics USB bridge appears to reset or latch-up, causing the device nodes to disappear (No such device) until a full cold boot is performed.

New Findings: IVSC & Firmware Gaps

Investigation with Secure Boot disabled confirms that the Intel Vision Sensing Controller (IVSC) stack is present but non-functional due to missing sensor-specific firmware.

1. Missing Firmware Blobs: /lib/firmware/intel/vsc/ contains firmware for other sensors but lacks ivsc_pkg_ovti08x40_0.bin and ivsc_skucfg_ovti08x40_0_1.bin.
2. IVSC Idle State: While ivsc-csi and ivsc-ace modules load, they fail to bind to the sensor, leaving it to bind directly to intel_ipu7_isys. This bypasses the secure handshake/authentication required by the hardware.

Observed Critical Failures

1. I2C Clock Speed Cap (The "Smoking Gun")

The usbio-i2c bridge driver forces a downclock from 400kHz to 100kHz. This latency appears to prevent the sensor from being configured within the IPU7's MIPI timing window.

[17.229199] i2c_usbio.usbio-i2c usbio.usbio-i2c.0: Invalid speed 400000 adjusting to bus max 100000

2. MIPI Link Timeout / Protocol Error

Even with manual resolution alignment (3856x2176), the CSI-2 receiver times out:

[17.779903] intel_ipu7_isys.isys intel_ipu7.isys.40: bind ov08x40 17-0036 nlanes is 2 port is 0
[20681.798345] intel_ipu7_isys.isys intel_ipu7.isys.40: enable streams Intel IPU7 CSI2 0 failed with -71

3. Entity Mismatch (Resolution Padding)

The sensor defaults to 3856x2176, while the ISYS pipeline defaults to a 12MP or 1080p target, leading to initial Broken pipe errors before manual alignment via media-ctl.

4. Firmware/GPIO Bug

The driver fails to map the physical reset line via the USB bridge:
Plaintext

[17.123913] gpio_usbio.usbio-gpio usbio.usbio-gpio.0: [Firmware Bug]: GPIO 4 is not in FW pins bitmap

Steps to Reproduce

(Optional) Disable Secure Boot and manually modprobe ivsc-csi.

Align pipeline to sensor native output: media-ctl -d /dev/media0 -V '"Intel IPU7 CSI2 0":0 [fmt:SGRBG10_1X10/3856x2176]'

Attempt capture: v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1 --stream-to=test.raw

Result: VIDIOC_STREAMON returned -1 (Protocol error).

Analysis

The combination of a 100kHz I2C bottleneck on the Synaptics bridge and missing IVSC sensor firmware creates a fatal race condition. The sensor cannot transition to High-Speed MIPI mode fast enough to satisfy the IPU7's watchdog timer. Furthermore, the direct binding of the sensor to ISYS (bypassing the IVSC) likely leaves the MIPI physical lanes in a low-power or locked state.

[tjchan001]

Update: Captured Synaptics Bridge Hardware Crash (-108) I have successfully built and injected a patched ov08x40 driver with added fsleep(100ms) delays to mitigate I2C latency. However, during the STREAMON sequence, the Synaptics SVP7500 bridge physically disconnects from the USB bus.

Critical Log Snippet:

[ 297.943136] usbio-bridge 3-3:1.0: Bulk in error -108
[ 297.943153] ov08x40 i2c-OVTI08F4:00: Failed to write reg 0x5152. error = -71
[ 297.943161] ov08x40 i2c-OVTI08F4:00: ov08x40_start_streaming failed to set plls
[ 298.924027] usb 3-3: new full-speed USB device number 5 using xhci_hcd
[ 299.048872] usb 3-3: Product: SVP7500

Observation: The bridge appears to encounter a watchdog reset or a power-state transition failure when the IPU7 attempts to enable streams. The -108 error indicates the link is physically severed. Manual attempts to set formats via media-ctl return Invalid argument (22) immediately after this reset event.

[s-ailus]

Hi Timothy,

Do you have more specific information on the system where this happens (e.g. model)?

[jibsta210]

Same Synaptics SVP7500 bridge, same -71 protocol error pattern. We've done extensive debugging on this on Panther Lake (PB16250 + HM1092 IR). Full writeup in:

• HOST_SET_MIPI_CONFIG needed for HM1092 IR sensor on Panther Lake (CVS blocks data lane) vision-drivers#37 — CVS bridge investigation (HOST_SET_MIPI_CONFIG protocol, capability bits, FW upload mechanism, reset GPIO)
• HM1092 IR sensor driver — probes but no MIPI data (need I2C trace from Windows) #64 — sensor-side (HM1092 init from Windows binary)

We've confirmed:

• The CVS firmware blob (06CB0701.bin, magic VISSOCFW, 1.93 MB) ships in the Vision_Ext folder of OEM driver packages
• It can be uploaded via the existing cvs_ctrl_data_pre sysfs in intel_cvs
• CVS cv_fw_capability 0xD200 has an undocumented bit 9 (0x200) set on PTL firmware 1.20.129
• Vision.sys exhaustively has only 7 SET commands (0x805, 0x820/821/822, 0x830, 0x831, 0x833) — no post-MIPI-config command exists in kernel side
• The actual missing piece is likely in iaisptrustlet64.dll (secure trustlet) or some MEI/SecureWorld interaction we can't see

Anyone with USBPcap on Windows running this exact hardware: a 5-min capture on device 06cb:0701 from camera-app-launch through first frame would settle this for everyone hitting Synaptics SVP7500 problems.

[tjchan001]

Hi Timothy,

Do you have more specific information on the system where this happens (e.g. model)?

Sorry, did not see your comment until now.

Dell Inc. Dell Pro 14 Premium PA14250

[jibsta210]

@Sailus @hdegoede @bingbu — sharing comprehensive findings here as this issue keeps surfacing under different titles (here, #26, #64, intel/vision-drivers#37, #31, #33, ublue-os/bazzite#4290). All same root cause: Synaptics SVP7500 bridge + Intel IPU7 + secondary CSI-2 port not forwarding on Linux.

I've been working on this for 3 months on a Dell XPS 16 PB16250 (Panther Lake) with OV08X40 RGB on port 0 and HM1092 IR on port 2. RGB works (two independent confirmations now — see intel/vision-drivers#37 comment 4433909742 by @tverhaeghe on Fedora 44 Silverblue). IR (port 2) does not stream despite every layer reporting success.

Three concrete patches we found along the way — each upstreamable independently

1. IRQF_ONESHOT removed from cvs_init() (real kernel API misuse)

drivers/misc/icvs/intel_cvs.c::cvs_init() calls devm_request_irq() with IRQF_ONESHOT — but IRQF_ONESHOT is only meaningful for threaded handlers. On a hardirq-only handler the kernel WARNs and IRQ delivery becomes unreliable. The SVP7500 bridge wedges after brief idle periods on PB16250 with this bug. Removing the flag fixes the WARNING and the wedge:

- IRQF_ONESHOT | IRQF_NO_SUSPEND,
+ IRQF_NO_SUSPEND,

Confirmed: post-fix the bridge survives 10+ minutes idle, mid-stream port-switching tests, and replay-rgb-init operations without wedge. Pure kernel API correctness, no Synaptics-specific tweaks. Ready to submit as a standalone patch.

2. HOST_SET_MIPI_CONFIG (0x0830) chunked to match Windows wire pattern

USBPcap analysis from @tverhaeghe's Windows traces shows Windows sends 0x0830 as 5 separate I2C transactions of 52/52/52/52/48 bytes (matching the USBIO_QUIRK_I2C_MAX_RW_LEN_52 chunking that Lattice NX33 has). Linux's intel_cvs was sending it as one 256-byte I2C transaction that the USBIO layer then split across multiple BULK packets — bridge-internal protocol parser sees this differently.

Patched intel_cvs_update.c::cvs_write_i2c to issue 5 separate i2c_master_send calls of ≤52 bytes each. Bridge accepts cleanly. RGB still works post-patch. Verified via usbmon + tshark capture diff against the Windows reference.

3. USBIO_QUIRK_I2C_ALLOW_400KHZ added for Synaptics 06cb:0701

Without it, kernel logs i2c_usbio.usbio-i2c.1: Invalid speed 400000 adjusting to bus max 100000 and the bridge gets clocked at 4× slower than spec. With the quirk added, the warning is gone, the bridge negotiates 400kHz, RGB unaffected. Same pattern as the Lattice NX33 entry already has.

{ USB_DEVICE(0x06cb, 0x0701),  /* Synaptics Sabre */
-  .driver_info = USBIO_QUIRK_BULK_MAXP_63 | USBIO_QUIRK_I2C_USE_CHUNK_LEN },
+  .driver_info = USBIO_QUIRK_BULK_MAXP_63 | USBIO_QUIRK_I2C_USE_CHUNK_LEN |
+                 USBIO_QUIRK_I2C_ALLOW_400KHZ },

The actual IR gap — bridge accepts everything, refuses to forward port 2

This is the puzzling part and where I'd love maintainer eyes. With all three patches above + a kernel-internal call from hm1092_set_stream(1) to intel_cvs::HOST_SET_MIPI_CONFIG (port=2 IR variant):

• ✅ hm1092 driver completes 240-register init (Windows-faithful from @tverhaeghe's USBPcap)
• ✅ Sensor MODE_SELECT=0x01 confirmed by I2C readback
• ✅ MCLK on continuously (19.2 MHz, verified via clk_get_rate before/after)
• ✅ Bridge accepts the 256-byte IR HOST_SET_MIPI_CONFIG (5 chunks, returns 0)
• ✅ Bridge state byte stays at 0x06 (DEVICE_ON | SENSOR_OWNER) — no error bits set
• ✅ Post-0x830 GET_DEVICE_STATE returns 0x06 again (no failure indicator)
• ✅ ipu7_isys CSI-2 PHY for port 2 calibrates successfully (LPDCOCAL_VT=0x19b9, 721 Mbps)
• ✅ ISYS firmware accepts STREAM_OPEN, returns STREAM_OPEN_DONE
• ❌ sof_event::csi2-2 count after 10s = 0. IPU7 csi2-2 receiver sees zero MIPI packets of any kind. Direct MMIO read of IS_IO_CSI2_ADPL_PORT_BASE(2) + CSI_RX_ERR_IRQ_STATUS shows zero error bits, zero FS_status latch, zero FE_status latch — receiver is literally idle. Bridge transmitter is not driving the lanes.
• ❌ ISYS firmware times out 10s later: stream stop time out / stream close time out

The bridge is selectively permissive in a way that points at deferred validation: it strictly rejects unknown opcodes (sent 0x0807 once, got -71 EPROTO + bridge wedge requiring reboot to recover), has a real state machine (FW loader opcodes 0x820/0x821/0x822 advance state 0x06→0x16→0x56), but accepts arbitrary 0x830 payloads — including ones with the buggy "checksum" bytes 6-9 from Vision.sys (the host-side checksum function does LEA RCX, [RSP+0x50] instead of MOV RCX, [RSP+0x50], so it sums 176 bytes of stack memory; verified by computing the actual checksum vs the captured value — they don't match. Bridge clearly doesn't validate those bytes against payload content).

Other hypotheses tested and eliminated

• Sensor PLL stabilization timing: Windows trace shows ~182ms between MODE_SELECT=0x01 and 0x830. Added msleep(200) between them via module param. No effect.
• AE-loop keepalive: Windows writes 0x0104=0x01 to IR every ~132ms during stream. Added periodic kthread via module param. No effect.
• Chip-specific OTP/calibration: Read 0x4b20 and 0x0101 on the live HM1092. Values match init exactly (0x9e, 0x03). Not a blind-write issue.
• SET_HOST_IDENTIFIER vision_sensing=1: Currently sent with vision_sensing=0 at probe. Flipping to 1 via post-probe sysfs call: bridge accepts (6/6 bytes), state unchanged, no effect on IR.
• ACPI _DSM on CVS: doesn't exist. Only INT3472 has _DSM (sensor GPIO config), nothing routes from there to a bridge command path.
• iaisptrustlet64.dll: Per RE (full report can share), it's IUM/VTL1 secure code with imports limited to IumSdk.dll. Talks to IPU7 PCI via MapSecureIo only. Zero I2C/USB/SPB access — cannot construct or send bridge commands. Not the missing piece.

What feels architectural

The bridge accepts every well-formed I2C command we send to 0x76 but the actual port-2 forwarding decision is gated by something not on the host I2C path. Looking at Windows boot, I see CSE BOOT_LOAD and AUTHENTICATE_RUN complete on our Linux side too, but the intel/ivsc-firmware repo at https://github.com/intel/ivsc-firmware ships blobs for many sensors (himx11b1, himx2170, himx2172, ovti01a0/01af/01as/02c1/02e1/2740/5678/9734/9738, hi556, int3537) but not for himx1092 (our IR) or ovti08x40 (our RGB). RGB works without the blob via direct ipu7_isys binding; IR may need it, or it may need something else entirely.

Could either of you (@Sailus / @hdegoede) confirm whether ivsc_pkg_himx1092_0.bin exists internally at Intel? And whether port-2 forwarding on the SVP7500 bridge has a known software-controllable gate we haven't found?

Reproducibility / community

This isn't a one-off — same hardware-and-symptoms pattern in:

• Not working on Dell Pro Plus 14, PB14250 #26 (Dell PB14250 LNL)
• HM1092 IR sensor driver — probes but no MIPI data (need I2C trace from Windows) #64 (this thread already mentions PA14250 LNL)
• HOST_SET_MIPI_CONFIG needed for HM1092 IR sensor on Panther Lake (CVS blocks data lane) vision-drivers#37 (PB16250 PTL — @tverhaeghe)
• IPU7 camera non-functional after building vision-drivers (CVS probe failure, no libcamera IPU7 pipeline) vision-drivers#31 (Fedora 43 LNL — @filosoho)
• Camera doesn't work on Dell Pro Max 14 Premium MA14250 vision-drivers#33 (Dell Pro Max MA14250 — @jech)
• Intel IPU6 camera fails to start (ov08x40 + Synaptics SVP7500) on Dell Pro Max 16 Premium MA16250 ublue-os/bazzite#4290 (Dell Pro Max 16)
• ASUS Vivobook X1407Q (HM1092 on Snapdragon X — same sensor, different bridge, same symptom)

A community-maintained DKMS fix pack with all three patches above + the in-flight investigation tooling is at https://github.com/jibsta210/svp7500-camera-fix-pack (v0.3). Two confirmed-RGB-working users so far, both Dell XPS 16 Panther Lake. v0.4 with the chunking + 400KHz patches incoming.

Happy to format the three patches above as proper git-format-patch series and send to linux-media@vger.kernel.org if that's the right venue. Just don't want to fork the discussion further until we know who'd land them.

[jibsta210]

Following up — pinging more of the active Intel folks who land patches on this code path:

@hao-yao @lwang47-amr @khaiwenng @qingwuzh @bingbucao

Apologies for the extra ping. @lwang47-amr — your name is on the intel_cvs source as one of the authors, so you'd likely have the cleanest mental model of the bridge state machine. Three months of community work has narrowed the IR-streaming-on-SVP7500 issue to a very specific, reproducible state (above comment) and we've eliminated essentially every host-side hypothesis — but we're hitting a wall at "bridge accepts all our 0x830 IR configs cleanly, never forwards port 2."

If anyone on the Intel side can shed light on:

• Whether ivsc_pkg_himx1092_0.bin exists internally / could be released (filed as IVSC firmware request: ivsc_pkg_himx1092_0.bin + ivsc_pkg_ovti08x40_0.bin for HM1092/OV08X40 sensors #72)
• Whether SVP7500 port-2 forwarding has any host-controllable enable we haven't found (we've mapped 0x800-0x806, 0x820-0x822, 0x830, 0x833 thoroughly)
• Whether there's a non-public/internal CSE-side handshake required for secondary CSI ports

…it would unblock a lot of hardware. Six different community threads (links in previous comment) and 3 affected Dell/Lenovo/ASUS laptop families with the same symptom. We're happy to do all the testing/legwork and write the kernel patches — just need a hint where the gate is.

Thanks for everything you've shipped already (intel_cvs, ipu7-isys staging, IVSC stack). The driver is genuinely in good shape — we just hit a wall on one specific path.

[jibsta210]

Direct CSI-2 receiver MMIO register dump from BAR0 — side-by-side comparison of all 4 ports during simultaneous RGB stream + IR stream attempt. Removes any ambiguity about where the gap is.

Test setup: PB16250 (PTL), kernel 7.0.5-cachyos-susfix, fix-pack v0.4 applied (chunked 0x830, ALLOW_400KHZ, kernel-internal reorder).

Method: small kernel module (ipu7poke) maps IPU7 BAR0 and exposes sysfs peek_addr / peek_value for arbitrary MMIO reads. Read all 4 CSI-2 receiver ADPL blocks at IS_IO_BASE + 0x40800 + i*0x2000, polled at three phases.

Phase	Port 0 (RGB, OV08X40)	Port 1 (unused)	Port 2 (IR, HM1092)	Port 3 (unused)
Cold (no streams)	all 0xffffffff (powered down)	all 0xffffffff	all 0xffffffff	all 0xffffffff
During RGB stream	INPUT_MODE=0x0, FS_STATUS=0x1, ERR=0x0	INPUT_MODE=0x0, FS=0x0	INPUT_MODE=0x0, FS=0x0	0xffffffff
During IR STREAMON (RGB still streaming)	INPUT_MODE=0x0, FS_STATUS=0x1	INPUT_MODE=0x0, FS=0x0	INPUT_MODE=0x0, FS_STATUS=0x0, RX_ERR_IRQ_STATUS=0x0	0xffffffff
After teardown	all 0xffffffff	all 0xffffffff	all 0xffffffff	all 0xffffffff

Interpretation:

1. Port-2 receiver hardware is healthy. It transitions from 0xffffffff (powered down) → 0x0 (active and configured) when the IR pipeline is opened, identical to port 0's transition. PHY 2 calibrates, ISYS firmware brings it up.
2. Port-2 receiver sees zero MIPI activity throughout the 10s STREAMON window. FS_STATUS never increments. RX_ERR_IRQ_STATUS = 0x0 — no errors, no malformed packets, no rejected frames. Receiver is literally idle, waiting.
3. RGB on port 0 latches FS_STATUS=0x1 cleanly and stays there — receiver is good.

So the gap is categorically not on the IPU7 receiver side. The bridge is silent on port-2 lanes despite:

• Accepting our 256-byte verbatim Windows IR HOST_SET_MIPI_CONFIG (5×52-byte chunked, returns 0)
• Reporting state 0x06 (DEVICE_ON | SENSOR_OWNER, no error bits) before, during, and after the attempt
• Successfully completing the REQ/RESP GPIO ownership handshake at probe (Transfer of ownership success)
• Confirming via I2C readback that the IR sensor itself is in MODE_SELECT=0x01 streaming mode

Whatever gates port-2 forwarding is inside the bridge, on the transmitter side, and isn't reachable from any host I2C path or any documented intel_cvs opcode (we mapped them all — 0x800-0x806 / 0x820-0x822 / 0x830 / 0x833, plus 0x807+ which the bridge rejects with -71 EPROTO).

The ipu7poke module + register dump script is small (~150 lines) — happy to share if it's useful for anyone else hitting this. Source will be in the next fix-pack tag at https://github.com/jibsta210/svp7500-camera-fix-pack.