Re: [REQUEST FOR GUIDANCE] Dell Panther Lake IR camera (HIMX1092 / Synaptics SVP7500 06CB:0701) — port-2 streaming gated by bridge secure-handshake

Re: [REQUEST FOR GUIDANCE] Dell Panther Lake IR camera (HIMX1092 / Synaptics SVP7500 06CB:0701) — port-2 streaming gated by bridge secure-handshake

[Laurent Pinchart]

On Tue, May 12, 2026 at 09:24:13PM -0400, Jake Steinman wrote:
> Hi all,
> 
> Cold mail to a wide CC, sending once instead of many — apologies for the
> broadcast. Community Linux camera-enable effort on Dell PB16250 (Panther Lake,
> Synaptics SVP7500 bridge USB 06CB:0701). To my knowledge this is the first
> working Linux RGB camera on any Panther Lake laptop — OV08X40 streams at
> 28.57fps after our IRQF_ONESHOT stability fix in intel_cvs, independently
> reproduced on Dell XPS DA16260 + Fedora 44 Silverblue by another community
> user. IR (HIMX1092) does not stream, and I think we've narrowed it cleanly to a
> bridge-internal secure-auth handshake we can't trigger from outside the Vision
> driver stack.
> 
> What works:
> 
> HIMX1092 probes, chip ID 0x1091 confirmed, bound to ipu7-isys CSI-2 port 2, 1
> lane
> Geometry aligned to Dell production (648×368 SGRBG10, from v81
> graph_settings_hm1092 files)
> IPU7 firmware ACKs STREAM_START_AND_CAPTURE
> intel_ipu7_isys: "stream on CSI2-2 with 1 lanes" (RX listening)
> Sensor MODE_SELECT=0x01 ack'd, intel_cvs port-2 mipi config (0x830, verbatim
> Windows USBPcap, 5×52-byte chunked) returns 0
> Cape FW already at Dell v81 level (1.20.129.0, identical bytes)
> What doesn't:
> 
> ZERO sof_event::csi2-2 in any test, including with RGB streaming concurrently
> at 28.57fps
> 10 host-side hypotheses falsified including geometry, format, MIPI replay
> verbatim, AE-kicks, vision_sensing flag, dual-stream
> Evidence the gate is bridge silicon: usbbridge.sys (Intel Vision driver,
> Windows) ships strings RESET_HANDSHAKE_CTX and 1_BRIDGE_STATE_TRIGGER_CTX. Dell
> v81 06CB0701.bin (1.97MB, magic VISSOCFW) is identical to what our cape boots.
> The handshake exists in cape FW; the trigger isn't a wire opcode visible in
> USBPcap, suggesting it crosses MEI/CSE.
> 
> Pinging this group because the answer probably lives at the intersection: Mario
> (Dell upstream routing), Hans (camera-stack architecture, prior bridge
> enabling), Sakari/Bingbu/Tianshu (IPU7 maintainers), Hans Verkuil (V4L2 second
> opinion), Tomas (MEI/CSE if the trigger crosses HECI), Daniel (INT3472 — DSC0
> only exposes HANDSHAKE/IR_LED GPIOs, AVDD/DOVDD appear bridge-internal),
> Laurent/Kieran (libcamera once unblocked).

This seems to be a question for Intel at this point.

> Not asking anyone to debug — just a pointer on whether the secure-auth path can
> be exposed to a non-Vision-stack driver, or who at Intel/Synaptics owns that
> mechanism. Even "talk to <person>" is enormously helpful.
> 
> Background + reproducer:
> 
> - DKMS fix pack (v0.4, MOK-signed, single-command install): https://github.com/
> jibsta210/svp7500-camera-fix-pack/releases/tag/v0.4
> 
> - Forensic write-up + IR debug history: https://gist.github.com/jibsta210/
> 8316b6a0bc58910891512945c4e91a08
> 
> RELATED:
> 
> https://github.com/intel/ipu7-drivers/issues/26
> https://github.com/intel/ipu7-drivers/issues/51
> https://github.com/intel/ipu7-drivers/issues/72
> https://github.com/intel/vision-drivers/issues/37

-- 
Regards,

Laurent Pinchart

Re: [REQUEST FOR GUIDANCE] Dell Panther Lake IR camera (HIMX1092 / Synaptics SVP7500 06CB:0701) — port-2 streaming gated by bridge secure-handshake

[Laurent Pinchart]

On Wed, May 13, 2026 at 07:47:41AM -0400, Jake Steinman wrote:
> On Wed, May 13, 2026 at 3:50 AM Laurent Pinchart wrote:
> > On Tue, May 12, 2026 at 09:24:13PM -0400, Jake Steinman wrote:
> > > Hi all,
> > >
> > > Cold mail to a wide CC, sending once instead of many — apologies for the
> > > broadcast. Community Linux camera-enable effort on Dell PB16250 (Panther Lake,
> > > Synaptics SVP7500 bridge USB 06CB:0701). To my knowledge this is the first
> > > working Linux RGB camera on any Panther Lake laptop — OV08X40 streams at
> > > 28.57fps after our IRQF_ONESHOT stability fix in intel_cvs, independently
> > > reproduced on Dell XPS DA16260 + Fedora 44 Silverblue by another community
> > > user. IR (HIMX1092) does not stream, and I think we've narrowed it cleanly to a
> > > bridge-internal secure-auth handshake we can't trigger from outside the Vision
> > > driver stack.
> > >
> > > What works:
> > >
> > > HIMX1092 probes, chip ID 0x1091 confirmed, bound to ipu7-isys CSI-2 port 2, 1 lane
> > > Geometry aligned to Dell production (648×368 SGRBG10, from v81 graph_settings_hm1092 files)
> > > IPU7 firmware ACKs STREAM_START_AND_CAPTURE
> > > intel_ipu7_isys: "stream on CSI2-2 with 1 lanes" (RX listening)
> > > Sensor MODE_SELECT=0x01 ack'd, intel_cvs port-2 mipi config (0x830, verbatim
> > > Windows USBPcap, 5×52-byte chunked) returns 0
> > > Cape FW already at Dell v81 level (1.20.129.0, identical bytes)
> > > What doesn't:
> > >
> > > ZERO sof_event::csi2-2 in any test, including with RGB streaming concurrently at 28.57fps
> > > 10 host-side hypotheses falsified including geometry, format, MIPI replay
> > > verbatim, AE-kicks, vision_sensing flag, dual-stream
> > > Evidence the gate is bridge silicon: usbbridge.sys (Intel Vision driver,
> > > Windows) ships strings RESET_HANDSHAKE_CTX and 1_BRIDGE_STATE_TRIGGER_CTX. Dell
> > > v81 06CB0701.bin (1.97MB, magic VISSOCFW) is identical to what our cape boots.
> > > The handshake exists in cape FW; the trigger isn't a wire opcode visible in
> > > USBPcap, suggesting it crosses MEI/CSE.
> > >
> > > Pinging this group because the answer probably lives at the intersection: Mario
> > > (Dell upstream routing), Hans (camera-stack architecture, prior bridge
> > > enabling), Sakari/Bingbu/Tianshu (IPU7 maintainers), Hans Verkuil (V4L2 second
> > > opinion), Tomas (MEI/CSE if the trigger crosses HECI), Daniel (INT3472 — DSC0
> > > only exposes HANDSHAKE/IR_LED GPIOs, AVDD/DOVDD appear bridge-internal),
> > > Laurent/Kieran (libcamera once unblocked).
> >
> > This seems to be a question for Intel at this point.
> 
> Thanks Laurent — matches our read.
> 
> Sakari and Bingbu (V4L2 + IPU7 maintainers) are already on this thread, but
> my hunch is the answer lives one team over from them — the Vision-stack /
> CSE side that owns the per-sensor bridge auth, not the kernel-V4L2 side.

Note that Bingbu has left Intel. His e-mail address bounces, I've
dropped him from CC. Hans de Goede has also left Red Hat for Qualcomm,
I've updated his e-mail.

Please also note that I only review code written by humans. If you would
like me to be involved in this matter, please make sure to write your
code manually. This also applies to e-mails.

> Anyone from prior IPU3 / IPU6 enabling you've worked with who'd be the
> right contact for that conversation? Even just a "forward this to X" closes
> the loop — happy to take it from there.
> 
> > > Not asking anyone to debug — just a pointer on whether the secure-auth path can
> > > be exposed to a non-Vision-stack driver, or who at Intel/Synaptics owns that
> > > mechanism. Even "talk to <person>" is enormously helpful.
> > >
> > > Background + reproducer:
> > >
> > > - DKMS fix pack (v0.4, MOK-signed, single-command install):
> > https://github.com/
> > > jibsta210/svp7500-camera-fix-pack/releases/tag/v0.4
> > >
> > > - Forensic write-up + IR debug history:
> > https://gist.github.com/jibsta210/
> > > 8316b6a0bc58910891512945c4e91a08
> > >
> > > RELATED:
> > >
> > > https://github.com/intel/ipu7-drivers/issues/26
> > > https://github.com/intel/ipu7-drivers/issues/51
> > > https://github.com/intel/ipu7-drivers/issues/72
> > > https://github.com/intel/vision-drivers/issues/37

-- 
Regards,

Laurent Pinchart

Re: [REQUEST FOR GUIDANCE] Dell Panther Lake IR camera (HIMX1092 / Synaptics SVP7500 06CB:0701) — port-2 streaming gated by bridge secure-handshake

[Sakari Ailus]

Hi Jake,

Cc'd Miguel and fixed libcamera domain.

On Tue, May 12, 2026 at 09:24:13PM -0400, Jake Steinman wrote:
> Hi all,
> 
> Cold mail to a wide CC, sending once instead of many — apologies for the
> broadcast. Community Linux camera-enable effort on Dell PB16250 (Panther
> Lake, Synaptics SVP7500 bridge USB 06CB:0701). To my knowledge this is the
> first working Linux RGB camera on any Panther Lake laptop — OV08X40 streams
> at 28.57fps after our IRQF_ONESHOT stability fix in intel_cvs,
> independently reproduced on Dell XPS DA16260 + Fedora 44 Silverblue by
> another community user. IR (HIMX1092) does not stream, and I think we've
> narrowed it cleanly to a bridge-internal secure-auth handshake we can't
> trigger from outside the Vision driver stack.

Miguel is upstreaming the CVS drivers
<URL:https://lore.kernel.org/linux-media/20260505223005.84162-1-miguel.vadillo@intel.com/>
so now downstream drivers should soon be needed anymore (for capture).

> 
> What works:
> 
> HIMX1092 probes, chip ID 0x1091 confirmed, bound to ipu7-isys CSI-2 port 2,
> 1 lane
> Geometry aligned to Dell production (648×368 SGRBG10, from v81
> graph_settings_hm1092 files)
> IPU7 firmware ACKs STREAM_START_AND_CAPTURE
> intel_ipu7_isys: "stream on CSI2-2 with 1 lanes" (RX listening)
> Sensor MODE_SELECT=0x01 ack'd, intel_cvs port-2 mipi config (0x830,
> verbatim Windows USBPcap, 5×52-byte chunked) returns 0
> Cape FW already at Dell v81 level (1.20.129.0, identical bytes)
> What doesn't:
> 
> ZERO sof_event::csi2-2 in any test, including with RGB streaming
> concurrently at 28.57fps
> 10 host-side hypotheses falsified including geometry, format, MIPI replay
> verbatim, AE-kicks, vision_sensing flag, dual-stream
> Evidence the gate is bridge silicon: usbbridge.sys (Intel Vision driver,
> Windows) ships strings RESET_HANDSHAKE_CTX and 1_BRIDGE_STATE_TRIGGER_CTX.
> Dell v81 06CB0701.bin (1.97MB, magic VISSOCFW) is identical to what our
> cape boots. The handshake exists in cape FW; the trigger isn't a wire
> opcode visible in USBPcap, suggesting it crosses MEI/CSE.
> 
> Pinging this group because the answer probably lives at the intersection:
> Mario (Dell upstream routing), Hans (camera-stack architecture, prior
> bridge enabling), Sakari/Bingbu/Tianshu (IPU7 maintainers), Hans Verkuil
> (V4L2 second opinion), Tomas (MEI/CSE if the trigger crosses HECI), Daniel
> (INT3472 — DSC0 only exposes HANDSHAKE/IR_LED GPIOs, AVDD/DOVDD appear
> bridge-internal), Laurent/Kieran (libcamera once unblocked).
> 
> Not asking anyone to debug — just a pointer on whether the secure-auth path
> can be exposed to a non-Vision-stack driver, or who at Intel/Synaptics owns
> that mechanism. Even "talk to <person>" is enormously helpful.
> 
> Background + reproducer:
> 
> - DKMS fix pack (v0.4, MOK-signed, single-command install):
> https://github.com/jibsta210/svp7500-camera-fix-pack/releases/tag/v0.4
> 
> - Forensic write-up + IR debug history:
> https://gist.github.com/jibsta210/8316b6a0bc58910891512945c4e91a08
> 
> RELATED:
> 
> - https://github.com/intel/ipu7-drivers/issues/26
> https://github.com/intel/ipu7-drivers/issues/51
> https://github.com/intel/ipu7-drivers/issues/72
> https://github.com/intel/vision-drivers/issues/37
> 
> -
> 
> Thanks,
> 
> 
> --
> 
> *Jake Steinman*

-- 
Kind regards,

Sakari Ailus

Re: [REQUEST FOR GUIDANCE] Dell Panther Lake IR camera (HIMX1092 / Synaptics SVP7500 06CB:0701) — port-2 streaming gated by bridge secure-handshake

[Vadillo, Miguel]

Hi Jake,

On 5/14/26 3:16 PM, Jake Steinman wrote:
> 
> 
> 
> 
> On Wed, May 13, 2026 at 8:33 AM Sakari Ailus 
> <sakari.ailus@linux.intel.com <mailto:sakari.ailus@linux.intel.com>> wrote:
> 
>     Hi Jake,
> 
>     Cc'd Miguel and fixed libcamera domain.
> 
> 
> 
> Hi Miguel, all,
> Tested v2 today on Dell XPS 16 DA16260 (Panther Lake, Synaptics SVP7500
> 06CB:0701, kernel 7.0.5 staging). Built v2 standalone, swapped our
> out-of-tree intel_cvs DKMS for cvs.ko, kept our hm1092 sensor driver +
> ipu-bridge HIMX1092 entry + INT3472 GPIO type 0x12 handler.
> Bound to ACPI INTC10E1, recognized 06CB:0701 with quirks 0x7a (matches
> your SVP7xxx table entry), read protocol 2.2 + capability 0xd200 over
> GET_DEV_CAPABILITY.
> Then probe failed:
>    intel_cvs i2c-INTC10E1:00: CSI init failed (-22)
> Source is the lane-count consistency check in
> drivers/media/i2c/cvs/v4l2.c around line 504:
>    ctx->nr_of_lanes = ep.bus.mipi_csi2.num_data_lanes;   /* sink */
>    source_ep = fwnode_graph_get_endpoint_by_id(...);      /* source */
>    v4l2_fwnode_endpoint_parse(source_ep, &ep);
>    ...
>    if (ctx->nr_of_lanes != ep.bus.mipi_csi2.num_data_lanes) {
>        ret = -EINVAL;
>        goto err_nf_cleanup;
>    }
> The check assumes sink and source endpoint lane counts match. SVP7500
> violates that by design: HM1092 outputs 1 lane to the bridge per ACPI
> SSDB, but the bridge transmits 2 lanes to IPU7 per Windows USBPcap
> decode of HOST_SET_MIPI_CONFIG (icvs_link_cfg byte 1 = 0x02). Bridge
> does protocol translation; sink/source lane counts naturally differ.
> Q1: is the hard mismatch check intentional? If yes, what's the upstream
> story for protocol-translation bridges where SSDB sensor-side count
> differs from the bridge's IPU7-side output?
> Side warning to anyone reading: we tried forcing sensor->lanes from 1
> to 2 in our patched ipu-bridge to satisfy the check. The IPU7 firmware
> does not fail-safe on lane misconfiguration vs its actual DMA layout —
> we lost the Xe GPU compositor to graphics artifacts and a hard freeze
> (IOMMU page corruption on a domain shared with GPU). Reverted.

The check was incorrect: it assumed bridge input and output lane counts 
always match. That's not true as you pointed, can you try with this change?

@@ -494,17 +494,20 @@ static int cvs_csi_parse_firmware(struct icvs *ctx)
         if (ret)
                 goto err_nf_cleanup;

-       ctx->nr_of_lanes = ep.bus.mipi_csi2.num_data_lanes;
         source_ep = fwnode_graph_get_endpoint_by_id(dev_fwnode(dev), 1, 
0, 0);
         ret = v4l2_fwnode_endpoint_parse(source_ep, &ep);
         fwnode_handle_put(source_ep);
         if (ret)
                 goto err_nf_cleanup;

-       if (ctx->nr_of_lanes != ep.bus.mipi_csi2.num_data_lanes) {
-               ret = -EINVAL;
-               goto err_nf_cleanup;
-       }
+       /*
+        * Use the source (bridge → IPU) lane count for MIPI config and
+        * get_mbus_config. Protocol-translation bridges (e.g. Synaptics
+        * SVP7xxx) may receive fewer lanes from the sensor than they
+        * forward to the IPU, so sink and source lane counts can differ
+        * by design.
+        */
+       ctx->nr_of_lanes = ep.bus.mipi_csi2.num_data_lanes;

         asc = v4l2_async_nf_add_fwnode_remote(&ctx->notifier, sink_ep,
                                               struct 
v4l2_async_connection);

I believe, this should match what Windows sends for your usecase. Thanks 
for checking.

> Q2 (separate from your driver scope): on HM1092 we can probe, read chip
> ID, send the verbatim Windows MIPI config, bridge accepts everything
> (state 0x06, no error bit), but port-2 forwarding stays closed — zero
> sof_event::csi2-2 in any test. usbbridge.sys (Windows Vision driver)
> strings include RESET_HANDSHAKE_CTX and 1_BRIDGE_STATE_TRIGGER_CTX, and
> Windows USBPcap shows zero per-sensor opcodes on the I2C bus during
> Hello unlock. Reads like the unlock crosses CSE/MEI rather than I2C.
> Is the per-sensor secure-auth path on your roadmap, or owned by a
> different team (Vision stack? IVSC?) we should be asking?
Yeah, I am not currently expecting to handle the IR winhello camera.

--
regards,
Miguel
> Happy to test patches against DA16260.
> Jakes
> Dell XPS 16 DA16260 / CachyOS / kernel 7.0.5
> 
> 
>     On Tue, May 12, 2026 at 09:24:13PM -0400, Jake Steinman wrote:
>      > Hi all,
>      >
>      > Cold mail to a wide CC, sending once instead of many — apologies
>     for the
>      > broadcast. Community Linux camera-enable effort on Dell PB16250
>     (Panther
>      > Lake, Synaptics SVP7500 bridge USB 06CB:0701). To my knowledge
>     this is the
>      > first working Linux RGB camera on any Panther Lake laptop —
>     OV08X40 streams
>      > at 28.57fps after our IRQF_ONESHOT stability fix in intel_cvs,
>      > independently reproduced on Dell XPS DA16260 + Fedora 44
>     Silverblue by
>      > another community user. IR (HIMX1092) does not stream, and I
>     think we've
>      > narrowed it cleanly to a bridge-internal secure-auth handshake we
>     can't
>      > trigger from outside the Vision driver stack.
> 
>     Miguel is upstreaming the CVS drivers
>     <URL:https://lore.kernel.org/linux-media/20260505223005.84162-1-
>     miguel.vadillo@intel.com/ <https://lore.kernel.org/linux-
>     media/20260505223005.84162-1-miguel.vadillo@intel.com/>>
>     so now downstream drivers should soon be needed anymore (for capture).
> 
>      >
>      > What works:
>      >
>      > HIMX1092 probes, chip ID 0x1091 confirmed, bound to ipu7-isys
>     CSI-2 port 2,
>      > 1 lane
>      > Geometry aligned to Dell production (648×368 SGRBG10, from v81
>      > graph_settings_hm1092 files)
>      > IPU7 firmware ACKs STREAM_START_AND_CAPTURE
>      > intel_ipu7_isys: "stream on CSI2-2 with 1 lanes" (RX listening)
>      > Sensor MODE_SELECT=0x01 ack'd, intel_cvs port-2 mipi config (0x830,
>      > verbatim Windows USBPcap, 5×52-byte chunked) returns 0
>      > Cape FW already at Dell v81 level (1.20.129.0, identical bytes)
>      > What doesn't:
>      >
>      > ZERO sof_event::csi2-2 in any test, including with RGB streaming
>      > concurrently at 28.57fps
>      > 10 host-side hypotheses falsified including geometry, format,
>     MIPI replay
>      > verbatim, AE-kicks, vision_sensing flag, dual-stream
>      > Evidence the gate is bridge silicon: usbbridge.sys (Intel Vision
>     driver,
>      > Windows) ships strings RESET_HANDSHAKE_CTX and
>     1_BRIDGE_STATE_TRIGGER_CTX.
>      > Dell v81 06CB0701.bin (1.97MB, magic VISSOCFW) is identical to
>     what our
>      > cape boots. The handshake exists in cape FW; the trigger isn't a wire
>      > opcode visible in USBPcap, suggesting it crosses MEI/CSE.
>      >
>      > Pinging this group because the answer probably lives at the
>     intersection:
>      > Mario (Dell upstream routing), Hans (camera-stack architecture, prior
>      > bridge enabling), Sakari/Bingbu/Tianshu (IPU7 maintainers), Hans
>     Verkuil
>      > (V4L2 second opinion), Tomas (MEI/CSE if the trigger crosses
>     HECI), Daniel
>      > (INT3472 — DSC0 only exposes HANDSHAKE/IR_LED GPIOs, AVDD/DOVDD
>     appear
>      > bridge-internal), Laurent/Kieran (libcamera once unblocked).
>      >
>      > Not asking anyone to debug — just a pointer on whether the
>     secure-auth path
>      > can be exposed to a non-Vision-stack driver, or who at Intel/
>     Synaptics owns
>      > that mechanism. Even "talk to <person>" is enormously helpful.
>      >
>      > Background + reproducer:
>      >
>      > - DKMS fix pack (v0.4, MOK-signed, single-command install):
>      > https://github.com/jibsta210/svp7500-camera-fix-pack/releases/
>     tag/v0.4 <https://github.com/jibsta210/svp7500-camera-fix-pack/
>     releases/tag/v0.4>
>      >
>      > - Forensic write-up + IR debug history:
>      > https://gist.github.com/
>     jibsta210/8316b6a0bc58910891512945c4e91a08 <https://gist.github.com/
>     jibsta210/8316b6a0bc58910891512945c4e91a08>
>      >
>      > RELATED:
>      >
>      > - https://github.com/intel/ipu7-drivers/issues/26 <https://
>     github.com/intel/ipu7-drivers/issues/26>
>      > https://github.com/intel/ipu7-drivers/issues/51 <https://
>     github.com/intel/ipu7-drivers/issues/51>
>      > https://github.com/intel/ipu7-drivers/issues/72 <https://
>     github.com/intel/ipu7-drivers/issues/72>
>      > https://github.com/intel/vision-drivers/issues/37 <https://
>     github.com/intel/vision-drivers/issues/37>
>      >
>      > -
>      >
>      > Thanks,
>      >
>      >
>      > --
>      >
>      > *Jake Steinman*
> 
>     -- 
>     Kind regards,
> 
>     Sakari Ailus
>