[PATCH 2/2] media: i2c: ov08x40: Do not expose the broken 1928x1088 binned mode

[Pierre Pinon]

On IPU7 platforms the 1928x1088 2x2-binned mode does not deliver usable
frames: the sensor emits only the first and the last line of each frame,
and the rest of the capture buffer is never written.

Measured on a Dell Pro 14 Premium PA14260 (IPU7 + Intel CVS, 2 MIPI
lanes at 1500 Mbps) by instrumenting libcamera's software ISP to count,
for each line of the incoming buffer, how many samples were left at
0xffff:

  3856x2176 mode : 2177 of 2177 lines carry data
  1928x1088 mode :    2 of 1089 lines carry data (the first and the last)

The raw samples confirm it. In the working mode they sit in the expected
10-bit range; in the binned mode everything outside those two lines is
0xffff:

  3856x2176 : min=59  max=81
  1928x1088 : min=261 max=65535

The consequence is not cosmetic. libcamera's simple pipeline handler
selects the smallest sensor mode that can satisfy the requested output,
so every capture at or below 1928x1088 -- which includes every resolution
a browser asks for over WebRTC -- is routed to this mode and produces a
uniformly saturated image. Requests above that size use the 3856x2176
mode and work correctly.

I could not determine whether the fault lies in the mode's register list
or in how the IPU7 CSI-2 receiver handles it; the register programming is
unchanged since before commit ff1f5010a96a ("media: ov08x40: Remove
common register settings from resolution-specific table"), which I
verified does not drop or alter any register for this mode. The 4-lane
binned mode (1928x1208) could not be exercised on this hardware.

Until the cause is understood, stop advertising the mode so that
userspace falls back to the full resolution mode, which works. With this
change a 640x480 capture on the affected machine goes from a uniform
saturated frame to a correctly exposed image.

Signed-off-by: Pierre Pinon <pierre@xxxxxxxxx>
---
 drivers/media/i2c/ov08x40.c | 28 +++++++---------------------
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/media/i2c/ov08x40.c b/drivers/media/i2c/ov08x40.c
index 3de06e19803c..7b10780f25eb 100644
--- a/drivers/media/i2c/ov08x40.c
+++ b/drivers/media/i2c/ov08x40.c
@@ -1318,27 +1318,13 @@ static const struct ov08x40_mode supported_modes[] = {
 		.exposure_shift = 1,
 		.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
 	},
-	{
-		.width = 1928,
-		.height = 1088,
-		.vts_def = OV08X40_VTS_BIN_30FPS,
-		.vts_min = OV08X40_VTS_BIN_30FPS,
-		.llp = 0x960,
-		.lanes = 2,
-		.reg_list = {
-			.num_of_regs = ARRAY_SIZE(mode_1928x1088_regs_1500mbps),
-			.regs = mode_1928x1088_regs_1500mbps,
-		},
-		.crop = {
-			.left = 0,
-			.top = 120,
-			.width = 3872,
-			.height = 2192,
-		},
-		.link_freq_index = OV08X40_LINK_FREQ_749MHZ_INDEX,
-		.exposure_shift = 0,
-		.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
-	},
+	/*
+	 * The 1928x1088 binned mode is not exposed: on IPU7 platforms the
+	 * sensor delivers only the first and last line of each frame in
+	 * this mode, the rest of the buffer is never written. Measured on a
+	 * Dell Pro 14 Premium PA14260: 2 valid lines out of 1088, against
+	 * 2176/2176 in the 3856x2176 mode.
+	 */
 };
 
 static const char * const ov08x40_supply_names[] = {
-- 
2.55.0