Re: [PATCH 05/10] media: ar0521: Add LINK_FREQ control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> 
> 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.

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

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux