[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM6PR04MB634199B1F0F3C09B8F3FFA16E7AB9@AM6PR04MB6341.eurprd04.prod.outlook.com>
Date: Mon, 13 Jun 2022 05:25:31 +0000
From: Ming Qian <ming.qian@....com>
To: "Mirela Rabulea (OSS)" <mirela.rabulea@....nxp.com>,
"mchehab@...nel.org" <mchehab@...nel.org>,
"hverkuil-cisco@...all.nl" <hverkuil-cisco@...all.nl>
CC: "shawnguo@...nel.org" <shawnguo@...nel.org>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"festevam@...il.com" <festevam@...il.com>,
dl-linux-imx <linux-imx@....com>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v2] media: imx-jpeg: Align upwards buffer size
> From: Mirela Rabulea (OSS) <mirela.rabulea@....nxp.com>
> Sent: 2022年6月13日 6:56
> To: Ming Qian <ming.qian@....com>; mchehab@...nel.org;
> hverkuil-cisco@...all.nl
> Cc: shawnguo@...nel.org; s.hauer@...gutronix.de; kernel@...gutronix.de;
> festevam@...il.com; dl-linux-imx <linux-imx@....com>;
> linux-media@...r.kernel.org; linux-kernel@...r.kernel.org;
> devicetree@...r.kernel.org; linux-arm-kernel@...ts.infradead.org
> Subject: Re: [PATCH v2] media: imx-jpeg: Align upwards buffer size
>
> Hi Ming,
>
> On 30.05.2022 10:49, Ming Qian wrote:
> > The hardware can support any image size WxH, with arbitrary W (image
> > width) and H (image height) dimensions.
> >
> > Align upwards buffer size for both encoder and decoder.
> > and leave the picture resolution unchanged.
> >
> > For decoder, the risk of memory out of bounds can be avoided.
> > For both encoder and decoder, the driver will lift the limitation of
> > resolution alignment.
> >
> > For example, the decoder can support jpeg whose resolution is 227x149
>
> I doubt 227x149 is working. I have tried 127x127, with your patch applied,
> both on encoder and decoder, the image does not look ok. The
> 126x127 seems to work. Having an odd resolution seems strange, I see not
> even gstreamer supports it (tried videotestsrc & filesink with BGR,
> 127x128 produces a 128x128 size).
>
> We need to gain more clarity on this one.
> And when we do, if we really can support any arbitrary resolution, from both
> the jpeg core and wrapper point of view, we have stuff to clean up.
> The assumption that I started with was, as stated in the comments:
> * The alignment requirements for the resolution depend on the format,
> * multiple of 16 resolutions should work for all formats.
> * Special workarounds are made in the driver to support NV12 1080p.
> With h_align/v_align defined in mxc_formats[].
>
> Regards,
> Mirela
Hi Mirela,
I think you are confusing picture size and buffer size.
In this patch, driver will enlarge the buffer size to align 16x16. But let the picture size unchanged.
And if you display the decoded 227x149 picture directly on imx8q, you may meet some drm error, and the display looks abnormal,
The error message like below:
[ 36.381015] [drm] [CRTC:38:crtc-0] dpu_crtc_atomic_flush: wait for content shdld done timeout
[ 36.389630] [drm] [CRTC:38:crtc-0] dpu_crtc_atomic_flush: FrameGen requests to read empty FIFO
[ 49.469022] [drm] [CRTC:38:crtc-0] dpu_crtc_atomic_flush: wait for content shdld done timeout
But if you save the decoded picture data in to a file, then check the data, you will find it's correct.
And if you treat the decoded buffer as a picture with resolution 240x160, and with some padding content, it's also correct.
So in my first patch, I let the driver report the aligned resolution in g_fmt,
and implement a g_selection to report the actual resolution through the crop info.
but this solution will fail your labgrid jpeg test.
So I choose the current solution that keep the actual picture size, and align upwards the buffer size.
The display of 227x149 is abnormal, I think it's not the jpeg codec's limitation, but the imx8q drm's limitation.
And in my opinion, I prefer the first solution that implementing a g_selection to report the actual picture size.
If you can accept that changing your labgrid jpeg testcase, I can prepare a v3 patch to switch to this solution.
Ming
>
> > the encoder can support nv12 1080P, won't change it to 1920x1072.
> >
> > Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG
> > Encoder/Decoder")
> > Signed-off-by: Ming Qian <ming.qian@....com>
> > ---
> > v2
> > - add Fixes tag
> > .../media/platform/nxp/imx-jpeg/mxc-jpeg.c | 88 ++++++++-----------
> > 1 file changed, 37 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
> > b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
> > index c0fd030d0f19..9a1c8df522ed 100644
> > --- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
> > +++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
> > @@ -894,8 +894,8 @@ static void mxc_jpeg_config_enc_desc(struct
> vb2_buffer *out_buf,
> > jpeg->slot_data[slot].cfg_stream_size =
> > mxc_jpeg_setup_cfg_stream(cfg_stream_vaddr,
> > q_data->fmt->fourcc,
> > - q_data->w_adjusted,
> > - q_data->h_adjusted);
> > + q_data->w,
> > + q_data->h);
> >
> > /* chain the config descriptor with the encoding descriptor */
> > cfg_desc->next_descpt_ptr = desc_handle | MXC_NXT_DESCPT_EN; @@
> > -977,7 +977,7 @@ static bool mxc_jpeg_source_change(struct mxc_jpeg_ctx
> *ctx,
> > &q_data_cap->h_adjusted,
> > q_data_cap->h_adjusted, /* adjust up */
> > MXC_JPEG_MAX_HEIGHT,
> > - q_data_cap->fmt->v_align,
> > + 0,
> > 0);
> >
> > /* setup bytesperline/sizeimage for capture queue */ @@ -1161,18
> > +1161,30 @@ static int mxc_jpeg_queue_setup(struct vb2_queue *q,
> > {
> > struct mxc_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> > struct mxc_jpeg_q_data *q_data = NULL;
> > + struct mxc_jpeg_q_data tmp_q;
> > int i;
> >
> > q_data = mxc_jpeg_get_q_data(ctx, q->type);
> > if (!q_data)
> > return -EINVAL;
> >
> > + tmp_q.fmt = q_data->fmt;
> > + tmp_q.w = q_data->w_adjusted;
> > + tmp_q.h = q_data->h_adjusted;
> > + for (i = 0; i < MXC_JPEG_MAX_PLANES; i++) {
> > + tmp_q.bytesperline[i] = q_data->bytesperline[i];
> > + tmp_q.sizeimage[i] = q_data->sizeimage[i];
> > + }
> > + mxc_jpeg_sizeimage(&tmp_q);
> > + for (i = 0; i < MXC_JPEG_MAX_PLANES; i++)
> > + tmp_q.sizeimage[i] = max(tmp_q.sizeimage[i], q_data->sizeimage[i]);
> > +
> > /* Handle CREATE_BUFS situation - *nplanes != 0 */
> > if (*nplanes) {
> > if (*nplanes != q_data->fmt->colplanes)
> > return -EINVAL;
> > for (i = 0; i < *nplanes; i++) {
> > - if (sizes[i] < q_data->sizeimage[i])
> > + if (sizes[i] < tmp_q.sizeimage[i])
> > return -EINVAL;
> > }
> > return 0;
> > @@ -1181,7 +1193,7 @@ static int mxc_jpeg_queue_setup(struct
> vb2_queue *q,
> > /* Handle REQBUFS situation */
> > *nplanes = q_data->fmt->colplanes;
> > for (i = 0; i < *nplanes; i++)
> > - sizes[i] = q_data->sizeimage[i];
> > + sizes[i] = tmp_q.sizeimage[i];
> >
> > return 0;
> > }
> > @@ -1381,11 +1393,6 @@ static int mxc_jpeg_parse(struct mxc_jpeg_ctx
> *ctx, struct vb2_buffer *vb)
> > }
> > q_data_out->w = header.frame.width;
> > q_data_out->h = header.frame.height;
> > - if (header.frame.width % 8 != 0 || header.frame.height % 8 != 0) {
> > - dev_err(dev, "JPEG width or height not multiple of 8: %dx%d\n",
> > - header.frame.width, header.frame.height);
> > - return -EINVAL;
> > - }
> > if (header.frame.width > MXC_JPEG_MAX_WIDTH ||
> > header.frame.height > MXC_JPEG_MAX_HEIGHT) {
> > dev_err(dev, "JPEG width or height should be <= 8192: %dx%d\n",
> @@
> > -1748,22 +1755,17 @@ static int mxc_jpeg_try_fmt(struct v4l2_format *f,
> const struct mxc_jpeg_fmt *fm
> > pix_mp->num_planes = fmt->colplanes;
> > pix_mp->pixelformat = fmt->fourcc;
> >
> > - /*
> > - * use MXC_JPEG_H_ALIGN instead of fmt->v_align, for vertical
> > - * alignment, to loosen up the alignment to multiple of 8,
> > - * otherwise NV12-1080p fails as 1080 is not a multiple of 16
> > - */
> > + pix_mp->width = w;
> > + pix_mp->height = h;
> > v4l_bound_align_image(&w,
> > - MXC_JPEG_MIN_WIDTH,
> > - w, /* adjust downwards*/
> > + w, /* adjust upwards*/
> > + MXC_JPEG_MAX_WIDTH,
> > fmt->h_align,
> > &h,
> > - MXC_JPEG_MIN_HEIGHT,
> > - h, /* adjust downwards*/
> > - MXC_JPEG_H_ALIGN,
> > + h, /* adjust upwards*/
> > + MXC_JPEG_MAX_HEIGHT,
> > + 0,
> > 0);
> > - pix_mp->width = w; /* negotiate the width */
> > - pix_mp->height = h; /* negotiate the height */
> >
> > /* get user input into the tmp_q */
> > tmp_q.w = w;
> > @@ -1889,35 +1891,19 @@ static int mxc_jpeg_s_fmt(struct mxc_jpeg_ctx
> > *ctx,
> >
> > q_data->w_adjusted = q_data->w;
> > q_data->h_adjusted = q_data->h;
> > - if (jpeg->mode == MXC_JPEG_DECODE) {
> > - /*
> > - * align up the resolution for CAST IP,
> > - * but leave the buffer resolution unchanged
> > - */
> > - v4l_bound_align_image(&q_data->w_adjusted,
> > - q_data->w_adjusted, /* adjust upwards */
> > - MXC_JPEG_MAX_WIDTH,
> > - q_data->fmt->h_align,
> > - &q_data->h_adjusted,
> > - q_data->h_adjusted, /* adjust upwards */
> > - MXC_JPEG_MAX_HEIGHT,
> > - q_data->fmt->v_align,
> > - 0);
> > - } else {
> > - /*
> > - * align down the resolution for CAST IP,
> > - * but leave the buffer resolution unchanged
> > - */
> > - v4l_bound_align_image(&q_data->w_adjusted,
> > - MXC_JPEG_MIN_WIDTH,
> > - q_data->w_adjusted, /* adjust downwards*/
> > - q_data->fmt->h_align,
> > - &q_data->h_adjusted,
> > - MXC_JPEG_MIN_HEIGHT,
> > - q_data->h_adjusted, /* adjust downwards*/
> > - q_data->fmt->v_align,
> > - 0);
> > - }
> > + /*
> > + * align up the resolution for CAST IP,
> > + * but leave the buffer resolution unchanged
> > + */
> > + v4l_bound_align_image(&q_data->w_adjusted,
> > + q_data->w_adjusted, /* adjust upwards */
> > + MXC_JPEG_MAX_WIDTH,
> > + q_data->fmt->h_align,
> > + &q_data->h_adjusted,
> > + q_data->h_adjusted, /* adjust upwards */
> > + MXC_JPEG_MAX_HEIGHT,
> > + q_data->fmt->v_align,
> > + 0);
> >
> > for (i = 0; i < pix_mp->num_planes; i++) {
> > q_data->bytesperline[i] = pix_mp->plane_fmt[i].bytesperline;
Powered by blists - more mailing lists