From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Paul Elder <paul.elder@ideasonboard.com>,
linux-media@vger.kernel.org, nicolas@ndufresne.ca
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] media: imx335: Set vblank immediately
Date: Sat, 15 Feb 2025 10:20:38 +0000 [thread overview]
Message-ID: <173961483828.3850773.86050600448052546@ping.linuxembedded.co.uk> (raw)
In-Reply-To: <aae670db21a1de622cc89ac637c407bf6452c44f.camel@ndufresne.ca>
Quoting nicolas@ndufresne.ca (2025-02-14 14:44:05)
> Hi,
>
> Le vendredi 14 février 2025 à 22:37 +0900, Paul Elder a écrit :
> > When the vblank v4l2 control is set, it does not get written to the
> > hardware immediately. It only gets updated when exposure is set.
> > Change
> > the behavior such that the vblank is written immediately when the
> > control is set.
>
> Not my field of competence, but won't this cause a flicker ?
No it shouldn't. The controls will only take effect on the next frame
boundary, but what was missing here before was that the VBLANK was not
being changed at all unless userspace also sets the Exposure control
directly.
That means that setting the exposure, and then setting the framerate
would not update the framerate (adjusted through the blanking), meaning
the framerate could not be updated at runtime. (Or it could be set but
would not take effect).
Note that in the event that VBLANK is updated, the exposure and blanking
is fully recalculated and reprogrammed to the hardware through
imx335_update_exp_gain(), which is required because the exposure is
proportional against the total frame duration. Perhaps that's specific
area you were concerned about potential for flicker?
Perhaps the commit message should make it clear that currently setting
the vblank does not take effect at all *unless* the exposure is also
*changed*. And Setting the vblank without changing the exposure is a
valid use case to change the frame rate.
> Nicolas
>
> >
> > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > ---
> > drivers/media/i2c/imx335.c | 19 +++++++++++++------
> > 1 file changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/media/i2c/imx335.c b/drivers/media/i2c/imx335.c
> > index fcfd1d851bd4..e73a23bbbc89 100644
> > --- a/drivers/media/i2c/imx335.c
> > +++ b/drivers/media/i2c/imx335.c
> > @@ -559,12 +559,12 @@ static int imx335_set_ctrl(struct v4l2_ctrl
> > *ctrl)
> > imx335->vblank,
> > imx335->vblank + imx335->cur_mode->height);
> >
> > - return __v4l2_ctrl_modify_range(imx335->exp_ctrl,
> > - IMX335_EXPOSURE_MIN,
> > - imx335->vblank +
> > - imx335->cur_mode-
> > >height -
> > -
> > IMX335_EXPOSURE_OFFSET,
> > - 1,
> > IMX335_EXPOSURE_DEFAULT);
> > + __v4l2_ctrl_modify_range(imx335->exp_ctrl,
> > + IMX335_EXPOSURE_MIN,
> > + imx335->vblank +
> > + imx335->cur_mode->height -
> > + IMX335_EXPOSURE_OFFSET,
> > + 1,
> > IMX335_EXPOSURE_DEFAULT);
> > }
> >
> > /*
> > @@ -575,6 +575,13 @@ static int imx335_set_ctrl(struct v4l2_ctrl
> > *ctrl)
> > return 0;
> >
> > switch (ctrl->id) {
> > + case V4L2_CID_VBLANK:
> > + exposure = imx335->exp_ctrl->val;
> > + analog_gain = imx335->again_ctrl->val;
> > +
> > + ret = imx335_update_exp_gain(imx335, exposure,
> > analog_gain);
> > +
This is what I would expect here,
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> > + break;
> > case V4L2_CID_EXPOSURE:
> > exposure = ctrl->val;
> > analog_gain = imx335->again_ctrl->val;
>
next prev parent reply other threads:[~2025-02-15 10:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-14 13:37 [PATCH] media: imx335: Set vblank immediately Paul Elder
2025-02-14 14:44 ` nicolas
2025-02-15 10:20 ` Kieran Bingham [this message]
2025-02-16 10:01 ` Sakari Ailus
2025-02-26 8:49 ` Paul Elder
2025-02-26 8:56 ` Sakari Ailus
2025-02-28 9:20 ` Paul Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=173961483828.3850773.86050600448052546@ping.linuxembedded.co.uk \
--to=kieran.bingham@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=paul.elder@ideasonboard.com \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox