linux-kernel - Re: [PATCH v2 12/20] media: i2c: ov4689: Implement vflip/hflip controls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZdpL4UxSy8elHkdZ@kekkonen.localdomain>
Date: Sat, 24 Feb 2024 20:04:49 +0000
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: Mikhail Rudenko <mike.rudenko@...il.com>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Jacopo Mondi <jacopo@...ndi.org>,
	Tommaso Merciai <tomm.merciai@...il.com>,
	Christophe JAILLET <christophe.jaillet@...adoo.fr>,
	Dave Stevenson <dave.stevenson@...pberrypi.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>
Subject: Re: [PATCH v2 12/20] media: i2c: ov4689: Implement vflip/hflip
 controls

Hi Mikhail,

On Fri, Feb 23, 2024 at 06:21:20PM +0300, Mikhail Rudenko wrote:
> 
> Hi Sakari,
> 
> and thanks for the review!
> 
> On 2024-02-23 at 08:26 GMT, Sakari Ailus <sakari.ailus@...ux.intel.com> wrote:
> 
> > Hi Mikhail,
> >
> > On Mon, Dec 18, 2023 at 08:40:33PM +0300, Mikhail Rudenko wrote:
> >> The OV4689 sensor supports horizontal and vertical flipping. Add
> >> appropriate controls to the driver. Toggling both array flip and
> >> digital flip bits allows to achieve flipping while maintaining output
> >> Bayer order. Note that the default value of hflip control corresponds
> >> to both bits set, as it was before this patch.
> >>
> >> Signed-off-by: Mikhail Rudenko <mike.rudenko@...il.com>
> >> ---
> >>  drivers/media/i2c/ov4689.c | 24 ++++++++++++++++++++++--
> >>  1 file changed, 22 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/ov4689.c b/drivers/media/i2c/ov4689.c
> >> index 06ed9d22b2c8..6cf986bf305d 100644
> >> --- a/drivers/media/i2c/ov4689.c
> >> +++ b/drivers/media/i2c/ov4689.c
> >> @@ -42,6 +42,14 @@
> >>  #define OV4689_REG_VTS			CCI_REG16(0x380e)
> >>  #define OV4689_VTS_MAX			0x7fff
> >>
> >> +#define OV4689_REG_TIMING_FORMAT1	CCI_REG8(0x3820)
> >> +#define OV4689_REG_TIMING_FORMAT2	CCI_REG8(0x3821)
> >> +#define OV4689_TIMING_FLIP_MASK		GENMASK(2, 1)
> >> +#define OV4689_TIMING_FLIP_ARRAY	BIT(1)
> >> +#define OV4689_TIMING_FLIP_DIGITAL	BIT(2)
> >> +#define OV4689_TIMING_FLIP_BOTH		(OV4689_TIMING_FLIP_ARRAY |\
> >> +					 OV4689_TIMING_FLIP_DIGITAL)
> >> +
> >>  #define OV4689_REG_TEST_PATTERN		CCI_REG8(0x5040)
> >>  #define OV4689_TEST_PATTERN_ENABLE	0x80
> >>  #define OV4689_TEST_PATTERN_DISABLE	0x0
> >> @@ -183,7 +191,6 @@ static const struct cci_reg_sequence ov4689_2688x1520_regs[] = {
> >>  	{CCI_REG8(0x3811), 0x08}, /* H_WIN_OFF_L h_win_off[7:0] = 0x08*/
> >>  	{CCI_REG8(0x3813), 0x04}, /* V_WIN_OFF_L v_win_off[7:0] = 0x04 */
> >>  	{CCI_REG8(0x3819), 0x01}, /* VSYNC_END_L vsync_end_point[7:0] = 0x01 */
> >> -	{CCI_REG8(0x3821), 0x06}, /* TIMING_FORMAT2 array_h_mirror = 1, digital_h_mirror = 1 */
> >>
> >>  	/* OTP control */
> >>  	{CCI_REG8(0x3d85), 0x36}, /* OTP_REG85 OTP_power_up_load_setting_enable = 1,
> >> @@ -607,6 +614,16 @@ static int ov4689_set_ctrl(struct v4l2_ctrl *ctrl)
> >>  			  (ctrl->val + ov4689->cur_mode->width) /
> >>  			  OV4689_HTS_DIVIDER, &ret);
> >>  		break;
> >> +	case V4L2_CID_VFLIP:
> >> +		cci_update_bits(regmap, OV4689_REG_TIMING_FORMAT1,
> >> +				OV4689_TIMING_FLIP_MASK,
> >> +				ctrl->val ? OV4689_TIMING_FLIP_BOTH : 0, &ret);
> >> +		break;
> >> +	case V4L2_CID_HFLIP:
> >> +		cci_update_bits(regmap, OV4689_REG_TIMING_FORMAT2,
> >> +				OV4689_TIMING_FLIP_MASK,
> >> +				ctrl->val ? 0 : OV4689_TIMING_FLIP_BOTH, &ret);
> >> +		break;
> >>  	default:
> >>  		dev_warn(dev, "%s Unhandled id:0x%x, val:0x%x\n",
> >>  			 __func__, ctrl->id, ctrl->val);
> >> @@ -637,7 +654,7 @@ static int ov4689_initialize_controls(struct ov4689 *ov4689)
> >>
> >>  	handler = &ov4689->ctrl_handler;
> >>  	mode = ov4689->cur_mode;
> >> -	ret = v4l2_ctrl_handler_init(handler, 10);
> >> +	ret = v4l2_ctrl_handler_init(handler, 12);
> >>  	if (ret)
> >>  		return ret;
> >>
> >> @@ -677,6 +694,9 @@ static int ov4689_initialize_controls(struct ov4689 *ov4689)
> >>  				     ARRAY_SIZE(ov4689_test_pattern_menu) - 1,
> >>  				     0, 0, ov4689_test_pattern_menu);
> >>
> >> +	v4l2_ctrl_new_std(handler, &ov4689_ctrl_ops, V4L2_CID_VFLIP, 0, 1, 1, 0);
> >> +	v4l2_ctrl_new_std(handler, &ov4689_ctrl_ops, V4L2_CID_HFLIP, 0, 1, 1, 0);
> >
> > Could you take the default value from the mounting rotation?
> 
> Could you provide an example (maybe a link to an existing driver) which
> does this right? If I understand you correctly, I should flip default
> for both flip controls for 180 degree rotation. But what should I do for
> 90, 270 and all the rest rotation values?

Looking at the patch again, it seems that the image wasn't flipped both
vertically and horizontally, but only horizontally. Was that the case?

Shouldn't the default then be no flipping?

> 
> > The default should be upside-up, but this is an existing driver and
> > changing the flipping now could affect existing users.
> 
> Do you mean default rotation value when missing device tree property?
> 
> > <URL:https://hverkuil.home.xs4all.nl/spec/userspace-api/drivers/camera-sensor.html#rotation-orientation-and-flipping>
> >
> 
> 
> 

-- 
Regards,

Sakari Ailus