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

["Vadillo, Miguel" <miguel.vadillo@intel.com>]

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
>