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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <169815197462.630990.3330310524563366908@ping.linuxembedded.co.uk>
Date:   Tue, 24 Oct 2023 13:52:54 +0100
From:   Kieran Bingham <kieran.bingham@...asonboard.com>
To:     André Apitzsch <git@...tzsch.eu>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Ricardo Ribalda <ribalda@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH 1/4] media: i2c: imx214: Explain some magic numbers

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@...tzsch.eu>
> > > ---
> > >  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.

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 ;-)

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

What device are you using to test this driver?

--
Kieran

> Regards,
> André