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

[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@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[] = {
-- 
2.55.0

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

[Sakari Ailus]

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

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

[Zhang, Qingwu]

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

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

[Su, Jimmy]

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

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

[Sakari Ailus]

Hi Jimmy,

On Thu, Sep 10, 2026 at 06:28:59AM +0000, Su, Jimmy wrote:
> 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 this CVS device still works in non-binned mode. Are the exact
limitations known? Is this CVS device used in other systems?

Staggered HDR isn't supported in upstream in any case.

> But our sensor driver only supports 1928x1088@linear mode. 
> It could have unexpected issue while this device has CVS board. 

One way to address this would be to set the minimum image size to some
larger, known to work size, for that CVS device in the CVS driver. This may
require changes on libcamera side, too, but that's a separate issue.

-- 
Kind regards,

Sakari Ailus

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

[Sakari Ailus]

Hi Jimmy,

On Thu, Sep 10, 2026 at 07:33:22AM +0000, Su, Jimmy wrote:
> Hi Sakari,
> 
> According to CVS vendor, only the following two resolutions are supported:
> 
> 3856x2176@ linear mode
> 
> 1928x1088@ sHDR mode
> 
> 
> 
> Their CVFW decodes sensor MIPI data and then re-encodes/re-packs MIPI data before sending it to our IPU.
> 
> As I know, it is not feasible to modify any parameters, like the resolution, data rate etc.
> 
> 
> 
> BTW, I am not sure whether libcamera support CVS?
> 
> CVS requires specific drivers (upstream or downstream usbio & vision drivers) and CVS configuration etc.
> 
> Therefore, I assume libcamera will not work with CVS-MIPI base projects.

It currently works with the simple pipeline handler.

The CVS driver should then reject other sizes than the above on that
device.

-- 
Regards,

Sakari Ailus

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

[Sakari Ailus]

Hi Pierre,

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

Can you provide the output of lsusb on that system, plesae?

-- 
Regards,

Sakari Ailus

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

[Pierre PINON]

Hi Sakari,

Sorry for the late reply. Here it is:

   $ lsusb
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 003 Device 003: ID 06cb:0701 Synaptics, Inc. SVP7500
   Bus 003 Device 004: ID 062a:5918 MosArt Semiconductor Corp. 2.4G 
Keyboard Mouse
   Bus 003 Device 005: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID
   Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

   $ lsusb -t
   /:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
   /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 
20000M/x2
   /:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 480M
       |__ Port 002: Dev 005, If 0, Class=Human Interface Device, 
Driver=usbhid, 12M
       |__ Port 002: Dev 005, If 1, Class=Human Interface Device, 
Driver=usbhid, 12M
       |__ Port 002: Dev 005, If 2, Class=Chip/SmartCard, Driver=usbfs, 12M
       |__ Port 003: Dev 003, If 0, Class=Vendor Specific Class, 
Driver=usbio-bridge, 12M
       |__ Port 007: Dev 004, If 0, Class=Human Interface Device, 
Driver=usbhid, 12M
       |__ Port 007: Dev 004, If 1, Class=Human Interface Device, 
Driver=usbhid, 12M
   /:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 
20000M/x2

   Best regards,
   Pierre

On 9/12/26 12:16 PM, Sakari Ailus wrote:
> Hi Pierre,
>
> On Fri, Sep 04, 2026 at 03:46:00PM +0200, Pierre Pinon wrote:
>> 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:
> Can you provide the output of lsusb on that system, plesae?
>

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

[Edvinas Šulcas]

Hi,

I can confirm this on a second CVS machine, and I think the data
supports what Jimmy wrote about CVS and Sakari's suggestion to deal
with it on the CVS side.

Machine: Dell XPS 14 DA14260 (Panther Lake), OV08X40 (OVTI08F4) behind
the CVS chip (ACPI INTC10E1, USB 06cb:0701), 2 data lanes. Ubuntu
7.0.0-38-generic with the in-tree intel_ipu7 and ov08x40 (the latter
built out of tree from v7.0 for the tests), intel_cvs from
intel/vision-drivers at 845d6f8.

- 1928x1088 (2 lanes, 749 MHz link frequency): the kernel logs "error
  group 3 code 18 details [0 0]" about twice per frame, which is
  INSYS_MSG_ERR_CAPTURE_HW_ERR_BAD_FRAME_DIM as Pierre found. A raw
  dump with libcamera's raw stream (stride 3904 bytes) has data only in
  line 0 (samples 42-90); the other 1087 lines are entirely 0xffff.
  Pierre saw the first and the last line; my buffer has 1088 lines, so
  a 1089th line would not fit. In the 3856x2176 mode all 2176 lines
  carry data and there are no errors.

- It does not depend on the extra registers of the binned list. That
  list writes about 110 registers the 3856x2176 list never touches
  (0x3a1a-0x3b06, 0x4911-0x497f, 0x49e0-0x49f1) and differs in 0x4501,
  0x4542, 0x3894 and 0x5000/0x5001. With a debug parameter that drops
  each group alone, all of them, and with 0x4501/0x4542 forced to the
  full-mode values, 20 captured frames at 1280x720 gave the same number
  of errors (43 or 44) in every case. That fits Jimmy's description
  that CVS only handles 1928x1088 as sHDR while the driver programs it
  as linear: changing details of the linear programming does not help.

- It is not CPU frequency either (all CPUs at 4.3 GHz instead of
  400 MHz while capturing, the idea from libcamera issue #328): same
  errors.

- Pierre's patches 1/2 and 2/2 applied to ov08x40.c from v7.0 (2/2 with
  fuzz 1) work here: 640x480, 1280x720, 1920x1080 and 3840x2160 all run
  at 28.6 fps with zero ISYS errors, and libcamera no longer complains
  about the missing crop rectangles. I have been using it in video
  calls. For patch 2/2 as posted:

  Tested-by: Edvinas Šulcas <edvinas.sulcas@gmail.com>

Oleg's report that the mode streams fine on a Yoga Slim 7x without a
vision chip in between points the same way: the mode itself works, it
is the combination with CVS that does not. Hiding it unconditionally
would take a working mode away from boards without CVS. So I think the
better place is on the CVS side, as Sakari suggested: either only make
the mode unavailable when the sensor is behind CVS (for example the
CVS driver restricting the sizes a sensor may use), or program the
sHDR variant of 1928x1088 for that case, which I cannot do without
documentation of the sensor's sHDR setup. Until one of these exists,
2/2 is a fine workaround for the affected machines.

I can test patches or run experiments on this machine, for example
logging the ISYS CSI-2 frame/line counts with dyndbg, or trying a
larger minimum size from the CVS driver. I can also send the lsusb
output if useful.

Regards,
Edvinas Šulcas