On Fri, 7 Oct 2022 at 15:01, Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> 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@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.
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.
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.
Dave
> > > ctrls->test_pattern = v4l2_ctrl_new_std_menu_items(hdl, ops,
> > > V4L2_CID_TEST_PATTERN,
> > > ARRAY_SIZE(test_pattern_menu) - 1,
>
> --
> Regards,
>
> Laurent Pinchart
