On Sun, May 16, 2021 at 6:40 PM Seongyong Park
<euphoriccatface@xxxxxxxxx> wrote:
>
> 2021년 5월 17일 (월) 오전 5:49, Matt Ranostay <matt.ranostay@xxxxxxxxxxxx>님이 작성:
> >
> > On Sun, May 16, 2021 at 4:09 AM Seongyong Park
> > <euphoriccatface@xxxxxxxxx> wrote:
> > >
> > > On MLX90640, Each measurement step updates half of the pixels in the frame
> > > (every other pixel in default "chess mode", and every other row
> > > in "interleave mode"), while additional coefficient data (25th & 26th row)
> > > updates every step. The compensational coefficient data only corresponds
> > > with the pixels updated in the same step.
> > >
> > > Only way to know which "subpage" was updated on the last step is to read
> > > "status register" on address 0x8000. Without this data,
> > > compensation calculation may be able to detect which sets of pixels have
> > > been updated, but it will have to make assumptions when frame skip happens,
> > > and there is no way to do it correctly when the host simply cannot
> > > keep up with refresh rate.
> > >
> > > Signed-off-by: Seongyong Park <euphoriccatface@xxxxxxxxx>
> > > ---
> > > drivers/media/i2c/video-i2c.c | 11 +++++++----
> > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> > > index 2ccb08335..ca3a1c504 100644
> > > --- a/drivers/media/i2c/video-i2c.c
> > > +++ b/drivers/media/i2c/video-i2c.c
> > > @@ -74,7 +74,7 @@ static const struct v4l2_fmtdesc mlx90640_format = {
> > >
> > > static const struct v4l2_frmsize_discrete mlx90640_size = {
> > > .width = 32,
> > > - .height = 26, /* 24 lines of pixel data + 2 lines of processing data */
> > > + .height = 27, /* 24 lines of pixel data + 2 lines of processing data + 1 line of registers */
> > > };
> > >
> > > static const struct regmap_config amg88xx_regmap_config = {
> > > @@ -168,8 +168,11 @@ static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
> > >
> > > static int mlx90640_xfer(struct video_i2c_data *data, char *buf)
> > > {
> > > - return regmap_bulk_read(data->regmap, 0x400, buf,
> > > - data->chip->buffer_size);
> > > + int ret = regmap_bulk_read(data->regmap, 0x400, buf,
> > > + data->chip->buffer_size - 64);
> > > + if (ret) return ret;
> > > + return regmap_bulk_read(data->regmap, 0x8000, buf + 1664,
> > > + 64);
> >
> > Rather than "buf + 1664" it would be more portable and clear if you
> > use "buf + (data->chip->buffer_size - 64)"
>
> Okay, I'll send another patch later to change it.
>
> > Also isn't the 1 line of registers only 32-bytes not 64-bytes?
>
> In terms of the V4L2 frame, a row is 64-bytes because width is 32 and
> each pixel is 16-bit.
> This was the main reason to decide the appendage to be 64-bytes.
>
Ok, forgot this sensor has 12-bit data padded to 16-bits.
- Matt
> For MLX90640, the address 0x8010 is mentioned in the datasheet, and
> actual output appears that up to 0x8013 is valid
> For reference, an output from my sensor shows:
> 0x8000: 0900 a200 9f69 0000 6120 0500 2003 e003 2817 4f8e 8701 8d04
> 0000 8119 0000 0000
> 0x8010: 33be 8000 4d02 0000 ffff ffff ffff ffff ffff ffff ffff ffff
> ffff ffff ffff ffff
>
> - Seongyong
>
> >
> > - Matt
> >
> > > }
> > >
> > > static int amg88xx_setup(struct video_i2c_data *data)
> > > @@ -375,7 +378,7 @@ static const struct video_i2c_chip video_i2c_chip[] = {
> > > .format = &mlx90640_format,
> > > .frame_intervals = mlx90640_frame_intervals,
> > > .num_frame_intervals = ARRAY_SIZE(mlx90640_frame_intervals),
> > > - .buffer_size = 1664,
> > > + .buffer_size = 1728,
> > > .bpp = 16,
> > > .regmap_config = &mlx90640_regmap_config,
> > > .nvmem_config = &mlx90640_nvram_config,
> > > --
> > > 2.31.1
> > >
