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

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