Re: [PATCH 4/4] media: i2c: imx214: Add sensor's pixel matrix size

[Dave Stevenson]

Hi Jacopo

On Fri, 27 Oct 2023 at 09:57, Jacopo Mondi
<jacopo.mondi@xxxxxxxxxxxxxxxx> wrote:
>
> Hi Andre'
>
> On Wed, Oct 25, 2023 at 11:26:00PM +0200, André Apitzsch wrote:
> > Hi Jacopo,
> >
> > Am Dienstag, dem 24.10.2023 um 09:52 +0200 schrieb Jacopo Mondi:
> > > Hi Andre'
> > >
> > > On Mon, Oct 23, 2023 at 11:47:53PM +0200, André Apitzsch wrote:
> > > > Set effictive and active sensor pixel sizes as shown in product
> > >
> > > s/effictive/effective
> > >
> > > > brief[1].
> > > >
> > > > [1]:
> > > > https://www.mouser.com/datasheet/2/897/ProductBrief_IMX214_20150428-1289331.pdf
> > > >
> > > > Signed-off-by: André Apitzsch <git@xxxxxxxxxxx>
> > > > ---
> > > >  drivers/media/i2c/imx214.c | 39 ++++++++++++++++++++++++++++++++--
> > > > -----
> > > >  1 file changed, 32 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/media/i2c/imx214.c
> > > > b/drivers/media/i2c/imx214.c
> > > > index bef8dc36e2d0..a2d441cd8dcd 100644
> > > > --- a/drivers/media/i2c/imx214.c
> > > > +++ b/drivers/media/i2c/imx214.c
> > > > @@ -36,6 +36,14 @@
> > > >  #define IMX214_EXPOSURE_STEP             1
> > > >  #define IMX214_EXPOSURE_DEFAULT          0x0c70
> > > >
> > > > +/* IMX214 native and active pixel array size */
> > > > +#define IMX214_NATIVE_WIDTH              4224U
> > > > +#define IMX214_NATIVE_HEIGHT             3136U
> > > > +#define IMX214_PIXEL_ARRAY_LEFT          8U
> > > > +#define IMX214_PIXEL_ARRAY_TOP           8U
> > > > +#define IMX214_PIXEL_ARRAY_WIDTH 4208U
> > > > +#define IMX214_PIXEL_ARRAY_HEIGHT        3120U
> > > > +
> > >
> > > I do get slightly different numbers from the datasheet version I have
> > >
> > > The sensor is said to have 4224x3208 total pixels of which 4208x3120
> > > are active ones.
> > >
> > > The pixel array diagram shows 64 "OPB" (optically black ?) lines,
> > > followed by 8 dummy lines, followed by 3120 valid lines. There are 8
> > > dummy columns at each side of the 4208 valid ones.
> > >
> > > Now, NATIVE which represents the full pixel array size seems to be
> > > 4224x3208 (other parts of the datasheet only report 3200 lines
> > > though)
> > >
> > > BOUNDS represents the readabale array area, which I presume
> > > corresponds to what is named as 'effective area' by the datasheet. It
> > > excludes the OPB lines at the top of the image and seems to be
> > > represented by (0, 64, 4224, 3160).
> > >
> > > CROP_DEFAULT represents the default crop rectangle which covers the
> > > active pixel area, so it excludes 8 more lines of dummy pixels and 8
> > > dummy columns, which gives a rectangle (8, 72, 4208, 3120)
> > >
> > > Also note that the driver always reports a TGT_CROP rectangle with
> > > top/left points set to 0. If my understanding is correct, V4L2
> > > selection targets are defined from the most external target
> > > (TGT_NATIVE in this case), and the driver should be corrected to
> > > initialize the crop rectangle with a top-left corner at (8, 72).
> > >
> > > Does this make sense ?
> >
> > As far as I understood, only the effective and active sizes of three
> > sizes provided in the datasheet (total, effective and active) matter.
> > By comparing the values used in imx219.c (and imx415.c) with the ones
> > in the corresponding datasheets [1,2] I assume, that "effective"
> > matches "NATIVE_SIZE", "active" matches "CROP_DEFAULT" and "total" is
> > ignored.
>
> imx219 driver indeed does not consider the OPB areas in the definition
> of the rectangles...
>
> Also looking at the X/Y_ADDR_START value assigned in the register tables
> for full resolution mode (3280x2462) they have value of 0, indeed
> meaning the active area is the only readable one.
>
> Then yes, you're right, for imx219
> NATIVE = effective
> CROP_DEFAULT = BOUND = active
>
> > The commit message of 1ed36ecd1459b653cced8929bfb37dba94b64c5d ("media:
> > i2c: imx219: Selection compliance fixes") seems to support me here:
>
> >
> > > The top/left crop coordinates of the TGT_CROP rectangle were set to
> > > (0, 0) instead of (8, 8) which is the offset from the larger physical
> > > pixel array rectangle.
> >
> > This (8, 8) is half the difference between number of effective and
> > active pixels of imx219[1].
> >
> > Together with the 8 dummy lines and 8 dummy columns you mentioned, I
> > still think my values are right. But I've just started working with
> > V4L2, so I might be wrong.
>
> To actually verify if the 'effective area' is readable or not, we
> should know what register controls the X/Y_ADDR_START value, and
> that's an information I don't have in my version of the datasheet.

I happen to have an IMX214 datasheet.
X_ADDR_START is 0x0344/5 (set in multiples of 2)
Y_ADDR_START is 0x0346/7 (set in multiples of 4)
X_ADDR_END is 0x0348/9 (set in multiples of 2)
Y_ADDR_END is 0x034a/b (set in multiples of 4)
X_OUTPUT_SIZE 0x034c/d
Y_OUTPUT_SIZE 0x034e/f

X direction are 13bit values, Y direction are 12 bit.
[12:8] or [11:8] in the low bits of the first register, [7:0] in the
second register.

  Dave

> It's however plausible that it behaves the same as imx219, as the
> driver's register sequences seems to program the crop sizes in
> register 0x034c and 0x034e and there's not programmed top-left corner
> there.
>
> Ok then, let's be consistent and do the same as imx219 as you're doing
> here.
>
> Reviewed-by: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx>
>
> >
> > Could you share the imx214 datasheet with me?
> >
> > Best regards,
> > André
> >
> > [1] https://www.arducam.com/downloads/modules/RaspberryPi_camera/IMX219DS.PDF
> > [2] https://www.sony-semicon.com/files/62/pdf/p-12_IMX415-AAQR_AAMR_Flyer.pdf
> > >
> > > Thanks
> > >   j
> > >
> > >
> > > >  static const char * const imx214_supply_name[] = {
> > > >   "vdda",
> > > >   "vddd",
> > > > @@ -634,14 +642,31 @@ static int imx214_get_selection(struct
> > > > v4l2_subdev *sd,
> > > >  {
> > > >   struct imx214 *imx214 = to_imx214(sd);
> > > >
> > > > - if (sel->target != V4L2_SEL_TGT_CROP)
> > > > -         return -EINVAL;
> > > > + switch (sel->target) {
> > > > + case V4L2_SEL_TGT_CROP:
> > > > +         mutex_lock(&imx214->mutex);
> > > > +         sel->r = *__imx214_get_pad_crop(imx214, sd_state,
> > > > sel->pad,
> > > > +                                         sel->which);
> > > > +         mutex_unlock(&imx214->mutex);
> > > > +         return 0;
> > > >
> > > > - mutex_lock(&imx214->mutex);
> > > > - sel->r = *__imx214_get_pad_crop(imx214, sd_state, sel-
> > > > >pad,
> > > > -                                 sel->which);
> > > > - mutex_unlock(&imx214->mutex);
> > > > - return 0;
> > > > + case V4L2_SEL_TGT_NATIVE_SIZE:
> > > > +         sel->r.top = 0;
> > > > +         sel->r.left = 0;
> > > > +         sel->r.width = IMX214_NATIVE_WIDTH;
> > > > +         sel->r.height = IMX214_NATIVE_HEIGHT;
> > > > +         return 0;
> > > > +
> > > > + case V4L2_SEL_TGT_CROP_DEFAULT:
> > > > + case V4L2_SEL_TGT_CROP_BOUNDS:
> > > > +         sel->r.top = IMX214_PIXEL_ARRAY_TOP;
> > > > +         sel->r.left = IMX214_PIXEL_ARRAY_LEFT;
> > > > +         sel->r.width = IMX214_PIXEL_ARRAY_WIDTH;
> > > > +         sel->r.height = IMX214_PIXEL_ARRAY_HEIGHT;
> > > > +         return 0;
> > > > + }
> > > > +
> > > > + return -EINVAL;
> > > >  }
> > > >
> > > >  static int imx214_entity_init_cfg(struct v4l2_subdev *subdev,
> > > >
> > > > --
> > > > 2.42.0
> > > >
> >