[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+V-a8s_d3Atp9J5KM=x4z2z_iAY8+9vcSHFUTyQ3XZ9HCCS3g@mail.gmail.com>
Date: Mon, 2 Mar 2020 07:18:38 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Fabio Estevam <festevam@...il.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
linux-media <linux-media@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH] media: i2c: ov5645: Add virtual_channel module parameter
Hi Fabio,
Thank you for the review.
On Fri, Feb 28, 2020 at 5:31 PM Fabio Estevam <festevam@...il.com> wrote:
>
> Hi Lad,
>
> On Fri, Feb 28, 2020 at 1:41 PM Lad Prabhakar
> <prabhakar.csengg@...il.com> wrote:
> >
> > OV5645 can operate in virtual channel 0-3 in CSI2 interfaces, this patch
> > adds support for module parameter virtual_channel to select the required
> > channel. By default OV5645 operates in virtual channel 0.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > ---
> > drivers/media/i2c/ov5645.c | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
> > index a6c17d15d754..0a0671164623 100644
> > --- a/drivers/media/i2c/ov5645.c
> > +++ b/drivers/media/i2c/ov5645.c
> > @@ -54,6 +54,7 @@
> > #define OV5645_TIMING_TC_REG21 0x3821
> > #define OV5645_SENSOR_MIRROR BIT(1)
> > #define OV5645_MIPI_CTRL00 0x4800
> > +#define OV5645_REG_DEBUG_MODE 0x4814
> > #define OV5645_PRE_ISP_TEST_SETTING_1 0x503d
> > #define OV5645_TEST_PATTERN_MASK 0x3
> > #define OV5645_SET_TEST_PATTERN(x) ((x) & OV5645_TEST_PATTERN_MASK)
> > @@ -61,6 +62,11 @@
> > #define OV5645_SDE_SAT_U 0x5583
> > #define OV5645_SDE_SAT_V 0x5584
> >
> > +static u8 virtual_channel;
> > +module_param(virtual_channel, byte, 0644);
> > +MODULE_PARM_DESC(virtual_channel,
> > + "MIPI CSI-2 virtual channel (0..3), default 0");
>
> Should this be a device tree property instead?
I did give a thought about it, but making this as DT property would
make it more stiff.
Cheers,
--Prabhakar
Powered by blists - more mailing lists