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.