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

["Su, Jimmy" <jimmy.su@intel.com>]

Hi Sakari, 
As I know, one of Chrome MTL project is using ov08x40 sensor. 
It supports "3856x2416@4 lanes linear mode" & "1928x1208@ 4 lanes linear mode".

Then Linux projects support 3856x2176@ 4 lanes & 2 lanes linear mode.   
BTW, Some Linux projects have CV solution. 
From one CV vendor's feedback, 1928x1088 resolution only supports sHDR mode. 
But our sensor driver only supports 1928x1088@linear mode. 
It could have unexpected issue while this device has CVS board. 

Jimmy

-----Original Message-----
From: Zhang, Qingwu <qingwu.zhang@intel.com> 
Sent: Wednesday, September 9, 2026 6:33 PM
To: Sakari Ailus <sakari.ailus@linux.intel.com>; Pierre Pinon <pierre@pinon1.fr>; Su, Jimmy <jimmy.su@intel.com>
Cc: Jason Chen <jason.z.chen@intel.com>; linux-media@vger.kernel.org; Mauro Carvalho Chehab <mchehab@kernel.org>; Hans de Goede <hansg@kernel.org>; linux-kernel@vger.kernel.org; Vadillo, Miguel <miguel.vadillo@intel.com>
Subject: RE: [PATCH 2/2] media: i2c: ov08x40: Do not expose the broken 1928x1088 binned mode


Hi Sakari,

The binned mode of ov08x40 was verified and already had been used on many projects of Chrome and Linux.
We didn't verify the binned mode with CVS due to no such device in hand.

@Su, Jimmy, please help to comment if verified with CVS before.

Best Regards
Qingwu

-----Original Message-----
From: Sakari Ailus <sakari.ailus@linux.intel.com>
Sent: Tuesday, September 8, 2026 5:42 PM
To: Pierre Pinon <pierre@pinon1.fr>
Cc: Jason Chen <jason.z.chen@intel.com>; Su, Jimmy <jimmy.su@intel.com>; linux-media@vger.kernel.org; Mauro Carvalho Chehab <mchehab@kernel.org>; Hans de Goede <hansg@kernel.org>; linux-kernel@vger.kernel.org; Vadillo, Miguel <miguel.vadillo@intel.com>; Zhang, Qingwu <qingwu.zhang@intel.com>
Subject: Re: [PATCH 2/2] media: i2c: ov08x40: Do not expose the broken 1928x1088 binned mode

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