patches/6.19: cameras: fix ov8865 stale mode when sensor is held powered (rear camera green screen) - #2169
Conversation
|
Upstream submission is on the list now: https://lore.kernel.org/linux-media/20260609232255.13559-1-eng.juri@gmail.com/ (may take a few minutes to appear in the lore index). |
|
Confirmed on Surface Pro 6 (IPU3, ov8865 rear + dw9719 VCM), kernel 6.19.8-surface-3. This only became visible here after #2123 was applied. Before that the VCM never bound, so the on every capture attempt. 2585088 = 2112 bytes/line x 1224 lines, i.e. the 1632x1224 binned mode — consistent with your "hardware left programmed for a previous mode" analysis. The delivered buffers were entirely zero (Y=0, U=0, V=0). That is what renders as the solid green frame reported in #2166 — an empty buffer, not a colour or tuning problem. One data point that differs from your Surface Book 2 findings: stopping wireplumber did not help here. With wireplumber stopped and the sensor confirmed runtime-suspended beforehand ( Results with both patches applied, rear camera pointed at a window:
Happy to run further tests on this device if useful. |
Problem
The IPU3 rear camera (ov8865) on Surface Book 2 — and likely other ov8865 devices — shows a frozen green/black frame in camera apps: the stream stalls after a single frame with
ipu3-cio2reportingframe sync errorandpayload length is X, received Ymismatches.Root cause
ov8865 writes its sensor registers only in the runtime-PM resume handler;
set_fmt()merely stores the requested mode. On IPU3 platforms,ipu_bridgegives the dw9719 VCM aDL_FLAG_PM_RUNTIMEdevice link to the sensor, so a userspace process holding the VCM subdev open (wireplumber does, on any stock desktop) pins the sensor runtime-active. After that, format changes never reach the hardware: the sensor keeps streaming the mode programmed at the last resume while CIO2 expects the newly negotiated one.Proof by inversion on SB2: with binned mode pinned, a full-res request fails with
payload length is 10340352, received 2585088— exactly one 1632x1224 binned frame where a 3264x2448 frame was expected. Stop wireplumber (sensor suspends/resumes again) and both modes stream 10/10 clean — so this is not a tuning-file issue (#2166) and not a sensor register table issue.Fix
Two patches appended to
patches/6.19/0013-cameras.patch:s_stream(1)when it differs from the negotiated mode (re-applying control values).Validation (SB2, 6.19.8-arch1-3-surface, wireplumber running = stock conditions)
cam -c1 --capture=40: 40/40 frames @ ~30 fps, no stall (previously froze on frame 1 — the green still)Being submitted to linux-media for upstream inclusion as well; will link the lore thread here once posted. Related: the rear-camera reports in #2123 (separate from the VCM fix there) and #2166.