[PATCH v2 regression fix for 6.19 0/5] media: ov02c10: h/vflip fixes

[PATCH v2 regression fix for 6.19 0/5] media: ov02c10: h/vflip fixes

[Hans de Goede]

Hi All,

Commit 69fe27173396 ("media: ov02c10: Fix default vertical flip") which
has been merged this merge window is causing various problems for
laptops with a ov02c10 sensors:

1. This changes the vflip default but does not update the bayer-order
   leading to debayer artifacts and wrong colors

2. The ov02c10 driver was originally developed on a XPS 16 9640 which
   has its sensor upside down. Changing the vflip (and hflip) default
   values fixes the image being upside down on other laptops, but will
   cause a regression on Dell XPS models causing the image to be upside
   down there.

3. The mentioned commit only changes vflip, so the image now is upside-up,
   but it is still mirrored.

Patches 1-4 of this series fixes these issues. Patch 5 is a follow-up
cleanup patch.

Hans Verkuil, can you please queue these up as fixes for 6.19?

Changes in v2:
- Fix Fixes tags to use the correct commit hash
- Fix compile error in patch 4/5 when CONFIG_ACPI is not set
- Add Bryan's Reviewed-by to all patches

Regards,

Hans


Hans de Goede (5):
  media: ov02c10: Fix bayer-pattern change after default vflip change
  media: ov02c10: Adjust x-win/y-win when changing flipping to preserve
    bayer-pattern
  media: ov02c10: Fix the horizontal flip control
  media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down
    sensors
  media: ov02c10: Remove unnecessary hflip and vflip pointers

 drivers/media/i2c/ov02c10.c          | 28 +++++++++++----------------
 drivers/media/pci/intel/Kconfig      |  2 +-
 drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+), 18 deletions(-)

-- 
2.52.0

[PATCH v2 1/5] media: ov02c10: Fix bayer-pattern change after default vflip change

[Hans de Goede]

After commit d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
the reported bayer-pattern of MEDIA_BUS_FMT_SGRBG10_1X10 is no longer
correct.

Change the 16-bit x-win register (0x3810) value from 2 to 1 so that
the sensor will generate data in GRBG bayer-order again.

Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
Cc: stable@vger.kernel.org
Cc: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
 drivers/media/i2c/ov02c10.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
index b1e540eb8326..6369841de88b 100644
--- a/drivers/media/i2c/ov02c10.c
+++ b/drivers/media/i2c/ov02c10.c
@@ -168,7 +168,7 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
 	{0x3810, 0x00},
 	{0x3811, 0x02},
 	{0x3812, 0x00},
-	{0x3813, 0x02},
+	{0x3813, 0x01},
 	{0x3814, 0x01},
 	{0x3815, 0x01},
 	{0x3816, 0x01},
-- 
2.52.0

[PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

[Hans de Goede]

The ov02c10 is capable of having its (crop) window shifted around with 1
pixel precision while streaming.

This allows changing the x/y window coordinates when changing flipping to
preserve the bayer-pattern.

__v4l2_ctrl_handler_setup() will now write the window coordinates at 0x3810
and 0x3812 so these can be dropped from sensor_1928x1092_30fps_setting.

Since the bayer-pattern is now unchanged, the V4L2_CTRL_FLAG_MODIFY_LAYOUT
flag can be dropped from the flip controls.

Note the original use of the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag was
incomplete, besides setting the flag the driver should also have reported
a different mbus code when getting the source pad's format depending on
the hflip / vflip settings see the ov2680.c driver for example.

Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip")
Cc: stable@vger.kernel.org
Cc: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
 drivers/media/i2c/ov02c10.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
index 6369841de88b..384c2f0b1608 100644
--- a/drivers/media/i2c/ov02c10.c
+++ b/drivers/media/i2c/ov02c10.c
@@ -165,10 +165,6 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
 	{0x3809, 0x88},
 	{0x380a, 0x04},
 	{0x380b, 0x44},
-	{0x3810, 0x00},
-	{0x3811, 0x02},
-	{0x3812, 0x00},
-	{0x3813, 0x01},
 	{0x3814, 0x01},
 	{0x3815, 0x01},
 	{0x3816, 0x01},
@@ -465,11 +461,15 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
 		break;
 
 	case V4L2_CID_HFLIP:
+		cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL,
+			  ctrl->val ? 1 : 2, &ret);
 		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
 				BIT(3), ov02c10->hflip->val << 3, &ret);
 		break;
 
 	case V4L2_CID_VFLIP:
+		cci_write(ov02c10->regmap, OV02C10_ISP_Y_WIN_CONTROL,
+			  ctrl->val ? 2 : 1, &ret);
 		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
 				BIT(4), ov02c10->vflip->val << 4, &ret);
 		break;
@@ -551,13 +551,9 @@ static int ov02c10_init_controls(struct ov02c10 *ov02c10)
 
 	ov02c10->hflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
 					   V4L2_CID_HFLIP, 0, 1, 1, 0);
-	if (ov02c10->hflip)
-		ov02c10->hflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
 
 	ov02c10->vflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
 					   V4L2_CID_VFLIP, 0, 1, 1, 0);
-	if (ov02c10->vflip)
-		ov02c10->vflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
 
 	v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &ov02c10_ctrl_ops,
 				     V4L2_CID_TEST_PATTERN,
-- 
2.52.0

[PATCH v2 3/5] media: ov02c10: Fix the horizontal flip control

[Hans de Goede]

During sensor calibration I noticed that with the hflip control set to
false/disabled the image was mirrored.

The horizontal flip control is inverted and needs to be set to 1 to not
flip. This is something which seems to be common with various recent
Omnivision sensors, the ov01a10 and ov08x40 also have an inverted
mirror control.

Invert the hflip control to fix the sensor mirroring by default.

Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip")
Cc: stable@vger.kernel.org
Cc: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
 drivers/media/i2c/ov02c10.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
index 384c2f0b1608..f912ae142040 100644
--- a/drivers/media/i2c/ov02c10.c
+++ b/drivers/media/i2c/ov02c10.c
@@ -170,7 +170,7 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
 	{0x3816, 0x01},
 	{0x3817, 0x01},
 
-	{0x3820, 0xa0},
+	{0x3820, 0xa8},
 	{0x3821, 0x00},
 	{0x3822, 0x80},
 	{0x3823, 0x08},
@@ -462,9 +462,9 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
 
 	case V4L2_CID_HFLIP:
 		cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL,
-			  ctrl->val ? 1 : 2, &ret);
+			  ctrl->val ? 2 : 1, &ret);
 		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
-				BIT(3), ov02c10->hflip->val << 3, &ret);
+				BIT(3), ctrl->val ? 0 : BIT(3), &ret);
 		break;
 
 	case V4L2_CID_VFLIP:
-- 
2.52.0

[PATCH v2 4/5] media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors

[Hans de Goede]

The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted
OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor
the _PLD for the sensor (both report a rotation of 0°).

Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries
to the DMI quirk list for these 2 laptops.

Note the OV02C10 driver was originally developed on a XPS 16 9640 which
resulted in inverted vflip + hflip settings making it look like the sensor
was upright on the XPS 16 9640 and upside down elsewhere this has been
fixed in commit 69fe27173396 ("media: ov02c10: Fix default vertical flip").
This makes this commit a regression fix since now the video is upside down
on these Dell XPS models where it was not before.

Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
Cc: stable@vger.kernel.org
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
Changes in v2:
- Fix fixes tag to use the correct commit hash
- Drop || COMPILE_TEST from Kconfig to fix compile errors when ACPI is disabled
---
 drivers/media/pci/intel/Kconfig      |  2 +-
 drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/intel/Kconfig b/drivers/media/pci/intel/Kconfig
index d9fcddce028b..3f14ca110d06 100644
--- a/drivers/media/pci/intel/Kconfig
+++ b/drivers/media/pci/intel/Kconfig
@@ -6,7 +6,7 @@ source "drivers/media/pci/intel/ivsc/Kconfig"
 
 config IPU_BRIDGE
 	tristate "Intel IPU Bridge"
-	depends on ACPI || COMPILE_TEST
+	depends on ACPI
 	depends on I2C
 	help
 	  The IPU bridge is a helper library for Intel IPU drivers to
diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 58ea01d40c0d..6463b2a47d78 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -5,6 +5,7 @@
 #include <acpi/acpi_bus.h>
 #include <linux/cleanup.h>
 #include <linux/device.h>
+#include <linux/dmi.h>
 #include <linux/i2c.h>
 #include <linux/mei_cl_bus.h>
 #include <linux/platform_device.h>
@@ -99,6 +100,28 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = {
 	IPU_SENSOR_CONFIG("XMCC0003", 1, 321468000),
 };
 
+/*
+ * DMI matches for laptops which have their sensor mounted upside-down
+ * without reporting a rotation of 180° in neither the SSDB nor the _PLD.
+ */
+static const struct dmi_system_id upside_down_sensor_dmi_ids[] = {
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 13 9350"),
+		},
+		.driver_data = "OVTI02C1",
+	},
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 16 9640"),
+		},
+		.driver_data = "OVTI02C1",
+	},
+	{} /* Terminating entry */
+};
+
 static const struct ipu_property_names prop_names = {
 	.clock_frequency = "clock-frequency",
 	.rotation = "rotation",
@@ -249,6 +272,12 @@ static int ipu_bridge_read_acpi_buffer(struct acpi_device *adev, char *id,
 static u32 ipu_bridge_parse_rotation(struct acpi_device *adev,
 				     struct ipu_sensor_ssdb *ssdb)
 {
+	const struct dmi_system_id *dmi_id;
+
+	dmi_id = dmi_first_match(upside_down_sensor_dmi_ids);
+	if (dmi_id && acpi_dev_hid_match(adev, dmi_id->driver_data))
+		return 180;
+
 	switch (ssdb->degree) {
 	case IPU_SENSOR_ROTATION_NORMAL:
 		return 0;
-- 
2.52.0

[PATCH v2 5/5] media: ov02c10: Remove unnecessary hflip and vflip pointers

[Hans de Goede]

The cci_update_bits() inside ov02c10_set_ctrl() can used the passed
data in the ctrl argument to access the vflip control value.

After changing this there is no need to store a pointer to the hflip
and vflip controls inside struct ov02c10, drop these.

Cc: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
Changes in v2:
- Small commit msg tweak suggested by Bryan
---
 drivers/media/i2c/ov02c10.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
index f912ae142040..cf93d36032e1 100644
--- a/drivers/media/i2c/ov02c10.c
+++ b/drivers/media/i2c/ov02c10.c
@@ -381,8 +381,6 @@ struct ov02c10 {
 	struct v4l2_ctrl *vblank;
 	struct v4l2_ctrl *hblank;
 	struct v4l2_ctrl *exposure;
-	struct v4l2_ctrl *hflip;
-	struct v4l2_ctrl *vflip;
 
 	struct clk *img_clk;
 	struct gpio_desc *reset;
@@ -471,7 +469,7 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
 		cci_write(ov02c10->regmap, OV02C10_ISP_Y_WIN_CONTROL,
 			  ctrl->val ? 2 : 1, &ret);
 		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
-				BIT(4), ov02c10->vflip->val << 4, &ret);
+				BIT(4), ctrl->val << 4, &ret);
 		break;
 
 	default:
@@ -549,11 +547,11 @@ static int ov02c10_init_controls(struct ov02c10 *ov02c10)
 					      OV02C10_EXPOSURE_STEP,
 					      exposure_max);
 
-	ov02c10->hflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
-					   V4L2_CID_HFLIP, 0, 1, 1, 0);
+	v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops, V4L2_CID_HFLIP,
+			  0, 1, 1, 0);
 
-	ov02c10->vflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
-					   V4L2_CID_VFLIP, 0, 1, 1, 0);
+	v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops, V4L2_CID_VFLIP,
+			  0, 1, 1, 0);
 
 	v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &ov02c10_ctrl_ops,
 				     V4L2_CID_TEST_PATTERN,
-- 
2.52.0

Re: [PATCH v2 regression fix for 6.19 0/5] media: ov02c10: h/vflip fixes

[Hans Verkuil]

Hi Hans,

On 10/12/2025 12:24, Hans de Goede wrote:
> Hi All,
> 
> Commit 69fe27173396 ("media: ov02c10: Fix default vertical flip") which
> has been merged this merge window is causing various problems for
> laptops with a ov02c10 sensors:
> 
> 1. This changes the vflip default but does not update the bayer-order
>    leading to debayer artifacts and wrong colors
> 
> 2. The ov02c10 driver was originally developed on a XPS 16 9640 which
>    has its sensor upside down. Changing the vflip (and hflip) default
>    values fixes the image being upside down on other laptops, but will
>    cause a regression on Dell XPS models causing the image to be upside
>    down there.
> 
> 3. The mentioned commit only changes vflip, so the image now is upside-up,
>    but it is still mirrored.
> 
> Patches 1-4 of this series fixes these issues. Patch 5 is a follow-up
> cleanup patch.
> 
> Hans Verkuil, can you please queue these up as fixes for 6.19?

It's best to wait until v6.19-rc1 is released, then add these patches
on top and post a PR with subject prefix [GIT FIXES for v6.19].

Either Mauro or myself will pick it up (probably Mauro since I'm about
to go on vacation).

Regards,

	Hans

> 
> Changes in v2:
> - Fix Fixes tags to use the correct commit hash
> - Fix compile error in patch 4/5 when CONFIG_ACPI is not set
> - Add Bryan's Reviewed-by to all patches
> 
> Regards,
> 
> Hans
> 
> 
> Hans de Goede (5):
>   media: ov02c10: Fix bayer-pattern change after default vflip change
>   media: ov02c10: Adjust x-win/y-win when changing flipping to preserve
>     bayer-pattern
>   media: ov02c10: Fix the horizontal flip control
>   media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down
>     sensors
>   media: ov02c10: Remove unnecessary hflip and vflip pointers
> 
>  drivers/media/i2c/ov02c10.c          | 28 +++++++++++----------------
>  drivers/media/pci/intel/Kconfig      |  2 +-
>  drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++
>  3 files changed, 41 insertions(+), 18 deletions(-)
> 

Re: [PATCH v2 1/5] media: ov02c10: Fix bayer-pattern change after default vflip change

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Hi,

On Wed, Dec 10, 2025 at 12:24:32PM +0100, Hans de Goede wrote:
> After commit d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
> the reported bayer-pattern of MEDIA_BUS_FMT_SGRBG10_1X10 is no longer
> correct.
> 
> Change the 16-bit x-win register (0x3810) value from 2 to 1 so that
> the sensor will generate data in GRBG bayer-order again.
> 
> Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
> Cc: stable@vger.kernel.org
> Cc: Sebastian Reichel <sre@kernel.org>
> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---

I'm not sure it's worth having this change, considering you are
dropping the whole setting in the next patch, which also has a
Fixes tag. In any case:

Reviewed-by: Sebastian Reichel <sre@kernel.org>

-- Sebastian

>  drivers/media/i2c/ov02c10.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
> index b1e540eb8326..6369841de88b 100644
> --- a/drivers/media/i2c/ov02c10.c
> +++ b/drivers/media/i2c/ov02c10.c
> @@ -168,7 +168,7 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
>  	{0x3810, 0x00},
>  	{0x3811, 0x02},
>  	{0x3812, 0x00},
> -	{0x3813, 0x02},
> +	{0x3813, 0x01},
>  	{0x3814, 0x01},
>  	{0x3815, 0x01},
>  	{0x3816, 0x01},
> -- 
> 2.52.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

Hi,

On Wed, Dec 10, 2025 at 12:24:33PM +0100, Hans de Goede wrote:
> The ov02c10 is capable of having its (crop) window shifted around with 1
> pixel precision while streaming.
> 
> This allows changing the x/y window coordinates when changing flipping to
> preserve the bayer-pattern.
> 
> __v4l2_ctrl_handler_setup() will now write the window coordinates at 0x3810
> and 0x3812 so these can be dropped from sensor_1928x1092_30fps_setting.
> 
> Since the bayer-pattern is now unchanged, the V4L2_CTRL_FLAG_MODIFY_LAYOUT
> flag can be dropped from the flip controls.
> 
> Note the original use of the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag was
> incomplete, besides setting the flag the driver should also have reported
> a different mbus code when getting the source pad's format depending on
> the hflip / vflip settings see the ov2680.c driver for example.
> 
> Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip")
> Cc: stable@vger.kernel.org
> Cc: Sebastian Reichel <sre@kernel.org>
> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---

Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org> # T14s Gen6 Snapdragon

Greetings,

-- Sebastian

>  drivers/media/i2c/ov02c10.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
> index 6369841de88b..384c2f0b1608 100644
> --- a/drivers/media/i2c/ov02c10.c
> +++ b/drivers/media/i2c/ov02c10.c
> @@ -165,10 +165,6 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
>  	{0x3809, 0x88},
>  	{0x380a, 0x04},
>  	{0x380b, 0x44},
> -	{0x3810, 0x00},
> -	{0x3811, 0x02},
> -	{0x3812, 0x00},
> -	{0x3813, 0x01},
>  	{0x3814, 0x01},
>  	{0x3815, 0x01},
>  	{0x3816, 0x01},
> @@ -465,11 +461,15 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
>  		break;
>  
>  	case V4L2_CID_HFLIP:
> +		cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL,
> +			  ctrl->val ? 1 : 2, &ret);
>  		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
>  				BIT(3), ov02c10->hflip->val << 3, &ret);
>  		break;
>  
>  	case V4L2_CID_VFLIP:
> +		cci_write(ov02c10->regmap, OV02C10_ISP_Y_WIN_CONTROL,
> +			  ctrl->val ? 2 : 1, &ret);
>  		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
>  				BIT(4), ov02c10->vflip->val << 4, &ret);
>  		break;
> @@ -551,13 +551,9 @@ static int ov02c10_init_controls(struct ov02c10 *ov02c10)
>  
>  	ov02c10->hflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
>  					   V4L2_CID_HFLIP, 0, 1, 1, 0);
> -	if (ov02c10->hflip)
> -		ov02c10->hflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
>  
>  	ov02c10->vflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
>  					   V4L2_CID_VFLIP, 0, 1, 1, 0);
> -	if (ov02c10->vflip)
> -		ov02c10->vflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
>  
>  	v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &ov02c10_ctrl_ops,
>  				     V4L2_CID_TEST_PATTERN,
> -- 
> 2.52.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/5] media: ov02c10: Fix the horizontal flip control

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

Hi,

On Wed, Dec 10, 2025 at 12:24:34PM +0100, Hans de Goede wrote:
> During sensor calibration I noticed that with the hflip control set to
> false/disabled the image was mirrored.
> 
> The horizontal flip control is inverted and needs to be set to 1 to not
> flip. This is something which seems to be common with various recent
> Omnivision sensors, the ov01a10 and ov08x40 also have an inverted
> mirror control.
> 
> Invert the hflip control to fix the sensor mirroring by default.
> 
> Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip")
> Cc: stable@vger.kernel.org
> Cc: Sebastian Reichel <sre@kernel.org>
> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---

Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org> # T14s Gen6 Snapdragon

Greetings,

-- Sebastian

>  drivers/media/i2c/ov02c10.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
> index 384c2f0b1608..f912ae142040 100644
> --- a/drivers/media/i2c/ov02c10.c
> +++ b/drivers/media/i2c/ov02c10.c
> @@ -170,7 +170,7 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
>  	{0x3816, 0x01},
>  	{0x3817, 0x01},
>  
> -	{0x3820, 0xa0},
> +	{0x3820, 0xa8},
>  	{0x3821, 0x00},
>  	{0x3822, 0x80},
>  	{0x3823, 0x08},
> @@ -462,9 +462,9 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
>  
>  	case V4L2_CID_HFLIP:
>  		cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL,
> -			  ctrl->val ? 1 : 2, &ret);
> +			  ctrl->val ? 2 : 1, &ret);
>  		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
> -				BIT(3), ov02c10->hflip->val << 3, &ret);
> +				BIT(3), ctrl->val ? 0 : BIT(3), &ret);
>  		break;
>  
>  	case V4L2_CID_VFLIP:
> -- 
> 2.52.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 5/5] media: ov02c10: Remove unnecessary hflip and vflip pointers

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

Hi,

On Wed, Dec 10, 2025 at 12:24:36PM +0100, Hans de Goede wrote:
> The cci_update_bits() inside ov02c10_set_ctrl() can used the passed
> data in the ctrl argument to access the vflip control value.
> 
> After changing this there is no need to store a pointer to the hflip
> and vflip controls inside struct ov02c10, drop these.
> 
> Cc: Sebastian Reichel <sre@kernel.org>
> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---

Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org> # T14s Gen6 Snapdragon

Greetings,

-- Sebastian

> Changes in v2:
> - Small commit msg tweak suggested by Bryan
> ---
>  drivers/media/i2c/ov02c10.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
> index f912ae142040..cf93d36032e1 100644
> --- a/drivers/media/i2c/ov02c10.c
> +++ b/drivers/media/i2c/ov02c10.c
> @@ -381,8 +381,6 @@ struct ov02c10 {
>  	struct v4l2_ctrl *vblank;
>  	struct v4l2_ctrl *hblank;
>  	struct v4l2_ctrl *exposure;
> -	struct v4l2_ctrl *hflip;
> -	struct v4l2_ctrl *vflip;
>  
>  	struct clk *img_clk;
>  	struct gpio_desc *reset;
> @@ -471,7 +469,7 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
>  		cci_write(ov02c10->regmap, OV02C10_ISP_Y_WIN_CONTROL,
>  			  ctrl->val ? 2 : 1, &ret);
>  		cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
> -				BIT(4), ov02c10->vflip->val << 4, &ret);
> +				BIT(4), ctrl->val << 4, &ret);
>  		break;
>  
>  	default:
> @@ -549,11 +547,11 @@ static int ov02c10_init_controls(struct ov02c10 *ov02c10)
>  					      OV02C10_EXPOSURE_STEP,
>  					      exposure_max);
>  
> -	ov02c10->hflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
> -					   V4L2_CID_HFLIP, 0, 1, 1, 0);
> +	v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops, V4L2_CID_HFLIP,
> +			  0, 1, 1, 0);
>  
> -	ov02c10->vflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
> -					   V4L2_CID_VFLIP, 0, 1, 1, 0);
> +	v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops, V4L2_CID_VFLIP,
> +			  0, 1, 1, 0);
>  
>  	v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &ov02c10_ctrl_ops,
>  				     V4L2_CID_TEST_PATTERN,
> -- 
> 2.52.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 4/5] media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3885 bytes --]

Hi,

On Wed, Dec 10, 2025 at 12:24:35PM +0100, Hans de Goede wrote:
> The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted
> OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor
> the _PLD for the sensor (both report a rotation of 0°).
> 
> Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries
> to the DMI quirk list for these 2 laptops.
> 
> Note the OV02C10 driver was originally developed on a XPS 16 9640 which
> resulted in inverted vflip + hflip settings making it look like the sensor
> was upright on the XPS 16 9640 and upside down elsewhere this has been
> fixed in commit 69fe27173396 ("media: ov02c10: Fix default vertical flip").
> This makes this commit a regression fix since now the video is upside down
> on these Dell XPS models where it was not before.
> 
> Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
> Cc: stable@vger.kernel.org
> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fix fixes tag to use the correct commit hash
> - Drop || COMPILE_TEST from Kconfig to fix compile errors when ACPI is disabled
> ---

Reviewed-by: Sebastian Reichel <sre@kernel.org>

-- Sebastian

>  drivers/media/pci/intel/Kconfig      |  2 +-
>  drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/pci/intel/Kconfig b/drivers/media/pci/intel/Kconfig
> index d9fcddce028b..3f14ca110d06 100644
> --- a/drivers/media/pci/intel/Kconfig
> +++ b/drivers/media/pci/intel/Kconfig
> @@ -6,7 +6,7 @@ source "drivers/media/pci/intel/ivsc/Kconfig"
>  
>  config IPU_BRIDGE
>  	tristate "Intel IPU Bridge"
> -	depends on ACPI || COMPILE_TEST
> +	depends on ACPI
>  	depends on I2C
>  	help
>  	  The IPU bridge is a helper library for Intel IPU drivers to
> diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
> index 58ea01d40c0d..6463b2a47d78 100644
> --- a/drivers/media/pci/intel/ipu-bridge.c
> +++ b/drivers/media/pci/intel/ipu-bridge.c
> @@ -5,6 +5,7 @@
>  #include <acpi/acpi_bus.h>
>  #include <linux/cleanup.h>
>  #include <linux/device.h>
> +#include <linux/dmi.h>
>  #include <linux/i2c.h>
>  #include <linux/mei_cl_bus.h>
>  #include <linux/platform_device.h>
> @@ -99,6 +100,28 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = {
>  	IPU_SENSOR_CONFIG("XMCC0003", 1, 321468000),
>  };
>  
> +/*
> + * DMI matches for laptops which have their sensor mounted upside-down
> + * without reporting a rotation of 180° in neither the SSDB nor the _PLD.
> + */
> +static const struct dmi_system_id upside_down_sensor_dmi_ids[] = {
> +	{
> +		.matches = {
> +			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> +			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 13 9350"),
> +		},
> +		.driver_data = "OVTI02C1",
> +	},
> +	{
> +		.matches = {
> +			DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> +			DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 16 9640"),
> +		},
> +		.driver_data = "OVTI02C1",
> +	},
> +	{} /* Terminating entry */
> +};
> +
>  static const struct ipu_property_names prop_names = {
>  	.clock_frequency = "clock-frequency",
>  	.rotation = "rotation",
> @@ -249,6 +272,12 @@ static int ipu_bridge_read_acpi_buffer(struct acpi_device *adev, char *id,
>  static u32 ipu_bridge_parse_rotation(struct acpi_device *adev,
>  				     struct ipu_sensor_ssdb *ssdb)
>  {
> +	const struct dmi_system_id *dmi_id;
> +
> +	dmi_id = dmi_first_match(upside_down_sensor_dmi_ids);
> +	if (dmi_id && acpi_dev_hid_match(adev, dmi_id->driver_data))
> +		return 180;
> +
>  	switch (ssdb->degree) {
>  	case IPU_SENSOR_ROTATION_NORMAL:
>  		return 0;
> -- 
> 2.52.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

[Sakari Ailus]

Hi Hans,

On Wed, Dec 10, 2025 at 12:24:33PM +0100, Hans de Goede wrote:
> The ov02c10 is capable of having its (crop) window shifted around with 1
> pixel precision while streaming.
> 
> This allows changing the x/y window coordinates when changing flipping to
> preserve the bayer-pattern.

Ideally we'd use the crop selection to configure this, but given these
sensors (and drivers) are generally what they are, I guess this is probably
a reasonable way to go.

-- 
Regards,

Sakari Ailus

Re: [PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

[Hans de Goede]

Hi Sakari,

On 7-Jan-26 12:48, Sakari Ailus wrote:
> Hi Hans,
> 
> On Wed, Dec 10, 2025 at 12:24:33PM +0100, Hans de Goede wrote:
>> The ov02c10 is capable of having its (crop) window shifted around with 1
>> pixel precision while streaming.
>>
>> This allows changing the x/y window coordinates when changing flipping to
>> preserve the bayer-pattern.
> 
> Ideally we'd use the crop selection to configure this, but given these
> sensors (and drivers) are generally what they are, I guess this is probably
> a reasonable way to go.

Even in sensor drivers where we allow setting the crop selection
to get arbritrary modes, we always round the coordinates to a multiple
of 2, to avoid changing the bayer-pattern seen by userspace when
userspace changes the crop. See e.g. ov2680_set_selection().

And then when doing flipping we might add 1 to either the x and/or y
coordinate to the userspace provided crop x, y before sending it to
the sensor to make flipping not change the bayer order, see e.g.
ov01a10_set_hflip() after the v2 series you've here:

https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/ov01a10

which does (simplified):

        offset = crop->left;
        if (hflip)
                offset++;

        cci_write(ov01a10->regmap, OV01A10_REG_X_WIN, offset, &ret);

IOW we are trying to not make userspace be able to affect the bayer-pattern
through setting the crop-selection and/or flip.

So I'm not sure what you mean with "Ideally we'd use the crop selection"
because we are actively trying to avoid to have the crop-selection change
the bayer order ?

Generally speaking I think we should avoid any settings change the bayer-order
whenever possible.

Regards,

Hans


here?

Re: [PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

[Sakari Ailus]

Hi Hans,

On Wed, Jan 07, 2026 at 02:45:18PM +0100, Hans de Goede wrote:
> Hi Sakari,
> 
> On 7-Jan-26 12:48, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > On Wed, Dec 10, 2025 at 12:24:33PM +0100, Hans de Goede wrote:
> >> The ov02c10 is capable of having its (crop) window shifted around with 1
> >> pixel precision while streaming.
> >>
> >> This allows changing the x/y window coordinates when changing flipping to
> >> preserve the bayer-pattern.
> > 
> > Ideally we'd use the crop selection to configure this, but given these
> > sensors (and drivers) are generally what they are, I guess this is probably
> > a reasonable way to go.
> 
> Even in sensor drivers where we allow setting the crop selection
> to get arbritrary modes, we always round the coordinates to a multiple
> of 2, to avoid changing the bayer-pattern seen by userspace when
> userspace changes the crop. See e.g. ov2680_set_selection().
> 
> And then when doing flipping we might add 1 to either the x and/or y
> coordinate to the userspace provided crop x, y before sending it to
> the sensor to make flipping not change the bayer order, see e.g.
> ov01a10_set_hflip() after the v2 series you've here:
> 
> https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/ov01a10
> 
> which does (simplified):
> 
>         offset = crop->left;
>         if (hflip)
>                 offset++;
> 
>         cci_write(ov01a10->regmap, OV01A10_REG_X_WIN, offset, &ret);
> 
> IOW we are trying to not make userspace be able to affect the bayer-pattern
> through setting the crop-selection and/or flip.
> 
> So I'm not sure what you mean with "Ideally we'd use the crop selection"
> because we are actively trying to avoid to have the crop-selection change
> the bayer order ?
> 
> Generally speaking I think we should avoid any settings change the bayer-order
> whenever possible.

That's up to the userspace. The UAPI allows to do either so why should the
driver decide?

As noted, in this case providing that flexibility probably causes more
hassle than any benefits, so I guess this is fine.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v2 4/5] media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors

[Vladimir Zapolskiy]

On 12/10/25 13:24, Hans de Goede wrote:
> The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted
> OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor
> the _PLD for the sensor (both report a rotation of 0°).
> 
> Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries
> to the DMI quirk list for these 2 laptops.
> 
> Note the OV02C10 driver was originally developed on a XPS 16 9640 which
> resulted in inverted vflip + hflip settings making it look like the sensor
> was upright on the XPS 16 9640 and upside down elsewhere this has been
> fixed in commit 69fe27173396 ("media: ov02c10: Fix default vertical flip").
> This makes this commit a regression fix since now the video is upside down
> on these Dell XPS models where it was not before.
> 
> Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
> Cc: stable@vger.kernel.org
> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fix fixes tag to use the correct commit hash
> - Drop || COMPILE_TEST from Kconfig to fix compile errors when ACPI is disabled
> ---
>   drivers/media/pci/intel/Kconfig      |  2 +-
>   drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++
>   2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/pci/intel/Kconfig b/drivers/media/pci/intel/Kconfig
> index d9fcddce028b..3f14ca110d06 100644
> --- a/drivers/media/pci/intel/Kconfig
> +++ b/drivers/media/pci/intel/Kconfig
> @@ -6,7 +6,7 @@ source "drivers/media/pci/intel/ivsc/Kconfig"
>   
>   config IPU_BRIDGE
>   	tristate "Intel IPU Bridge"
> -	depends on ACPI || COMPILE_TEST
> +	depends on ACPI

Why this change is done? Apparently there should be a new dependency on DMI.

-- 
Best wishes,
Vladimir

Re: [PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

[Hans de Goede]

Hi,

On 7-Jan-26 22:36, Sakari Ailus wrote:
> Hi Hans,
> 
> On Wed, Jan 07, 2026 at 02:45:18PM +0100, Hans de Goede wrote:
>> Hi Sakari,
>>
>> On 7-Jan-26 12:48, Sakari Ailus wrote:
>>> Hi Hans,
>>>
>>> On Wed, Dec 10, 2025 at 12:24:33PM +0100, Hans de Goede wrote:
>>>> The ov02c10 is capable of having its (crop) window shifted around with 1
>>>> pixel precision while streaming.
>>>>
>>>> This allows changing the x/y window coordinates when changing flipping to
>>>> preserve the bayer-pattern.
>>>
>>> Ideally we'd use the crop selection to configure this, but given these
>>> sensors (and drivers) are generally what they are, I guess this is probably
>>> a reasonable way to go.
>>
>> Even in sensor drivers where we allow setting the crop selection
>> to get arbritrary modes, we always round the coordinates to a multiple
>> of 2, to avoid changing the bayer-pattern seen by userspace when
>> userspace changes the crop. See e.g. ov2680_set_selection().
>>
>> And then when doing flipping we might add 1 to either the x and/or y
>> coordinate to the userspace provided crop x, y before sending it to
>> the sensor to make flipping not change the bayer order, see e.g.
>> ov01a10_set_hflip() after the v2 series you've here:
>>
>> https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/ov01a10
>>
>> which does (simplified):
>>
>>         offset = crop->left;
>>         if (hflip)
>>                 offset++;
>>
>>         cci_write(ov01a10->regmap, OV01A10_REG_X_WIN, offset, &ret);
>>
>> IOW we are trying to not make userspace be able to affect the bayer-pattern
>> through setting the crop-selection and/or flip.
>>
>> So I'm not sure what you mean with "Ideally we'd use the crop selection"
>> because we are actively trying to avoid to have the crop-selection change
>> the bayer order ?
>>
>> Generally speaking I think we should avoid any settings change the bayer-order
>> whenever possible.
> 
> That's up to the userspace. The UAPI allows to do either so why should the
> driver decide?
> 
> As noted, in this case providing that flexibility probably causes more
> hassle than any benefits, so I guess this is fine.

If we allow setting the crop selection with a 1 pixel precision drivers
need some equivalent of V4L2_CTRL_FLAG_MODIFY_LAYOUT for userspace, so IMHO
the UAPI does not allow this at the moment.

Also drivers would get extra complicated by needing to figure out which
bayer order to report as being active based on the crop selection.

I really so no use-case where we need the single precision crop selection.

So when you say "in this case providing that flexibility probably causes more
hassle than any benefits" I believe that statement applies more general then
just in this case.

Regards,

Hans

Re: [PATCH v2 4/5] media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors

[Hans de Goede]

HI,

On 7-Jan-26 22:53, Vladimir Zapolskiy wrote:
> On 12/10/25 13:24, Hans de Goede wrote:
>> The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted
>> OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor
>> the _PLD for the sensor (both report a rotation of 0°).
>>
>> Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries
>> to the DMI quirk list for these 2 laptops.
>>
>> Note the OV02C10 driver was originally developed on a XPS 16 9640 which
>> resulted in inverted vflip + hflip settings making it look like the sensor
>> was upright on the XPS 16 9640 and upside down elsewhere this has been
>> fixed in commit 69fe27173396 ("media: ov02c10: Fix default vertical flip").
>> This makes this commit a regression fix since now the video is upside down
>> on these Dell XPS models where it was not before.
>>
>> Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
>> Cc: stable@vger.kernel.org
>> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
>> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Fix fixes tag to use the correct commit hash
>> - Drop || COMPILE_TEST from Kconfig to fix compile errors when ACPI is disabled
>> ---
>>   drivers/media/pci/intel/Kconfig      |  2 +-
>>   drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++
>>   2 files changed, 30 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/pci/intel/Kconfig b/drivers/media/pci/intel/Kconfig
>> index d9fcddce028b..3f14ca110d06 100644
>> --- a/drivers/media/pci/intel/Kconfig
>> +++ b/drivers/media/pci/intel/Kconfig
>> @@ -6,7 +6,7 @@ source "drivers/media/pci/intel/ivsc/Kconfig"
>>     config IPU_BRIDGE
>>       tristate "Intel IPU Bridge"
>> -    depends on ACPI || COMPILE_TEST
>> +    depends on ACPI
> 
> Why this change is done? Apparently there should be a new dependency on DMI.

This patch introduces an acpi_dev_hid_match() call which requires config ACPI
to be set.

And there is very little value in having COMPILE_TEST here since this driver
only makes sense in combination with ACPI, as it works-around short-comings
of the MIPI camera descriptions in ACPI tables.

Regards,

Hans

Re: [PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

[Sakari Ailus]

Hi Hans,

On Thu, Jan 08, 2026 at 09:38:16AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 7-Jan-26 22:36, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > On Wed, Jan 07, 2026 at 02:45:18PM +0100, Hans de Goede wrote:
> >> Hi Sakari,
> >>
> >> On 7-Jan-26 12:48, Sakari Ailus wrote:
> >>> Hi Hans,
> >>>
> >>> On Wed, Dec 10, 2025 at 12:24:33PM +0100, Hans de Goede wrote:
> >>>> The ov02c10 is capable of having its (crop) window shifted around with 1
> >>>> pixel precision while streaming.
> >>>>
> >>>> This allows changing the x/y window coordinates when changing flipping to
> >>>> preserve the bayer-pattern.
> >>>
> >>> Ideally we'd use the crop selection to configure this, but given these
> >>> sensors (and drivers) are generally what they are, I guess this is probably
> >>> a reasonable way to go.
> >>
> >> Even in sensor drivers where we allow setting the crop selection
> >> to get arbritrary modes, we always round the coordinates to a multiple
> >> of 2, to avoid changing the bayer-pattern seen by userspace when
> >> userspace changes the crop. See e.g. ov2680_set_selection().
> >>
> >> And then when doing flipping we might add 1 to either the x and/or y
> >> coordinate to the userspace provided crop x, y before sending it to
> >> the sensor to make flipping not change the bayer order, see e.g.
> >> ov01a10_set_hflip() after the v2 series you've here:
> >>
> >> https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/ov01a10
> >>
> >> which does (simplified):
> >>
> >>         offset = crop->left;
> >>         if (hflip)
> >>                 offset++;
> >>
> >>         cci_write(ov01a10->regmap, OV01A10_REG_X_WIN, offset, &ret);
> >>
> >> IOW we are trying to not make userspace be able to affect the bayer-pattern
> >> through setting the crop-selection and/or flip.
> >>
> >> So I'm not sure what you mean with "Ideally we'd use the crop selection"
> >> because we are actively trying to avoid to have the crop-selection change
> >> the bayer order ?
> >>
> >> Generally speaking I think we should avoid any settings change the bayer-order
> >> whenever possible.
> > 
> > That's up to the userspace. The UAPI allows to do either so why should the
> > driver decide?
> > 
> > As noted, in this case providing that flexibility probably causes more
> > hassle than any benefits, so I guess this is fine.
> 
> If we allow setting the crop selection with a 1 pixel precision drivers
> need some equivalent of V4L2_CTRL_FLAG_MODIFY_LAYOUT for userspace, so IMHO
> the UAPI does not allow this at the moment.

I'm not quite sure why you'd say that. The user space needs to be (and is)
aware of the colour filter array pattern in use.

> 
> Also drivers would get extra complicated by needing to figure out which
> bayer order to report as being active based on the crop selection.

This isn't really different from the effects of flipping in general and
will change with the generic raw formats in any case.

> 
> I really so no use-case where we need the single precision crop selection.
> 
> So when you say "in this case providing that flexibility probably causes more
> hassle than any benefits" I believe that statement applies more general then
> just in this case.

I have to disagree with that in a general case. This is exactly the kind of
design that has lead us into trouble when it has been applied, especially
when it comes to UAPI.

-- 
Regards,

Sakari Ailus