The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Kyrie Wu (吴晗)" <Kyrie.Wu@mediatek.com>
To: "nicolas@ndufresne.ca" <nicolas@ndufresne.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"Kyrie Wu (吴晗)" <Kyrie.Wu@mediatek.com>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"robh@kernel.org" <robh@kernel.org>,
	"hverkuil-cisco@xs4all.nl" <hverkuil-cisco@xs4all.nl>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH v11 02/12] media: mediatek: jpeg: fix jpeg buffer payload setting
Date: Thu, 25 Dec 2025 05:48:38 +0000	[thread overview]
Message-ID: <c133597593c69e0fcb2cb7ea5c14fcb6013302c8.camel@mediatek.com> (raw)
In-Reply-To: <36268d4980a1cd6d976bdf5de148f1c2668a92e4.camel@ndufresne.ca>

On Tue, 2025-12-16 at 16:15 -0500, Nicolas Dufresne wrote:
> Hi.
> 
> Le mardi 02 décembre 2025 à 17:47 +0800, Kyrie Wu a écrit :
> > For multi-core jpegdec, if one of hws gets the event of resolution
> > changing, the payload size, representing the size of Y/C data,
> 
> -> "gets the resolution change event, ..."
> 
> > needed to change. But others hws are decoding at the same time and
> 
> needed -> needs,               hws -> cores ?
> 
> It this specific to decoders or any type of cores ?
> 
> > it can not be changed immediately, which results that the payload
> 
>                                                     in the playload
> 
> > size is not equal to the real buffer length of the hw's, which
> > occurred
> 
> size to not match the real buffer lenght for the ... hw ?
> 
> > resolution changing and a warnning call trace will print.
> 
> Can't parse. You can probably split that large sentence, and it needs
> to be
> rework.
> 
> > So the setting of payload size must less than the real buffer
> > length
> > to remove the warnning logs.
> > 
> > Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-
> > hardware")
> > 
> 
> Don't add blank line in tags please.
> 
> > Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
> > ---
> >  .../platform/mediatek/jpeg/mtk_jpeg_core.c    | 19 ++++++++++++++-
> > ----
> >  1 file changed, 14 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> > b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> > index 6a7e01130f1c..0cf3dc5407e4 100644
> > --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> > @@ -709,6 +709,7 @@ static int mtk_jpeg_buf_prepare(struct
> > vb2_buffer *vb)
> >  	struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> >  	struct mtk_jpeg_q_data *q_data = NULL;
> >  	struct v4l2_plane_pix_format plane_fmt = {};
> > +	unsigned long max_size;
> 
> size_t ?
> 
> >  	int i;
> >  
> >  	q_data = mtk_jpeg_get_q_data(ctx, vb->vb2_queue->type);
> > @@ -717,12 +718,20 @@ static int mtk_jpeg_buf_prepare(struct
> > vb2_buffer *vb)
> >  
> >  	for (i = 0; i < q_data->fmt->colplanes; i++) {
> >  		plane_fmt = q_data->pix_mp.plane_fmt[i];
> > +		max_size = plane_fmt.sizeimage;
> > +
> >  		if (ctx->enable_exif &&
> > -		    q_data->fmt->fourcc == V4L2_PIX_FMT_JPEG)
> > -			vb2_set_plane_payload(vb, i,
> > plane_fmt.sizeimage +
> > -					      MTK_JPEG_MAX_EXIF_SIZE);
> > -		else
> > -			vb2_set_plane_payload(vb, i, 
> > plane_fmt.sizeimage);
> > +			q_data->fmt->fourcc == V4L2_PIX_FMT_JPEG) {
> > +			max_size += MTK_JPEG_MAX_EXIF_SIZE;
> > +
> > +			vb2_set_plane_payload(vb, i,
> > +					      MIN(vb->planes[i].length,
> > +						  max_size));
> 
> This is still not quite right. sizeimage, straight from s_fmt should
> already
> account for the EXIF headers. If enable_exif is unknown at the
> moment, then you
> should just always include that space. This way, the buffer length
> will only be
> bigger if userspace asked for more at allocation time, and wil never
> be smaller
> then this.
> 
> The point of sizeimage it to allow userspace allocate externally the
> right size,
> this driver failed at that task it seems.
> 
> Stepping back a little, I don't even understand why you set the
> payload size
> like this here. Why isn't the true payload size written once, when
> the buffer is
> encoded ? Are you using bytesused to tell the HW how much space can
> be written
> too ? Just give it the full space, wich is the allocated size
> (length).
> 
> Nicolas

Dear Nicolas,

The value, max_size = plane_fmt.sizeimage, recorded the current size,
but if the resolution changed to a smaller one, the sizeimage will
bigger
than the vb->planes[i].length, in the former sw flow, the bigger value
will set to payload size and caused a warnning call trace printed.

Here are the answers of your questions:
1. The enable_exif is a
determined value, which is set in s_ctrl before 
jpeg decoder/encoder starting.

2. If enable_exif is set as true, the buffer planes length is equal to
sizeimage + MTK_JPEG_MAX_EXIF_SIZE.

3. The reason, Why isn't the true payload size written once,
is due to this setting is used to avoid the condition descripted in
commit message. And it will set the true value in irq handler.

Thanks.

Regards,
Kyrie.
> 
> 
> > +		} else {
> > +			vb2_set_plane_payload(vb, i,
> > +					      MIN(plane_fmt.sizeimage,
> > +						  vb-
> > >planes[i].length));
> > +		}
> >  	}
> >  
> >  	return 0;

  reply	other threads:[~2025-12-25  5:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  9:47 [PATCH v11 00/12] Enable jpeg enc & dec multi-hardwares for MT8196 Kyrie Wu
2025-12-02  9:47 ` [PATCH v11 01/12] media: mediatek: jpeg: fix jpeg hw count setting Kyrie Wu
2025-12-16 20:57   ` Nicolas Dufresne
2025-12-25  2:20     ` Kyrie Wu (吴晗)
2025-12-02  9:47 ` [PATCH v11 02/12] media: mediatek: jpeg: fix jpeg buffer payload setting Kyrie Wu
2025-12-16 21:15   ` Nicolas Dufresne
2025-12-25  5:48     ` Kyrie Wu (吴晗) [this message]
2025-12-02  9:47 ` [PATCH v11 03/12] media: mediatek: jpeg: fix jpeg buffer layout Kyrie Wu
2025-12-16 21:22   ` Nicolas Dufresne
2025-12-25  6:05     ` Kyrie Wu (吴晗)
2026-01-05 19:20       ` Nicolas Dufresne
2025-12-02  9:47 ` [PATCH v11 04/12] media: mediatek: jpeg: fix stop streaming flow for multi-core Kyrie Wu
2025-12-16 21:27   ` Nicolas Dufresne
2025-12-25  6:12     ` Kyrie Wu (吴晗)
2025-12-02  9:47 ` [PATCH v11 05/12] media: mediatek: jpeg: fix multi-core clk suspend and resume setting Kyrie Wu
2025-12-16 21:33   ` Nicolas Dufresne
2025-12-25  6:35     ` Kyrie Wu (吴晗)
2025-12-02  9:47 ` [PATCH v11 06/12] media: mediatek: jpeg: fix decoding buffer number setting timing issue Kyrie Wu
2025-12-16 21:37   ` Nicolas Dufresne
2025-12-25  7:04     ` Kyrie Wu (吴晗)
2025-12-02  9:47 ` [PATCH v11 07/12] media: mediatek: jpeg: fix decoding resolution change operation Kyrie Wu
2025-12-16 21:40   ` Nicolas Dufresne
2025-12-25  7:05     ` Kyrie Wu (吴晗)
2025-12-02  9:47 ` [PATCH v11 08/12] media: mediatek: jpeg: fix remove buffer operation for multi-core Kyrie Wu
2025-12-16 21:43   ` Nicolas Dufresne
2025-12-25  7:15     ` Kyrie Wu (吴晗)
2025-12-02  9:47 ` [PATCH v11 09/12] media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgdec compatible Kyrie Wu
2025-12-02  9:47 ` [PATCH v11 10/12] media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgenc compatible Kyrie Wu
2025-12-02  9:47 ` [PATCH v11 11/12] media: mediatek: jpeg: add jpeg compatible Kyrie Wu
2025-12-16 21:49   ` Nicolas Dufresne
2025-12-02  9:48 ` [PATCH v11 12/12] media: mediatek: jpeg: add jpeg smmu sid setting Kyrie Wu
2025-12-16 21:48   ` Nicolas Dufresne
2025-12-25  7:17     ` Kyrie Wu (吴晗)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c133597593c69e0fcb2cb7ea5c14fcb6013302c8.camel@mediatek.com \
    --to=kyrie.wu@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox