IVSC firmware request: ivsc_pkg_himx1092_0.bin + ivsc_pkg_ovti08x40_0.bin for HM1092/OV08X40 sensors

[jibsta210]

The intel/ivsc-firmware repo is archived. Filing here as it's the active venue for IPU7-related sensor enablement.

The IVSC firmware repo at https://github.com/intel/ivsc-firmware ships ivsc_pkg_* and ivsc_skucfg_* blobs for these sensors:

hi556, himx11b1, himx2170, himx2172, int3537,
ovti01a0, ovti01af, ovti01as, ovti02c1, ovti02e1,
ovti2740, ovti5678, ovti9734, ovti9738

Missing — and broadly affecting Panther Lake / Lunar Lake laptops:

• ivsc_pkg_himx1092_0.bin + ivsc_skucfg_himx1092_0_1.bin — Himax HM1092 IR sensor (Windows Hello). ACPI HID HIMX1092.
• ivsc_pkg_ovti08x40_0.bin + ivsc_skucfg_ovti08x40_0_1.bin — OmniVision OV08X40 RGB front camera. ACPI HID OVTI08F4.

Affected hardware (all ship one or both of these sensors)

• Dell XPS 16 PB16250 / DA16260 (Panther Lake)
• Dell Latitude 9440 / 7440 / 7450
• Dell Pro Plus 14 PB14250 (Lunar Lake)
• Dell Pro Max 16 MA16250 / Pro Max 14 MA14250 (Lunar Lake)
• Lenovo ThinkPad X9
• ASUS Vivobook X1407Q (Snapdragon X — same HM1092)
• Various other Intel-IPU7-based PTL/LNL laptops

What works without these blobs

RGB (OV08X40) does work on Linux via direct binding to intel_ipu7_isys, bypassing IVSC. Two community confirmations on Dell XPS 16 PB16250 (CachyOS) and DA16260 (Fedora 44 Silverblue) — see intel/vision-drivers#37 (comment) and https://github.com/jibsta210/svp7500-camera-fix-pack.

What does NOT work without these blobs

IR (HM1092) streaming. Despite:

• Sensor probing cleanly (chip ID 0x1091 confirmed on PB16250)
• 240-register Windows-faithful init applied (sensor reaches MODE_SELECT=0x01)
• Synaptics SVP7500 bridge (06CB:0701) accepting our verbatim Windows HOST_SET_MIPI_CONFIG (0x0830) IR payload as 5×52-byte chunks (matches Windows USBPcap pattern exactly)
• IPU7 CSI-2 PHY for port 2 calibrating successfully (LPDCOCAL_VT=0x19b9, 721 Mbps)
• ISYS firmware accepting STREAM_OPEN
• Bridge state byte stays at 0x06 (DEVICE_ON | SENSOR_OWNER) throughout, no error bits

→ sof_event::csi2-2 count = 0. Direct MMIO read of CSI-2 receiver shows zero packets, zero error bits — bridge is selectively silent on port 2.

Detailed investigation history at #51 (also pinged @Sailus + @hdegoede there).

Ask

Could Intel publish the missing IVSC blobs (or unarchive the intel/ivsc-firmware repo for community contribution)? Same release process used for the other 14 sensors already shipped.

If the missing blobs are not the gate (entirely possible — RGB works without one), guidance on what is gating port-2 forwarding on the SVP7500 bridge would help the affected community converge on a fix.

[jibsta210]

Concrete MEI/IVSC evidence supporting this firmware request — captured tonight on PB16250 (Panther Lake / 06CB:0701 / OVTI08F4+HIMX1092):

$ lsmod | grep -E 'mei|ivsc'
mei_gsc_proxy          16384  0
mei_me                 61440  1
ivsc_csi               16384  0   ← unbound
mei_vsc                16384  0   ← unbound
ivsc_ace               16384  0
mei_vsc_hw             28672  1 mei_vsc

The Intel ME at 0000:00:16.0 enumerates 11 MEI clients (visible under /sys/bus/mei/devices/) — all standard mei_me flavor (GSC proxy, AMT, etc). None of them are the IVSC client (92335fcf-3203-4472-af93-7b4453ac29da, the alias ivsc_csi.ko advertises). And mei_vsc shows refcount 0 — the kernel-side IVSC stack loads but never enumerates a hardware client to bind to.

Cross-checked with the firmware list at intel/ivsc-firmware: blobs exist for hi556, himx11b1, himx2170, himx2172, ovti01af, ovti02c1, ovti02e1, ovti2740, ovti5678, ovti9734, ovti9738, int3537 — but not for HIMX1092 or OVTI08F4 (the two sensors on every SVP7500-bridge laptop).

This is consistent across ALL the issues:

• Not working on Dell Pro Plus 14, PB14250 #26 (multiple PB14250 / PB16250 / various LNL+PTL units)
• [Lunar Lake] Protocol Error (-71) and I2C Speed Bottleneck on OV08X40 via Synaptics SVP7500 Bridge #51 (PA14250 — same -71 EPROTO pattern)
• Camera doesn't work on Dell Pro Max 14 Premium MA14250 vision-drivers#33 (jech, MA14250)
• HOST_SET_MIPI_CONFIG needed for HM1092 IR sensor on Panther Lake (CVS blocks data lane) vision-drivers#37 (full PB16250 RE thread)

Without the IVSC firmware for these two sensors, the secure handshake never completes, the bridge accepts I2C-layer protocol commands but the MIPI forwarding gate (which we believe is conditioned on IVSC trust) never opens. We've separately verified the I2C path is byte-for-byte correct vs Windows USBPcap traces (chunked 0x830 patch in v0.4 of our community fix pack).

The minimum ask: ivsc_pkg_himx1092_0.bin + ivsc_skucfg_himx1092_0_1.bin for HM1092, and the matching pair for OVTI08F4. With those in linux-firmware, the kernel-side IVSC stack should bind, secure handshake should run, and the test cases above can prove it works without further code changes.

Affected hardware (community confirmed so far):

• Dell XPS 16 PB16250 (Panther Lake)
• Dell XPS 16 DA16260 (Panther Lake)
• Dell Pro Plus 14 PB14250 (Lunar Lake)
• Dell Pro 14 Premium PA14250 (Lunar Lake)
• Dell Pro Max 14 MA14250 (per Camera doesn't work on Dell Pro Max 14 Premium MA14250 vision-drivers#33)
• Plus likely Lenovo ThinkPad X9 / Latitude 9440-7440-7450 / ASUS Vivobook X1407Q (untested but same hardware family)

[jibsta210]

Update: ruled out the Linux IVSC stack as the right framing. After deeper investigation tonight:

1. mei_vsc_hw shows refcount 1 but never enumerates a VSC client — no request_firmware() call ever happens during boot. Putting a renamed ivsc_pkg_himx1092_0.bin in /lib/firmware/intel/vsc/ triggers nothing. The IVSC stack appears to be designed for hardware with separate VSC silicon coprocessors (some MTL/RPL designs), not the PTL/LNL platforms with the Synaptics SVP7500 bridge where VSC functionality is folded into the IPU7 firmware itself.

2. The actual gate is bridge-internal regulator gating tied to CSE secure-auth. Independent confirmation from cross-platform analysis: the same HM1092 sensor on Snapdragon X (Asus Vivobook X1407Q, pir0c0pter0/fedora-vivobook-x1407q docs) requires:

   • AVDD = 2.91V (pm8010 LDO7_M on Qcom, equivalent must come from somewhere on Intel)
   • DOVDD = 1.82V (pm8010 LDO4_M on Qcom)

   On our Intel platform, the INT3472 (DSC0) only exposes 2 GPIOs for HM1092 — type 0x12 HANDSHAKE (mapped as "dvdd" connection) and type 0x02 IR LED. No AVDD/DOVDD enable GPIOs are exposed to Linux. The SVP7500 bridge itself most likely contains the regulators that supply HM1092's AVDD and DOVDD, and gates them on a CSE/secure-auth handshake we have no host-side access to.

   This perfectly explains why:

   • Sensor responds on I2C ✓ (DVDD path works via HANDSHAKE → bridge always-on rail)
   • Sensor reaches MODE_SELECT=0x01 ✓ (sensor logic is on)
   • Port 2 emits zero MIPI packets ✓ (DOVDD off → MIPI lane drivers unpowered)
   • Bridge state stays at 0x06 happy ✓ (bridge is in a defined idle state, just not authenticated)

3. What would actually unblock this:

   • Updated IPU7 firmware that performs the secure auth/regulator-enable for HM1092 internally (the way it presumably does for other sensors that work on Linux today, e.g. on MTL platforms with similar chip families)
   • Or publication of the bridge's secure handshake protocol so a Linux driver can implement it
   • Or an unsigned/development bridge firmware that skips the auth check (we have 06CB0701.bin from the OEM Vision_Ext package; magic VISSOCFW, version 1.20.129; works for upload via cvs_ctrl_data_pre but doesn't change behavior)

So the actual ask sharpens: not "ship ivsc_pkg_himx1092.bin" but "extend the IPU7 firmware on PTL/LNL to support HM1092 secure-channel sensor auth, OR document the bridge-side handshake." Any insight from Intel on which path is feasible would help an entire class of community camera fixes converge.

[GPLJRivett]

PA14250 is already in the affected list above — thanks. Reading comment 2's reframe toward bridge-side secure-auth / regulator gating; three small data points from this PA14250 instance in case any are useful:

1. IPU7 firmware build. psys+isys 1.1.9.240627135220, commit d84f5c35 (Ubuntu 26.04 / kernel 7.0.0-15-generic, staging DKMS).

2. ACPI OPID method absent. intel_cvs probes cleanly (protocol 1.0, ownership transfer OK) but logs:

   Intel CVS driver i2c-INTC10DE:00: find_oem_prod_id: ACPI method OPID not found
   

   The CVS driver never resolves an OEM/product ID — flagging in case OPID-derived identity is part of what the bridge wants to authenticate against.

3. IPU7 secure-mode mask = 0x0. intel-ipu7 0000:00:05.0: IPU7 SKU 0 in secure mode mask 0x0 — no CSI-2 port is firmware-locked to secure-only on this SKU. If port-2 silence were an IPU7-side hard secure-mode lock you'd expect a non-zero mask; consistent with the bridge-side AVDD/DOVDD gating theory in comment 2.

Happy to dig deeper if any of these warrant a closer look.

[jibsta210]

@GPLJRivett — matching data from a Dell DA16260 (PTL, INTC10E1, SVP7500 / 06CB:0701):

• find_oem_prod_id: ACPI method OPID not found — same as yours. Two independent platforms now confirm OPID is normally absent. Not the gate.
• IPU7 SKU 1 in secure mode mask 0x0 — same 0x0 mask, different SKU (1 vs your 0). Strongest evidence on the thread that no CSI-2 port is firmware-locked to secure-only on the IPU7 side.

That second one is, I think, the strongest single data point so far that the wall is on the bridge side (Synaptics secure-auth / regulator gating, per comment 2) rather than IPU7. Worth elevating.

Two things on your PA14250 that would push the bridge-side theory further:

1. Streaming attempt → IPU7 firmware response. Run a clean RGB capture first to confirm IPU7 firmware is healthy, then attempt IR via libcamera:

   cam --camera='\_SB_.LNK0' --capture=3 --file=/tmp/ir-#.raw
   

   On our box this returns 0 frames; dmesg shows critical boot state error 0xdead0001 (= IA_GOFO_FW_BOOT_STATE_CRIT_UNSPECIFIED, the catch-all critical code from drivers/media/pci/intel/ipu7/abi/ipu7_fw_boot_abi.h). If you hit the same code on a fresh build with no host customisation, that's a third independent confirmation.

2. cvs_send_mipi_ir_config return value. On our box the bridge accepts the IR config (intel_cvs ... port-2 mipi config returned 0) and the HM1092 sensor enters streaming (hm1092_set_stream(1) EXIT, IR LED on). Then IPU7 sees no SOF on csi2-2. If your stack reaches the same "bridge said yes, sensor streaming, IPU7 still silent" state, that's the cleanest evidence the bridge is accepting commands but not actually emitting MIPI.

For the record, comparing bridge USB ID (lsusb | grep -i synaptics) across affected platforms is also a thing we can do if it becomes useful — ours is 06CB:0701 (Synaptics SVP7500). Same failure on a different bridge SKU would itself be informative, but not asking you to chase it.

Happy to compare any of the above, or our HM1092 reverse-engineered init / pipeline-handler / patched ipu-bridge if useful.

[jibsta210]

SOLVED. The HM1092 IR sensor streams and Howdy face-unlock works end to end.

Root cause was a unit mismatch in my own sensor driver: V4L2_CID_LINK_FREQ was set to the MIPI per-lane bit rate (360,960,000) when V4L2 defines it as the DDR clock — half that, 180,480,000. So ipu7-isys programmed the CSI-2 D-PHY at ~721 Mbps against a sensor transmitting at ~361: the clock lane came up, no data packet ever framed, zero SOF forever. It looks exactly like a firmware-locked or dead sensor. It is not.

The wrong number came from the natural derivation — the sensor's own PLL registers (19.2 MHz × 94 / 5 = 360.96 MHz). That is the PLL output, but it is the bit clock, not what V4L2 wants.

Relevant to this request: no IVSC firmware blob was needed. ivsc_pkg_himx1092_0.bin turned out not to be the missing piece — the sensor was configured correctly all along and simply had its receiver clocked at twice the sensor's line rate. This issue can probably be closed unless the firmware is wanted for something else.

Working code, full write-up and verification tooling: https://github.com/jibsta210/svp7500-camera-fix-pack
Detail: intel/vision-drivers#37