[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?
>