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
> 

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

[Sakari Ailus]

Hi Jake,

On Sat, Jul 25, 2026 at 01:51:50PM -0400, Jake Steinman wrote:
> Hi all,
> 
> Back in May I posted an RFC about the IR camera path on Intel Panther Lake
> (IPU7) laptops where a Himax HM1092 sensor sits behind a Synaptics SVP7500
> vision bridge. I could not get a single frame out of it.
> 
> It now works completely, and I would like help getting it upstream rather
> than leaving it as an out-of-tree fix pack.
> 
> What works today
> On a Dell XPS 16 (DA16260, Panther Lake), from a cold boot, surviving
> reboots and kernel upgrades:
> 
> RGB camera (OV08x40) — streaming, 3856x2176 @30
> IR camera (HM1092) — streaming, 648x368 @30
> IR face authentication via Howdy — lock-screen unlock in ~0.3 s
> s2idle suspend/resume, camera survives
> That is the entire camera subsystem on this class of machine. Dell's own
> driver packages bind the identical ACPI\HIMX1092 behind the identical
> bridge on the XPS 13 9350 and DA14260/DA16260, and the same combination
> ships on HP and Lenovo units, so this is a hardware family rather than one
> laptop.
> 
> Root cause, for the archive
> My sensor driver published V4L2_CID_LINK_FREQ = 360,960,000. That value is
> correct, but it is the per-lane MIPI bit rate; V4L2 defines LINK_FREQ as
> the DDR clock, which is half of it — 180,480,000. ipu7-isys therefore
> programmed the CSI-2 D-PHY at ~721 Mbps against a sensor transmitting at
> ~361. The clock lane came up and no data packet ever framed: zero SOF,
> indefinitely.
> 
> The wrong number came from the obvious derivation — the sensor's own PLL
> registers, 19.2 MHz * 94 / 5 = 360.96 MHz. That derivation is right; it
> simply yields the bit clock. Anyone reverse-engineering this part from its
> PLL configuration will land on the same value, which is why I think it is
> worth recording publicly.
> 
> I would like to correct the record on things I previously reported here and
> on the Intel trackers, all of which were wrong: the bridge does not gate
> the data lane (with no MIPI link config at all, the sensor's clock still
> reaches the IPU); HOST_SET_MIPI_CONFIG is not required for IR (Windows
> never sends one); the register init table was never wrong (byte-identical
> to Windows, in content and order); and there is no frame-trigger or
> slave-mode register anywhere in the sensor or in any Windows driver build.
> 
> A diagnostic others may find useful
> IPU7 CSI-2 PHY_STOPSTATE (port N base 0x2c0000 + N*0x4000, offset +0x4c)
> carries one bit per data lane plus bit 16 for the clock lane:
> 
> 0x00010001  clock idle + data idle   - nothing transmitting
> 0x00000001  clock ACTIVE, data parked - rate or format mismatch
> 0x00000000  both live                 - streaming
> The middle state is the signature of exactly this class of bug, and it is
> otherwise very hard to distinguish from a firmware-locked sensor.
> 
> One caveat: ipu7-isys reads that register roughly 29 us before the sensor's
> s_stream(1), so the value that reaches dmesg always says "idle" and is
> useless. The sensor has to be armed out of band first for the reading to
> mean anything. That single detail cost me weeks.
> 
> What I am asking for
> One patch is ready now. ipu-bridge has no HIMX1092 entry, so a stock kernel
> cannot construct the swnode graph for this sensor at all:
> 
> IPU_SENSOR_CONFIG("HIMX1092", 1, 180480000),
> alongside the existing HIMX11B1 / HIMX2170 / HIMX2172 entries. I will send
> this as a proper patch if it is wanted.

I'll pick the patch once we have rc1 in the media tree.

> 
> The sensor driver is not submittable as it stands, and I would rather hear
> that now than waste a maintainer's review cycle. It carries out-of-tree
> assumptions — vendor DKMS layout, debug module parameters — and needs CCI
> accessors, a proper link_freq menu and binding documentation. I am willing
> to do that work.

As you've noticed, Ramshouriesh has submitted versions of the HM1029
driver, latest is v6. That driver seems to be in a good shape (for a
register list based driver). Adding whatever needed for ACPI and required
frequency configuration to the driver would be very nice. I see you're
already working with him on this, good!

> 
> What I cannot supply is the judgement calls:
> 
> Is a sensor sitting behind a vendor vision bridge acceptable in
> drivers/media/i2c/, or does this topology need a different home?

The sensor driver isn't affected by this. The fact that it's behind such a
bridge is visible in the Media graph but otherwise these bridges are
effectively just pass-through devices for regular use cases.

> Would Intel prefer to take the HM1092 driver in-house, given it is your
> silicon and you already ship intel_cvs?
> Is there an existing convention for the illuminator? INT3472 exposes it as
> a LED class device, which means the sensor driver cannot drive it and the
> userspace consumer has to — that works, but it feels like the wrong layer.

The devices (sensor and the LED) are still different and there are use
cases where both are used independently. Does HM1092 support strobing flash
LED? That is in principle supported but often there's wiring missing. :-o

> Working code, full write-up and verification tooling:
> https://github.com/jibsta210/svp7500-camera-fix-pack
> 
> Prior discussion: https://github.com/intel/vision-drivers/issues/37
> https://github.com/intel/ipu7-drivers/issues/64
> 
> Happy to test patches, provide captures, or rework the driver to whatever
> shape you would accept. My preference by a wide margin is for this to end
> up maintained in-tree rather than living as a DKMS pack that breaks on
> every kernel bump.

I'd very much like to see such an outcome as well.

-- 
Kind regards,

Sakari Ailus