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

[Mikhail Rudenko <mike.rudenko@gmail.com>]

On 2024-02-24 at 20:04 GMT, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:

> 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@linux.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@gmail.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?
>

Do you mean setting FORMAT1 and FORMAT2 to 0x0 and HFLIP and VFLIP
controls to 0 by default, and doing

   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 ? OV4689_TIMING_FLIP_BOTH : 0, &ret);  // do not invert!
		break;

in ov4689_set_ctrl? The issue is that we get a mirrored image in this
case.

The publicly available documentation doesn't clarify this, but it looks
like the horizontal flipping bits in FORMAT2 are somehow inverted. All
the other drivers for this sensor I've found default to FORMAT2 = 0x6
(none implement flipping controls, though).

So I see two options here:
(1) default to HFLIP = 0, FORMAT2 = 0x6 (as done is this patch)
(2) default to HFLIP = 1, FORMAT2 = 0x0

I like (1) better, because it results in non-mirrored image by
default. What is your opinion?

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


--
Best regards,
Mikhail Rudenko