| 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
| ||
|
Message-Id: <20230609145648.1960398-1-bbara93@gmail.com>
Date: Fri, 9 Jun 2023 16:56:48 +0200
From: Benjamin Bara <bbara93@...il.com>
To: dave.stevenson@...pberrypi.com
Cc: bbara93@...il.com, benjamin.bara@...data.com,
jacopo.mondi@...asonboard.com, laurent.pinchart@...asonboard.com,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
mani@...nel.org, mchehab@...nel.org
Subject: [PATCH 2/2] media: i2c: imx290: Add support for V4L2_CID_VTOTAL
Hi Dave,
thanks for the feedback!
On Fri, 9 Jun 2023 at 16:21, Dave Stevenson <dave.stevenson@...pberrypi.com> wrote:
> On Fri, 9 Jun 2023 at 14:16, Benjamin Bara <bbara93@...il.com> wrote:
> >
> > From: Benjamin Bara <benjamin.bara@...data.com>
> >
> > The new V4L2_CID_VTOTAL control represents the VMAX register.
> > Implementing it simplifies calculations in user space, as it is
> > independent of the current mode (format height), meaning its value does
> > not change with format changes.
>
> I know Laurent suggested this change[1] so that (AIUI) exposure max
> limits are easier to compute around mode changes.
>
> I'm currently seeing this as a fair amount of boilerplate to be added
> to all drivers so that two controls provide effectively the same
> information, and I'm not convinced it saves any significant effort in
> userspace. Can you (or Laurent) detail exactly what the issue is that
> the new control solves?
Sure. My main problem with the current blanking controls is that it is
not clear what should happen in case of a format switch. I guess the
expected case is that the vertical blanking should stay constant, but
that might be implemented differently.
If so, this results in a change of the total frame duration. If we
switch to "total", a format switch would result to the same (required)
frame rate, as the blanking would be reduced instead. I guess this
represents the typical "use case" better, and clarifies implementation
things. Currently, it seems a little bit odd or unnecessary complicated
to me that I have to modify a blanking time and need to know the current
format to be able to achieve a certain frame rate. But maybe Laurent has
other issues.
> Do we need to do the same for HBLANK as well, or do we live with an
> asymmetrical set of controls.
I can add that in a v2 too, IMHO it makes sense to replace both
blankings with totals. So one can set HTOTAL to min and VTOTAL to the
required frame rate (simpler calculation now) and has the guarantee that
the frame rate stays constant during format switches (if the pixel rate
is high enough of course). I will then also adapt the doc accordingly.
Hope this clarifies it.
Regards,
Benjamin
> Thanks
> Dave
>
> [1] https://lists.libcamera.org/pipermail/libcamera-devel/2023-June/038170.html
>
> > Signed-off-by: Benjamin Bara <benjamin.bara@...data.com>
> > ---
> > drivers/media/i2c/imx290.c | 47 ++++++++++++++++++++++++++++++++++------------
> > 1 file changed, 35 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > index 5ea25b7acc55..42938400efb0 100644
> > --- a/drivers/media/i2c/imx290.c
> > +++ b/drivers/media/i2c/imx290.c
> > @@ -255,6 +255,7 @@ struct imx290 {
> > struct v4l2_ctrl *link_freq;
> > struct v4l2_ctrl *hblank;
> > struct v4l2_ctrl *vblank;
> > + struct v4l2_ctrl *vtotal;
> > struct v4l2_ctrl *exposure;
> > struct {
> > struct v4l2_ctrl *hflip;
> > @@ -782,8 +783,7 @@ static void imx290_exposure_update(struct imx290 *imx290,
> > {
> > unsigned int exposure_max;
> >
> > - exposure_max = imx290->vblank->val + mode->height -
> > - IMX290_EXPOSURE_OFFSET;
> > + exposure_max = imx290->vtotal->val - IMX290_EXPOSURE_OFFSET;
> > __v4l2_ctrl_modify_range(imx290->exposure, 1, exposure_max, 1,
> > exposure_max);
> > }
> > @@ -794,7 +794,7 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
> > struct imx290, ctrls);
> > const struct v4l2_mbus_framefmt *format;
> > struct v4l2_subdev_state *state;
> > - int ret = 0, vmax;
> > + int ret = 0;
> >
> > /*
> > * Return immediately for controls that don't need to be applied to the
> > @@ -803,10 +803,22 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
> > if (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY)
> > return 0;
> >
> > - if (ctrl->id == V4L2_CID_VBLANK) {
> > - /* Changing vblank changes the allowed range for exposure. */
> > + /* Changing vtotal changes the allowed range for exposure. */
> > + if (ctrl->id == V4L2_CID_VTOTAL)
> > imx290_exposure_update(imx290, imx290->current_mode);
> > - }
> > +
> > + /*
> > + * vblank and vtotal depend on each other, therefore also update the
> > + * other one.
> > + */
> > + if (ctrl->id == V4L2_CID_VBLANK &&
> > + imx290->vtotal->val != ctrl->val + imx290->current_mode->height)
> > + __v4l2_ctrl_s_ctrl(imx290->vtotal,
> > + ctrl->val + imx290->current_mode->height);
> > + if (ctrl->id == V4L2_CID_VTOTAL &&
> > + imx290->vblank->val != ctrl->val - imx290->current_mode->height)
> > + __v4l2_ctrl_s_ctrl(imx290->vblank,
> > + ctrl->val - imx290->current_mode->height);
> >
> > /* V4L2 controls values will be applied only when power is already up */
> > if (!pm_runtime_get_if_in_use(imx290->dev))
> > @@ -821,9 +833,14 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
> > break;
> >
> > case V4L2_CID_VBLANK:
> > - ret = imx290_write(imx290, IMX290_VMAX,
> > - ctrl->val + imx290->current_mode->height,
> > - NULL);
> > + /* vblank is updated by vtotal. */
> > + break;
> > +
> > + case V4L2_CID_VTOTAL:
> > + ret = imx290_write(imx290, IMX290_VMAX, ctrl->val, NULL);
> > + if (ret)
> > + goto err;
> > +
> > /*
> > * Due to the way that exposure is programmed in this sensor in
> > * relation to VMAX, we have to reprogramme it whenever VMAX is
> > @@ -834,9 +851,8 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
> > ctrl = imx290->exposure;
> > fallthrough;
> > case V4L2_CID_EXPOSURE:
> > - vmax = imx290->vblank->val + imx290->current_mode->height;
> > ret = imx290_write(imx290, IMX290_SHS1,
> > - vmax - ctrl->val - 1, NULL);
> > + imx290->vtotal->val - ctrl->val - 1, NULL);
> > break;
> >
> > case V4L2_CID_TEST_PATTERN:
> > @@ -880,6 +896,7 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
> > break;
> > }
> >
> > +err:
> > pm_runtime_mark_last_busy(imx290->dev);
> > pm_runtime_put_autosuspend(imx290->dev);
> >
> > @@ -911,11 +928,14 @@ static void imx290_ctrl_update(struct imx290 *imx290,
> > unsigned int vblank_max = IMX290_VMAX_MAX - mode->height;
> >
> > __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
> > + __v4l2_ctrl_s_ctrl(imx290->vblank, imx290->vtotal->val - mode->height);
> >
> > __v4l2_ctrl_modify_range(imx290->hblank, hblank_min, hblank_max, 1,
> > hblank_min);
> > __v4l2_ctrl_modify_range(imx290->vblank, vblank_min, vblank_max, 1,
> > vblank_min);
> > + __v4l2_ctrl_modify_range(imx290->vtotal, mode->vmax_min,
> > + IMX290_VMAX_MAX, 1, mode->vmax_min);
> > }
> >
> > static int imx290_ctrl_init(struct imx290 *imx290)
> > @@ -947,7 +967,7 @@ static int imx290_ctrl_init(struct imx290 *imx290)
> >
> > /*
> > * Correct range will be determined through imx290_ctrl_update setting
> > - * V4L2_CID_VBLANK.
> > + * V4L2_CID_VTOTAL.
> > */
> > imx290->exposure = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
> > V4L2_CID_EXPOSURE, 1, 65535, 1,
> > @@ -983,6 +1003,9 @@ static int imx290_ctrl_init(struct imx290 *imx290)
> >
> > imx290->vblank = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
> > V4L2_CID_VBLANK, 1, 1, 1, 1);
> > + imx290->vtotal = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
> > + V4L2_CID_VTOTAL, 1, IMX290_VMAX_MAX,
> > + 1, 1);
> >
> > imx290->hflip = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
> > V4L2_CID_HFLIP, 0, 1, 1, 0);
> >
> > --
> > 2.34.1
> >
Powered by blists - more mailing lists