linux/drivers/media/platform/mediatek/vcodec/decoder/vdec, branch master

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

media: mediatek: vcodec: use = { } instead of memset()

2026-01-05T14:56:31Z

Based on testing and recommendations by David Lechner et al. [1][2], using = { } to initialize a structure or array is the preferred way to do this in the kernel. Converts memset() to = { }, thereby: - Eliminating the risk of sizeof() mismatches. - Simplifying the code. [1]: https://lore.kernel.org/linux-iio/202505090942.48EBF01B@keescook/ [2]: https://lore.kernel.org/lkml/20250614151844.50524610@jic23-huawei/ Signed-off-by: Qianfeng Rong Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil

media: v4l2-mem2mem: Don't copy frame flags in v4l2_m2m_buf_copy_metadata()

2025-10-17T09:31:16Z

The v4l2_m2m_buf_copy_metadata() function takes a boolean copy_frame_flags argument. When true, it causes the function to copy the V4L2_BUF_FLAG_KEYFRAME, V4L2_BUF_FLAG_BFRAME and V4L2_BUF_FLAG_PFRAME flags from the output buffer to the capture buffer. There is no use cases in any upstream driver for copying the flags. KEY/P/B frames are properties of the bitstream buffer in some formats. Once decoded, this is no longer a property of the video frame and should be discarded. It was considered useful to know if an uncompressed frame was decoded from a KEY/P/B compressed frame, and to preserve that information if that same uncompressed frame was passed through another M2M device (e.g. a scaler). However, the V4L2 documentation makes it clear that the flags are meant for compressed frames only. Drop the copy_frame_flags argument from v4l2_m2m_buf_copy_metadata(). The change to drivers was performed with the following Coccinelle semantic patch: @@ expression src; expression dst; expression flag; @@ - v4l2_m2m_buf_copy_metadata(src, dst, flag); + v4l2_m2m_buf_copy_metadata(src, dst); include/media/v4l2-mem2mem.h and drivers/media/v4l2-core/v4l2-mem2mem.c have been updated manually. Signed-off-by: Laurent Pinchart Reviewed-by: Philipp Zabel Reviewed-by: Benjamin Gaignard Signed-off-by: Hans Verkuil

media: mediatek: vcodec: Drop unneeded v4l2_m2m_get_vq() NULL check

2025-10-17T09:31:14Z

The v4l2_m2m_get_vq() function never returns NULL. In the set format handlers, the check may have been intended to catch invalid format types, but that's not needed as the V4L2 core picks the appropriate VIDIOC_S_FMT ioctl handler based on the format type, so the type can't be incorrect. In the get format handlers, the return value is not used for any purpose other than the NULL check, which was therefore probably intended to catch invalid format types. That's not needed for the same reason as in the set format handler. In other locations the v4l2_m2m_get_vq() function is called with a hardcoded V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE type, so the NULL check can't have been an attempt to catch an invalid type there either. Drop the unneeded return value checks and, as the function has no side effect, the unneeded function call as well. Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: mediatek: vcodec: add description for vsi struct

2025-04-11T11:21:14Z

The vsi (video shared information) struct needs to be synchronized between firmware and host, as a change that is only done in the host version of the struct but isn't synchronized to the firmware. This can lead to decoding issues with H264 bitstreams. Highlight this requirement within the struct descriptions. Signed-off-by: Yunfei Dong Reviewed-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil

media: mediatek: vcodec: support extended h264 decode

2025-04-11T11:21:13Z

Add a new extended vsi_ext struct besides the existing vsi struct, to enable calculating the end of the address range of the current working buffer for architectures, where simply adding the buffer size to the start of the address range isn't sufficient. Additionally, on extended architectures, the NAL information can be fetched directly from the firmware, which allows skipping the parsing step within the kernel. Signed-off-by: Yunfei Dong Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil

media: mediatek: vcodec: remove vsi operation in common interface

2025-04-11T11:21:12Z

Extend the VSI (video shared information) struct to allow sending slice parameters to SCP, as the parameters have changed on MT8188 architecture. Remove VSI related information from the common interface to ensure that the interface is usable by architectures with and without the extended parameters. The new VSI extensions will be introduced in later patches. Signed-off-by: Yunfei Dong Reviewed-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil

media: mediatek: vcodec: Correct vsi_core framebuffer size

2025-04-11T11:21:12Z

The framebuffer size for decoder instances was being incorrectly set - inst->vsi_core->fb.y.size was assigned twice consecutively. Assign the second picinfo framebuffer size to the C framebuffer instead, which appears to be the intended target based on the surrounding code. Fixes: 2674486aac7d ("media: mediatek: vcodec: support stateless hevc decoder") Cc: stable@vger.kernel.org Signed-off-by: Fei Shao Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil

media: mediatek: vcodec: mark vdec_vp9_slice_map_counts_eob_coef noinline

2024-12-13T16:51:35Z

With KASAN enabled, clang fails to optimize the inline version of vdec_vp9_slice_map_counts_eob_coef() properly, leading to kilobytes of temporary values spilled to the stack: drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than] This seems to affect all versions of clang including the latest (clang-20), but the degree of stack overhead is different per release. Marking the function as noinline_for_stack is harmless here and avoids the problem completely. Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Sebastian Fricke Signed-off-by: Mauro Carvalho Chehab