kernel/drivers/media/platform/mediatek/vcodec/decoder, branch linux-rolling-stable

media: mediatek: vcodec: Don't try to decode 422/444 VP9

2026-03-04T12:19:57Z

[ Upstream commit 3e92d7e4935084ecdbdc88880cc4688618ae1557 ] This is not supported by the hardware and trying to decode these leads to LAT timeout errors. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: mediatek: vcodec: Use spinlock for context list protection lock

2025-10-20T07:23:17Z

Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler. Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered. Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock. Fixes: 6467cda18c9f ("media: mediatek: vcodec: adding lock to protect decoder context list") Fixes: afaaf3a0f647 ("media: mediatek: vcodec: adding lock to protect encoder context list") Cc: Yunfei Dong Cc: stable@vger.kernel.org Signed-off-by: Chen-Yu Tsai Reviewed-by: Fei Shao Reviewed-by: Tomasz Figa 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: mtk: vcodec: Access v4l2_fh from file

2025-08-13T06:33:49Z

The v4l2_fh associated with an open file handle is now guaranteed to be available in file->private_data, initialised by v4l2_fh_add(). Access the v4l2_fh, and from there the driver-specific structure, from the file * in all ioctl handlers. While at modify mtk_vcodec_enc_get_chip_name() to accept a ctx instead of a raw void *. Signed-off-by: Jacopo Mondi Co-developed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: Reset file->private_data to NULL in v4l2_fh_del()

2025-08-13T06:33:44Z

Multiple drivers that use v4l2_fh and call v4l2_fh_del() manually reset the file->private_data pointer to NULL in their video device .release() file operation handler. Move the code to the v4l2_fh_del() function to avoid direct access to file->private_data in drivers. This requires adding a file pointer argument to the function. Changes to drivers have been generated with the following coccinelle semantic patch: @@ expression fh; identifier filp; identifier release; type ret; @@ ret release(..., struct file *filp, ...) { <... - filp->private_data = NULL; ... - v4l2_fh_del(fh); + v4l2_fh_del(fh, filp); ...> } @@ expression fh; identifier filp; identifier release; type ret; @@ ret release(..., struct file *filp, ...) { <... - v4l2_fh_del(fh); + v4l2_fh_del(fh, filp); ... - filp->private_data = NULL; ...> } @@ expression fh; identifier filp; identifier release; type ret; @@ ret release(..., struct file *filp, ...) { <... - v4l2_fh_del(fh); + v4l2_fh_del(fh, filp); ...> } Manual changes have been applied to Documentation/ to update the usage patterns, to drivers/media/v4l2-core/v4l2-fh.c to update the v4l2_fh_del() prototype and reset file->private_data, and to include/media/v4l2-fh.h to update the v4l2_fh_del() function prototype and its documentation. Additionally, white space issues have been fixed manually in drivers/usb/gadget/function/uvc_v4l2.c Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: Set file->private_data in v4l2_fh_add()

2025-08-13T06:33:39Z

All the drivers that use v4l2_fh and call v4l2_fh_add() manually store a pointer to the v4l2_fh instance in file->private_data in their video device .open() file operation handler. Move the code to the v4l2_fh_add() function to avoid direct access to file->private_data in drivers. This requires adding a file pointer argument to the function. Changes to drivers have been generated with the following coccinelle semantic patch: @@ expression fh; identifier filp; identifier open; type ret; @@ ret open(..., struct file *filp, ...) { <... - filp->private_data = fh; ... - v4l2_fh_add(fh); + v4l2_fh_add(fh, filp); ...> } @@ expression fh; identifier filp; identifier open; type ret; @@ ret open(..., struct file *filp, ...) { <... - v4l2_fh_add(fh); + v4l2_fh_add(fh, filp); ... - filp->private_data = fh; ...> } Manual changes have been applied to Documentation/ to update the usage patterns, to drivers/media/v4l2-core/v4l2-fh.c to update the v4l2_fh_add() prototype set file->private_data, and to include/media/v4l2-fh.h to update the v4l2_fh_add() function prototype and its documentation. Additionally, white space issues have been fixed manually in drivers/media/platform/nvidia/tegra-vde/v4l2.c, drivers/media/platform/rockchip/rkvdec/rkvdec.c, drivers/media/v4l2-core/v4l2-fh.c and drivers/staging/most/video/video.c. Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: Replace file->private_data access with custom functions

2025-08-13T06:33:30Z

Accessing file->private_data manually to retrieve the v4l2_fh pointer is error-prone, as the field is a void * and will happily cast implicitly to any pointer type. Replace all remaining locations that read the v4l2_fh pointer directly from file->private_data and cast it to driver-specific file handle structures with driver-specific functions that use file_to_v4l2_fh() and perform the same cast. No functional change is intended, this only paves the way to remove direct accesses to file->private_data and make V4L2 drivers safer. Other accesses to the field will be addressed separately. Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: mediatek: vcodec: Enable HEVC main still picture decode

2025-04-24T13:21:34Z

Mediatek devices that support HEVC also support the main still picture profile, but today, the main still picture profile is excluded. This removes the skip mask for HEVC, and enables the main still picture profile decoding. Signed-off-by: Nathan Hebert Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne 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