linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: "Jacopo Mondi" <jacopo@jmondi.org>,
	"Krzysztof Hałasa" <khalasa@piap.pl>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Sakari Ailus" <sakari.ailus@iki.fi>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 05/10] media: ar0521: Add LINK_FREQ control
Date: Sun, 16 Oct 2022 04:53:10 +0300	[thread overview]
Message-ID: <Y0tkBvcufgwSe/AT@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAPY8ntCh4UFT5swHvwPj7xz8wPH3MJB-aJjEd9bCgXVubRyp5w@mail.gmail.com>

Hi Dave,

On Fri, Oct 07, 2022 at 03:26:55PM +0100, Dave Stevenson wrote:
> On Fri, 7 Oct 2022 at 15:01, Laurent Pinchart wrote:
> > On Thu, Oct 06, 2022 at 04:10:10PM +0100, Dave Stevenson wrote:
> > > On Wed, 5 Oct 2022 at 20:07, Jacopo Mondi wrote:
> > > >
> > > > Add support for V4L2_CID_LINK_FREQ which currently reports a single
> > > > hard-coded frequency which depends on the fixed pixel clock.
> > > >
> > > > This will change in the next patches where the pixel rate will be
> > > > computed from the desired link_frequency.
> > > >
> > > > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > >
> > > Looks valid based on the current pixel rate of 184MPix/s, 8bpp,
> > > divided by 4 lanes, and DDR.
> > >
> > > > ---
> > > >  drivers/media/i2c/ar0521.c | 9 +++++++++
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/drivers/media/i2c/ar0521.c b/drivers/media/i2c/ar0521.c
> > > > index 21649aecf442..c5410b091654 100644
> > > > --- a/drivers/media/i2c/ar0521.c
> > > > +++ b/drivers/media/i2c/ar0521.c
> > > > @@ -90,6 +90,10 @@ static const char * const ar0521_supply_names[] = {
> > > >         "vaa",          /* Analog (2.7V) supply */
> > > >  };
> > > >
> > > > +static const s64 ar0521_link_frequencies[] = {
> > > > +       184000000,
> > > > +};
> > > > +
> > > >  struct ar0521_ctrls {
> > > >         struct v4l2_ctrl_handler handler;
> > > >         struct v4l2_ctrl *ana_gain;
> > > > @@ -104,6 +108,7 @@ struct ar0521_ctrls {
> > > >         };
> > > >         struct v4l2_ctrl *pixrate;
> > > >         struct v4l2_ctrl *exposure;
> > > > +       struct v4l2_ctrl *link_freq;
> > > >         struct v4l2_ctrl *test_pattern;
> > > >  };
> > > >
> > > > @@ -655,6 +660,10 @@ static int ar0521_init_controls(struct ar0521_dev *sensor)
> > > >         ctrls->exposure = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_EXPOSURE, 0,
> > > >                                             65535, 1, 360);
> > > >
> > > > +       ctrls->link_freq = v4l2_ctrl_new_int_menu(hdl, ops, V4L2_CID_LINK_FREQ,
> > > > +                                       ARRAY_SIZE(ar0521_link_frequencies) - 1,
> > > > +                                       0, ar0521_link_frequencies);
> > > > +
> > >
> > > Admittedly there is only one entry, but did you want to make it a read
> > > only control? With no case for it in s_ctrl, you'll get errors thrown
> > > from the control handler framework.
> >
> > I'd make it writable even if there's a single entry, so that userspace
> > won't need special logic. It will also prepare for support of multiple
> > entries in the future.
> 
> Do you really see a situation where userspace will be configuring link
> frequency instead of DT / ACPI?
> A quick search seems to imply that only 1 current driver supports a
> r/w link frequency - mt9v032. That would imply that having a
> controllable link frequency would require the special logic in
> userspace.

Looking at the mainline kernel only, the N9, N950 and Librem5 all
specify multiple link frequencies, and so does the sdm845-db845c
development board.

This indeed requires specific logic in userspace, and to be honest, I
haven't really thought about how it would be implemented. Sakari has
more experience than me here, he may be able to shed some light.

> I'm always very cautious about drivers that are linking PIXEL_RATE and
> LINK_FREQ - most of the sensors are tending to have 2 (or more) PLLs,
> and there is a FIFO between the image sensor (PIXEL_RATE) and the MIPI
> block (LINK_FREQ). imx290 is certainly wrong (pixel rate does not
> change with mode, but link freq does), and I'm fairly certain that
> ov7251 is as well (pixel rate is 48MPix/s whether at 240 or 319.2MHz
> link frequency). Patches coming soon for both.

That's a good point, different link frequencies may or may not result in
different pixel rates.

> > > >         ctrls->test_pattern = v4l2_ctrl_new_std_menu_items(hdl, ops,
> > > >                                         V4L2_CID_TEST_PATTERN,
> > > >                                         ARRAY_SIZE(test_pattern_menu) - 1,

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2022-10-16  1:53 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05 19:06 [PATCH 00/10] media: ar0521: Add analog gain, rework clock tree Jacopo Mondi
2022-10-05 19:06 ` [PATCH 01/10] media: ar0521: Implement enum_frame_sizes Jacopo Mondi
2022-10-06 14:37   ` Dave Stevenson
2022-10-06 16:33   ` Laurent Pinchart
2022-10-07  4:57     ` Krzysztof Hałasa
2022-10-07  8:08       ` Laurent Pinchart
2022-10-07  7:29     ` Jacopo Mondi
2022-10-07  8:11       ` Laurent Pinchart
2022-10-07 10:32         ` Dave Stevenson
2022-10-07 12:05           ` Sakari Ailus
2022-10-07 12:12             ` Laurent Pinchart
2022-10-05 19:06 ` [PATCH 02/10] media: ar0521: Add V4L2_CID_ANALOG_GAIN Jacopo Mondi
2022-10-06 14:44   ` Dave Stevenson
2022-10-06 15:00     ` Jacopo Mondi
2022-10-06 15:05       ` Laurent Pinchart
2022-10-07  5:28         ` Krzysztof Hałasa
2022-10-07  8:20           ` Laurent Pinchart
2022-10-12 18:54             ` Sakari Ailus
2022-10-13  9:30               ` Laurent Pinchart
2022-10-07  5:20   ` Krzysztof Hałasa
2022-10-07  7:17     ` Jacopo Mondi
2022-10-07  8:30       ` Laurent Pinchart
2022-10-07 12:01         ` Krzysztof Hałasa
2022-10-07 12:07           ` Laurent Pinchart
2022-10-07 14:02             ` Krzysztof Hałasa
2022-10-17 15:10         ` Jacopo Mondi
2022-10-17 15:57           ` Sakari Ailus
2022-10-17 16:31             ` Jacopo Mondi
2022-10-17 16:37               ` Sakari Ailus
2022-10-17 16:42               ` Dave Stevenson
2022-10-07 11:56       ` Krzysztof Hałasa
2022-10-07 12:11         ` Laurent Pinchart
2022-10-07 14:00           ` Krzysztof Hałasa
2022-10-05 19:06 ` [PATCH 03/10] media: ar0521: Set maximum resolution to 2592x1944 Jacopo Mondi
2022-10-06 14:57   ` Dave Stevenson
2022-10-07 13:06     ` Laurent Pinchart
2022-10-20 11:23       ` Jacopo Mondi
2022-10-07  5:33   ` Krzysztof Hałasa
2022-10-07 12:42     ` Jacopo Mondi
2022-10-07 14:07       ` Krzysztof Hałasa
2022-10-05 19:06 ` [PATCH 04/10] media: ar0521: Rework PLL computation Jacopo Mondi
2022-10-07 13:56   ` Laurent Pinchart
2022-10-12 19:02     ` Sakari Ailus
2022-10-13  9:31       ` Laurent Pinchart
2022-10-05 19:06 ` [PATCH 05/10] media: ar0521: Add LINK_FREQ control Jacopo Mondi
2022-10-06 15:10   ` Dave Stevenson
2022-10-07 14:01     ` Laurent Pinchart
2022-10-07 14:26       ` Dave Stevenson
2022-10-16  1:53         ` Laurent Pinchart [this message]
2022-10-17 11:21           ` Dave Stevenson
2022-10-17  9:24         ` Jacopo Mondi
2022-10-17 11:00           ` Dave Stevenson
2022-10-17 12:00             ` Jacopo Mondi
2022-10-05 19:06 ` [PATCH 06/10] media: ar0521: Configure pixel rate using LINK_FREQ Jacopo Mondi
2022-10-06  5:51   ` kernel test robot
2022-10-06 15:42   ` Sakari Ailus
2022-10-07  7:25     ` Jacopo Mondi
2022-10-07  5:52   ` Krzysztof Hałasa
2022-10-05 19:06 ` [PATCH 07/10] media: ar0521: Adjust exposure and blankings limits Jacopo Mondi
2022-10-06  2:08   ` kernel test robot
2022-10-06  4:17   ` kernel test robot
2022-10-06 15:41   ` Dave Stevenson
2022-10-05 19:06 ` [PATCH 08/10] media: ar0521: Setup controls at s_stream time Jacopo Mondi
2022-10-06 15:43   ` Dave Stevenson
2022-10-07  7:23     ` Jacopo Mondi
2022-10-05 19:06 ` [PATCH 09/10] media: ar0521: Rework startup sequence Jacopo Mondi
2022-10-06 15:45   ` Dave Stevenson
2022-10-05 19:06 ` [PATCH 10/10] media: ar0521: Tab-align definitions Jacopo Mondi
2022-10-06 15:48   ` Dave Stevenson
2022-10-06 16:11   ` Laurent Pinchart
2022-10-07  5:42   ` Krzysztof Hałasa

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=Y0tkBvcufgwSe/AT@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=jacopo@jmondi.org \
    --cc=khalasa@piap.pl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sakari.ailus@iki.fi \
    /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;
as well as URLs for NNTP newsgroup(s).