mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Cc: Philippe Baetens <philippebaetens@gmail.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Jai Luthra <jai.luthra@ideasonboard.com>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] media: i2c: mira016: Add driver for Mira016
Date: Tue, 8 Sep 2026 11:09:04 +0300	[thread overview]
Message-ID: <ap_CoB5YL2rKAuCy@kekkonen.localdomain> (raw)
In-Reply-To: <ap6ALNC8Q0M-Oo51@zed>

Hi Jacopo,

On Mon, Sep 07, 2026 at 11:16:41AM +0200, Jacopo Mondi wrote:
> > > > > +static int mira016_set_ctrl(struct v4l2_ctrl *ctrl)
> > > > > +{
> > > > > +	struct mira016 *mira016 =
> > > > > +		container_of(ctrl->handler, struct mira016, ctrl_handler);
> > > > > +	struct i2c_client *client = v4l2_get_subdevdata(&mira016->sd);
> > > > > +	struct v4l2_subdev_state *state;
> > > > > +	struct v4l2_rect *crop;
> > > > > +	int ret = 0;
> > > > > +
> > > > > +	state = v4l2_subdev_get_locked_active_state(&mira016->sd);
> > > > > +	crop = v4l2_subdev_state_get_crop(state, 0);
> > > > > +
> > > > > +	if (ctrl->id == V4L2_CID_VBLANK) {
> > > > > +		s32 exposure_max = crop->height + ctrl->val
> > > > > +				 - MIRA016_FRAME_INTEGRATION_DIFF;
> > > > > +		s32 exposure_def = min(exposure_max,
> > > > > +				       mira016->exposure->val);
> > > > > +
> > > > > +		ret = __v4l2_ctrl_modify_range(mira016->exposure,
> > > > > +					       mira016->exposure->minimum,
> > > > > +					       exposure_max,
> > > > > +					       mira016->exposure->step,
> > > > > +					       exposure_def);
> > > > > +		if (ret)
> > > > > +			return ret;
> > > > > +	}
> > > > > +
> > > > > +	if (!pm_runtime_get_if_in_use(&client->dev))
> > > > > +		return 0;
> > > > > +
> > > > > +	switch (ctrl->id) {
> > > > > +	case V4L2_CID_EXPOSURE:
> > > > > +		ret = mira016_write_exposure_reg(mira016, ctrl->val);
> > > > > +		break;
> > > > > +	case V4L2_CID_VBLANK:
> > > > > +		ret = mira016_write_frame_duration_reg(mira016, state, ctrl->val);
> > > > > +		break;
> > > >
> > > > Is hblank part of the register lists?
> > > >
> > >
> > > These sensors (there will hopefully be more supported by this driver)
> > > do not have a real horizontal blanking.
> > >
> > > Their line length is expressed by a time base multipled by a line
> > > length which doesn't directly depend on the pixel width but rather on
> > > the ADC and PHY timings.
> > >
> > > You could expand the line duration by increasing the time base, but I
> > > wouldn't go there and use VBLANK only to control the frame duration.
> > >
> > > As you can see the HBLANK control is registered with  fixed value of
> > > 0.
> >
> > How does control frame rate then? If HBLANK is zero, the frame rate is
> > undefined, isn't it?
> >
> 
> Why do you think so ?
> 
> The row_timing is the product of the time base (in usec) multiplied by
> the row length expressed in time base cycles (see mira016_trow_psec()
> and how seq_time_base and row_length are calculated).
> 
> VBLANK is still controllable, and you can vary the frame rate by
> changing the vblank.
> 
> What have am I missing ?

Using only vertical blanking value to control the frame rate is fine, but
the correct HBLANK value is still needed by the user space to be able to
set the frame rate.

-- 
Regards,

Sakari Ailus

  reply	other threads:[~2026-09-08  8:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04 10:43 [PATCH v2 0/2] media: i2c: " Jacopo Mondi
2026-09-04 10:43 ` [PATCH v2 1/2] dt-bindings: media: i2c: Add Mira016 image sensor Jacopo Mondi
2026-09-04 15:13   ` Conor Dooley
2026-09-04 10:43 ` [PATCH v2 2/2] media: i2c: mira016: Add driver for Mira016 Jacopo Mondi
2026-09-06 20:28   ` Sakari Ailus
2026-09-07  7:45     ` Jacopo Mondi
2026-09-07  8:50       ` Sakari Ailus
2026-09-07  9:16         ` Jacopo Mondi
2026-09-08  8:09           ` Sakari Ailus [this message]
2026-09-08  7:17       ` Jacopo Mondi
2026-09-08  8:12         ` Sakari Ailus
2026-09-08  9:21           ` Jacopo Mondi
2026-09-08 10:10             ` Sakari Ailus
2026-09-08 10:34               ` Jacopo Mondi
2026-09-12 11:47                 ` Sakari Ailus

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=ap_CoB5YL2rKAuCy@kekkonen.localdomain \
    --to=sakari.ailus@linux.intel.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jacopo.mondi@ideasonboard.com \
    --cc=jai.luthra@ideasonboard.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=philippebaetens@gmail.com \
    --cc=robh@kernel.org \
    /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

all inboxes | Powered by JetHome®