Re: [PATCH v2] platform/x86: int3472: map the ov7251 power enable GPIO to "vdda"

["D. Manresa" <dmanresa@gmail.com>]

On Sun, 31 Aug 2026, Jakob Berg Jespersen wrote:
> Tested-by: Jakob Berg Jespersen <dev@berg.pm> # Surface Pro 7+, probe/power-on

Thanks for the quick test!

> 0x009e0903 is V4L2_CID_ANALOGUE_GAIN, and the in-tree ov7251 registers
> V4L2_CID_GAIN instead, so only the front and rear cameras get
> enumerated.
> [...]
> Did you have something equivalent downstream? Happy to send it to you
> or to the list if it would help.

Yes - and so does everyone else, independently, which is the strongest
possible argument for sending it to the list. The linux-surface patchset has
carried exactly that two-line change since 2023: "media: i2c: Clarify that
gain is Analogue gain in OV7251", by Dan Scally (on Cc), in
patches/6.19/0013-cameras.patch. It was never submitted to mainline. Last
week a Fedora user rediscovered the same fix from scratch on another Surface
Pro 7+ (linux-surface PR #2252), and now you make the third. Since libcamera
hard-requires V4L2_CID_ANALOGUE_GAIN, mainline ov7251 is unusable with
libcamera on every machine until this lands.

Dan, it is your patch - would you like to send it upstream yourself? If you
would rather not, either of us can, with your authorship preserved.

> I should say I have not got a usable image out of it here yet: Frames
> come through at the right size and rate, but the content is saturated
> white, and the sensor's own test pattern does not come through either.

That is almost certainly not the sensor: it matches, symptom for symptom, the
IPU6 CSI-2 receiver desynchronisation I reported on linux-media yesterday -
"ipu6-isys: MCD PHY is initialised before the sensor is powered; intermittent
D-PHY desync at stream start (TGL)". The signature: a session starts with the
receiver desynced, every frame arrives at the right size and rate but the
content is garbage railed at full scale (for a 10-bit sensor most rows pin
near 1023 - saturated white), the sensor's test pattern does not survive
either (nothing valid does), and dmesg shows "csi2-N error: DPHY fatal error /
SOT sync error" from the first frame. Three checks on your machine:

  - dmesg right after the white session starts: if the DPHY/SOT errors are
    there, it is the receiver, not the sensor;
  - close the video device and start a new session: on my unit the desync is
    per-STREAMON and clears on the next attempt (~3% failure rate at stock
    30 fps timing, but it drifts with uptime - I have measured up to ~50%);
  - if the front camera is streaming at the same time, stop it first: the
    OV5693 (port 4) and OV7251 (port 5) share MCD PHY1, and starting the IR
    while the front holds the PHY made it fail 22 times out of 22 here.

My IR capture path retries the session start automatically on that signature,
which makes it invisible in practice. Details and the register-level evidence
are in that thread.

D. Manresa <dmanresa@gmail.com>