Re: [PATCH 1/4] media: i2c: imx214: Explain some magic numbers

[André Apitzsch]

Am Dienstag, dem 24.10.2023 um 13:52 +0100 schrieb Kieran Bingham:
> Quoting André Apitzsch (2023-10-24 08:30:01)
> > Am Montag, dem 23.10.2023 um 23:44 +0100 schrieb Kieran Bingham:
> > > Quoting André Apitzsch (2023-10-23 22:47:50)
> > > > Code refinement, no functional changes.
> > > > 
> > > > Signed-off-by: André Apitzsch <git@xxxxxxxxxxx>
> > > > ---
> > > >  drivers/media/i2c/imx214.c | 24 +++++++++++++++++++-----
> > > >  1 file changed, 19 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/media/i2c/imx214.c
> > > > b/drivers/media/i2c/imx214.c
> > > > index 4f77ea02cc27..9218c149d4c8 100644
> > > > --- a/drivers/media/i2c/imx214.c
> > > > +++ b/drivers/media/i2c/imx214.c
> > > > @@ -19,12 +19,23 @@
> > > >  #include <media/v4l2-fwnode.h>
> > > >  #include <media/v4l2-subdev.h>
> > > >  
> > > > +#define IMX214_REG_MODE_SELECT         0x0100
> > > > +#define IMX214_MODE_STANDBY            0x00
> > > > +#define IMX214_MODE_STREAMING          0x01
> > > > +
> > > >  #define IMX214_DEFAULT_CLK_FREQ        24000000
> > > >  #define IMX214_DEFAULT_LINK_FREQ 480000000
> > > >  #define IMX214_DEFAULT_PIXEL_RATE ((IMX214_DEFAULT_LINK_FREQ *
> > > > 8LL) / 10)
> > > >  #define IMX214_FPS 30
> > > >  #define IMX214_MBUS_CODE MEDIA_BUS_FMT_SRGGB10_1X10
> > > >  
> > > > +/* Exposure control */
> > > > +#define IMX214_REG_EXPOSURE            0x0202
> > > > +#define IMX214_EXPOSURE_MIN            0
> > > > +#define IMX214_EXPOSURE_MAX            3184
> > > > +#define IMX214_EXPOSURE_STEP           1
> > > > +#define IMX214_EXPOSURE_DEFAULT                0x0c70
> > > 
> > > I like this change, and I see that 0x0c70 was directly moved here
> > > from
> > > the code below. But could we replace 0xc70 here with 3184 please
> > > so
> > > that
> > > it's /far/ clearer that the Exposure Default == Exposure Max
> > > which is
> > > otherwise hidden?
> > > 
> > Hi Kieran,
> > 
> > I can do that. But I propose to replace 3184 with 0x0c70 instead.
> > Because that matches the entries used in the reg_8 lists
> > mode_4096x2304[] and mode_1920x1080[].
> > 
> >         {0x0202, 0x0C},
> >         {0x0203, 0x70}, 
> > 
> > What do you think?
> 
> I think exposure values are easier to read as integers than hex
> values.
Okay, integer it is.

> 
> This is the 'Coarse Integration Time' register with a unit of
> 'lines'.
> 
> If you have lots of time, or wish to delve deeper - we could talk
> about splitting out those register tables to use CCI and/or more
> readable functions ;-)

I will consider it.

> 
> Do you have the datasheet for this sensor - or are you just working
> from the information within this driver?

I don't have the datasheet, yet (maybe somebody could provide it), so I
have to work with the information within this driver and downstream
implementations, like the one by nvidia [1].

> 
> What device are you using to test this driver?
> 
The sensor is part of my mobile, BQ Aquaris M5 (Longcheer L9100).

Best regards,
André

[1] https://github.com/InES-HPMM/linux-l4t/blob/9150157d2b1f73aefe01e9a07e3b062a45d57247/drivers/media/i2c/imx214_mode_tbls.h

> --
> Kieran
> 
> > Regards,
> > André