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

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Pierre,

On Fri, Sep 04, 2026 at 03:46:00PM +0200, Pierre Pinon wrote:
> 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)

Did you use upstream kernel to test this? There are some hints the CVS
could be the culprit.

What USB and I²C devices can be found in the system?

Cc Miguel and Qingwu as well. Qingwu: any idea if the binned mode was ever
tested and if CVS was involved?

Removing a presumably otherwise working (?) mode seems a bit drastic.

> 
> 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@pinon1.fr>
> ---
>  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[] = {

-- 
Regards,

Sakari Ailus