From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Benjamin Bara <bbara93@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>,
Alexander Stein <alexander.stein@ew.tq-group.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Benjamin Bara <benjamin.bara@skidata.com>
Subject: Re: [PATCH v3 4/7] media: i2c: imx290: Introduce initial "off" mode & link freq
Date: Tue, 3 Sep 2024 16:00:53 +0300 [thread overview]
Message-ID: <20240903130053.GA25878@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAJpcXm6r_LAD+NC7u5aNvkEHq3Vb3osCea8MAn8nQ45dCtoxSg@mail.gmail.com>
On Mon, Sep 02, 2024 at 10:55:04PM +0200, Benjamin Bara wrote:
> On Mon, 2 Sept 2024 at 21:58, Laurent Pinchart wrote:
> > On Mon, Sep 02, 2024 at 05:57:29PM +0200, bbara93@gmail.com wrote:
> > > From: Benjamin Bara <benjamin.bara@skidata.com>
> > >
> > > To be compliant to the V4L2 API, the driver currently "randomly" decides
> > > on one of the two supported modes which also implies a link frequency.
> > >
> > > Add a new mode and frequency which symbolize that the sensor is not in
> > > use. This can be used as a default value during probe() and enables us
> > > to avoid communication with the sensor.
> >
> > I really doin't like this change. I would like to instead move away from
> > modes and make the driver freely configurable.
>
> Which controls do you want to have freely configurable? At least on the
> imx290 the exposure limits depend on the blanking, and the blanking
> limits depend on the format. As the format is defined by the mode on
> imx290, I think this will be quite hard with the current controls.
I want to make the format freely configurable.
> > Furthermore, the concept of an initial unconfigured state isn't valid
> > in V4L2. The driver must fully initialize the whole device state at
> > probe time.
>
> I understand that and it makes sense to me. But given the dependencies
> from above and the fact that the format is currently part of this
> "state", it makes the "freely configurable" intention even harder :-(
Why can't we simply initialize the controls with limits that correspond
to the default format ? I don't understand what issue this is trying to
solve.
> > > Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
> > > ---
> > > Changes since v2:
> > > - new
> > > ---
> > > drivers/media/i2c/imx290.c | 29 +++++++++++++++++++++++------
> > > 1 file changed, 23 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > > index 6812e7cb9e23..ece4d66001f5 100644
> > > --- a/drivers/media/i2c/imx290.c
> > > +++ b/drivers/media/i2c/imx290.c
> > > @@ -425,14 +425,17 @@ static const struct imx290_csi_cfg imx290_csi_297mhz = {
> > > /* supported link frequencies */
> > > #define FREQ_INDEX_1080P 0
> > > #define FREQ_INDEX_720P 1
> > > +#define FREQ_INDEX_OFF 2
> > > static const s64 imx290_link_freq_2lanes[] = {
> > > [FREQ_INDEX_1080P] = 445500000,
> > > [FREQ_INDEX_720P] = 297000000,
> > > + [FREQ_INDEX_OFF] = 0,
> > > };
> > >
> > > static const s64 imx290_link_freq_4lanes[] = {
> > > [FREQ_INDEX_1080P] = 222750000,
> > > [FREQ_INDEX_720P] = 148500000,
> > > + [FREQ_INDEX_OFF] = 0,
> > > };
> > >
> > > /*
> > > @@ -552,6 +555,10 @@ static const struct imx290_mode imx290_modes_4lanes[] = {
> > > },
> > > };
> > >
> > > +static const struct imx290_mode imx290_mode_off = {
> > > + .link_freq_index = FREQ_INDEX_OFF,
> > > +};
> > > +
> > > static inline const struct imx290_mode *imx290_modes_ptr(const struct imx290 *imx290)
> > > {
> > > if (imx290->nlanes == 2)
> > > @@ -876,10 +883,19 @@ static unsigned int imx290_get_blank_min(const struct imx290 *imx290, bool v)
> > > static void imx290_ctrl_update(struct imx290 *imx290,
> > > const struct imx290_mode *mode)
> > > {
> > > - unsigned int hblank_min = mode->hmax_min - mode->width;
> > > - unsigned int hblank_max = IMX290_HMAX_MAX - mode->width;
> > > - unsigned int vblank_min = mode->vmax_min - mode->height;
> > > - unsigned int vblank_max = IMX290_VMAX_MAX - mode->height;
> > > + unsigned int hblank_min, hblank_max, vblank_min, vblank_max;
> > > +
> > > + if (mode == &imx290_mode_off) {
> > > + hblank_min = imx290_get_blank_min(imx290, false);
> > > + hblank_max = HBLANK_MAX;
> > > + vblank_min = imx290_get_blank_min(imx290, true);
> > > + vblank_max = VBLANK_MAX;
> > > + } else {
> > > + hblank_min = mode->hmax_min - mode->width;
> > > + hblank_max = IMX290_HMAX_MAX - mode->width;
> > > + vblank_min = mode->vmax_min - mode->height;
> > > + vblank_max = IMX290_VMAX_MAX - mode->height;
> > > + }
> > >
> > > __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
> > >
> > > @@ -932,7 +948,8 @@ static int imx290_ctrl_init(struct imx290 *imx290)
> > > imx290->link_freq =
> > > v4l2_ctrl_new_int_menu(&imx290->ctrls, &imx290_ctrl_ops,
> > > V4L2_CID_LINK_FREQ,
> > > - imx290_link_freqs_num(imx290) - 1, 0,
> > > + imx290_link_freqs_num(imx290) - 1,
> > > + FREQ_INDEX_OFF,
> > > imx290_link_freqs_ptr(imx290));
> > > if (imx290->link_freq)
> > > imx290->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > > @@ -1278,7 +1295,7 @@ static int imx290_subdev_init(struct imx290 *imx290)
> > > struct v4l2_subdev_state *state;
> > > int ret;
> > >
> > > - imx290->current_mode = &imx290_modes_ptr(imx290)[0];
> > > + imx290->current_mode = &imx290_mode_off;
> > >
> > > v4l2_i2c_subdev_init(&imx290->sd, client, &imx290_subdev_ops);
> > > imx290->sd.internal_ops = &imx290_internal_ops;
> > >
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-09-03 13:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 15:57 [PATCH v3 0/7] media: i2c: imx290: check for availability in probe() bbara93
2024-09-02 15:57 ` [PATCH v3 1/7] media: i2c: imx290: Define standby mode values bbara93
2024-09-02 19:55 ` Laurent Pinchart
2024-09-02 20:05 ` Benjamin Bara
2024-09-02 15:57 ` [PATCH v3 2/7] media: i2c: imx290: Define absolute control ranges bbara93
2024-09-02 18:00 ` Dave Stevenson
2024-09-02 19:43 ` Benjamin Bara
2024-09-02 20:06 ` Laurent Pinchart
2024-09-02 21:17 ` Benjamin Bara
2024-09-03 7:38 ` Benjamin Bara
2024-09-02 15:57 ` [PATCH v3 3/7] media: i2c: imx290: Remove CHIP_ID reg definition bbara93
2024-09-02 15:57 ` [PATCH v3 4/7] media: i2c: imx290: Introduce initial "off" mode & link freq bbara93
2024-09-02 19:58 ` Laurent Pinchart
2024-09-02 20:55 ` Benjamin Bara
2024-09-03 13:00 ` Laurent Pinchart [this message]
2024-09-03 14:13 ` Dave Stevenson
2024-09-02 15:57 ` [PATCH v3 5/7] media: i2c: imx290: Avoid communication during probe() bbara93
2024-09-02 20:00 ` Laurent Pinchart
2024-09-02 21:03 ` Benjamin Bara
2024-09-02 15:57 ` [PATCH v3 6/7] media: i2c: imx290: Check for availability in probe() bbara93
2024-09-02 18:22 ` Dave Stevenson
2024-09-02 20:01 ` Laurent Pinchart
2024-09-02 20:03 ` Benjamin Bara
2024-09-02 15:57 ` [PATCH v3 7/7] media: i2c: imx290: Implement a "privacy mode" for probe() bbara93
2024-09-02 18:10 ` Dave Stevenson
2024-09-02 19:49 ` Benjamin Bara
2024-09-02 20:04 ` Laurent Pinchart
2024-09-02 21:04 ` Benjamin Bara
2024-09-02 17:55 ` [PATCH v3 0/7] media: i2c: imx290: check for availability in probe() Dave Stevenson
2024-09-02 18:18 ` Benjamin Bara
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=20240903130053.GA25878@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=bbara93@gmail.com \
--cc=benjamin.bara@skidata.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mchehab@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.