From: sashiko-bot@kernel.org
To: "Kyrie Wu" <kyrie.wu@mediatek.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org,
media-ci@linuxtv.org
Subject: Re: [PATCH v6 13/14] media: mediatek: decoder: fill av1 buffer size with picinfo
Date: Mon, 20 Jul 2026 01:48:54 +0000 [thread overview]
Message-ID: <20260720014855.2E44E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720012056.1026551-14-kyrie.wu@mediatek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but this patch incompletely fixes a subsystem-wide issue by fixing AV1 while leaving the exact same bug in the VP9 stateless decoder. The C plane offset for reference frames is incorrectly calculated during dynamic resolution changes.
--
--- Patch [13]: [PATCH v6 13/14] media: mediatek: decoder: fill av1 buffer size with picinfo ---
commit 6fb6f33cb9871d45e294575fbf5e9c61dfa39742
Author: Kyrie Wu <kyrie.wu@mediatek.com>
media: mediatek: decoder: fill av1 buffer size with picinfo
The buffer size of y and c plane has been calculated in vcp/scp,
can fill each frame buffer size with picinfo directly.
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
[ ... ]
> @@ -1845,8 +1846,10 @@ static int vdec_av1_slice_setup_core_buffer(struct vdec_av1_slice_instance *inst
> }
>
> vref->y.dma_addr = vb2_dma_contig_plane_dma_addr(vb, 0);
> + vref->y.size = vsi->fb.y.size;
> + vref->c.size = vsi->fb.c.size;
> if (plane == 1)
> - vref->c.dma_addr = vref->y.dma_addr + size;
> + vref->c.dma_addr = vref->y.dma_addr + vsi->fb.y.size;
[Severity: High]
This is a pre-existing issue, but this fix for AV1 appears to leave the exact
same bug unfixed in the VP9 stateless decoder.
When a VP9 stream changes resolution mid-stream, the driver calculates the
C plane offset based on the current frame's width and height. Does this
erroneously apply the current-frame offset to all previously decoded
reference frames?
vdec_vp9_req_lat_if.c:vdec_vp9_slice_setup_core_buffer() {
...
size = ALIGN(w, 64) * ALIGN(h, 64);
...
vsi->ref[i].c.dma_addr =
vsi->ref[i].y.dma_addr + size;
...
}
If the current frame is smaller than the reference frame, would the hardware
read corrupted chroma data from the middle of the reference frame's Y plane?
If the current frame is larger, could the calculated offset applied to the
reference frame point beyond its actual chroma offset, potentially triggering
a hardware fault via the IOMMU?
Could a similar fix using ctx->picinfo.fb_sz[0] be applied to VP9?
> else
> vref->c.dma_addr = vb2_dma_contig_plane_dma_addr(vb, 1);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720012056.1026551-1-kyrie.wu@mediatek.com?part=13
next prev parent reply other threads:[~2026-07-20 1:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 1:20 [PATCH v6 00/14] media: mediatek: vcodec: support video decoder in mt8196 Kyrie Wu
2026-07-20 1:20 ` [PATCH v6 01/14] media: mediatek: vcodec: support vcp architecture Kyrie Wu
2026-07-20 1:36 ` sashiko-bot
2026-07-20 12:57 ` Nicolas Dufresne
2026-07-20 1:20 ` [PATCH v6 02/14] media: mediatek: vcodec: add driver to support vcp Kyrie Wu
2026-07-20 1:36 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 03/14] media: mediatek: vcodec: add driver to support vcp encoder Kyrie Wu
2026-07-20 1:45 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 04/14] media: mediatek: vcodec: get different firmware ipi id Kyrie Wu
2026-07-20 1:44 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 05/14] media: mediatek: vcodec: get share memory address Kyrie Wu
2026-07-20 1:40 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 06/14] media: mediatek: vcodec: add debug information Kyrie Wu
2026-07-20 1:31 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 07/14] media: mediatek: vcodec: send share memory address to vcp Kyrie Wu
2026-07-20 1:32 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 08/14] dt-bindings: media: mediatek: vcodec: add decoder dt-bindings for mt8196 Kyrie Wu
2026-07-20 1:29 ` sashiko-bot
2026-07-20 5:46 ` Krzysztof Kozlowski
2026-07-20 5:46 ` Krzysztof Kozlowski
2026-07-20 5:49 ` Krzysztof Kozlowski
2026-07-20 5:49 ` Krzysztof Kozlowski
2026-07-20 6:26 ` Kyrie Wu (吴晗)
2026-07-20 6:26 ` Kyrie Wu (吴晗)
2026-07-20 10:19 ` Krzysztof Kozlowski
2026-07-20 10:19 ` Krzysztof Kozlowski
2026-07-20 1:20 ` [PATCH v6 09/14] media: mediatek: vcodec: add decoder compatible to support mt8196 Kyrie Wu
2026-07-20 1:36 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 10/14] media: mediatek: vcodec: define MT8196 vcodec levels Kyrie Wu
2026-07-20 1:20 ` [PATCH v6 11/14] media: mediatek: vcodec: support 36bit iova address Kyrie Wu
2026-07-20 1:20 ` [PATCH v6 12/14] media: mediatek: vcodec: clean xpc status Kyrie Wu
2026-07-20 2:03 ` sashiko-bot
2026-07-20 1:20 ` [PATCH v6 13/14] media: mediatek: decoder: fill av1 buffer size with picinfo Kyrie Wu
2026-07-20 1:48 ` sashiko-bot [this message]
2026-07-20 1:20 ` [PATCH v6 14/14] media: mediatek: decoder: support av1 extend vsi Kyrie Wu
2026-07-20 1:50 ` sashiko-bot
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=20260720014855.2E44E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kyrie.wu@mediatek.com \
--cc=media-ci@linuxtv.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.