kernel/git/stable/linux.git/drivers/media, branch linux-rolling-stable

media: chips-media: wave5: Resume device before setting EOS flag

2026-09-11T09:51:15+00:00

commit a52e6f7923c17a672135b485ffd96fbd72f46267 upstream. Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run(). Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: chips-media: wave5: Fix pipeline stall when queuing fails

2026-09-11T09:51:15+00:00

commit e3a80073d99c376176d81013335cd355af576be2 upstream. The Wave5 decoder calls v4l2_m2m_job_finish() immediately in device_run() after submitting frames to firmware. When the firmware completes those frames and the queue drains to zero, finish_decode() has no active M2M job to finish, so v4l2_m2m_schedule_next_job() is never called and the decoder stalls. Call v4l2_m2m_try_schedule() in finish_decode() when the firmware queue empties to ensure the framework always schedules the next device_run(). Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued

2026-09-11T09:51:15+00:00

commit b694ba0a5526a69f78a6924982b1553154ccfd73 upstream. Decoder instances sharing a VPU also share one v4l2_m2m job slot, released when the running context calls v4l2_m2m_job_finish(). While draining, device_run() defers job_finish() once EOS is sent (sent_eos), expecting a later finish_decode() (from a DEC_PIC completion IRQ) to release the slot. But the m2m core checks job_ready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finish_decode() has already moved the instance to STOP and sent EOS. device_run() then runs in STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no finish_decode(), and the shared slot is leaked, stalling every instance. With several v4l2h264dec instances in parallel, GStreamer hangs at EOS. Track whether the run actually queued a DEC_PIC (cmd_issued) and defer job_finish() only then. Otherwise finish the job immediately Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: chips-media: wave5: Add timeout while stop_streaming

2026-09-11T09:51:15+00:00

commit 2ae7faed2e60d6d07d9efdd962d20dcb15330ced upstream. When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: chips-media: wave5: avoid skipping device_run while VPU has work

2026-09-11T09:51:15+00:00

commit 8c5a74a24cbbba9142e38c463c96435d316149ce upstream. The decoder stalls because empty_queue is set to true even when the m2m context still has pending commands. As a result, device_run is never invoked, the m2m source queue fills up, and userspace (e.g. Chromium) can no longer queue new bitstream buffers to the V4L2 driver. Fix this by querying the VPU queue status via DEC_GET_QUEUE_STATUS before deciding whether to skip device_run. Only skip when the VPU's instance_queue_count equals the number of ready source buffers in the v4l2-m2m context, which indicates that there is genuinely no new work to perform. Otherwise, proceed with issuing a decode command so that the VPU can continue draining its internal queue. Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: chips-media: wave5: Set inst->std during default format initialization

2026-09-11T09:51:14+00:00

commit cfcefc5a996f6a00b310c963b5f811430f28a30a upstream. When the encoder is opened, wave5_set_default_format() sets up the default capture format (e.g. H.264) but does not initialize inst->std. As a result, inst->std remains zero, which does not match any valid encoder codec. If STREAMON is called before the user explicitly calls S_FMT on the capture queue — as v4l2-compliance does in testBlockingDQBuf — the codec/product check in wave5_vpu_enc_init_seq() fails with "Unsupported encoder-codec & product combination" because inst->std is neither W_HEVC_ENC nor W_AVC_ENC, returning -EOPNOTSUPP. Fix this by setting inst->std via wave5_to_vpu_std() in wave5_set_default_format(), so that the codec type is always consistent with the default capture pixel format from the moment the instance is opened. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: chips-media: wave5: Guard bit depth check with initial_info_obtained

2026-09-11T09:51:14+00:00

commit 1551386934ad43d934c3bb7317929207e1edcd6a upstream. When CAPTURE STREAMON is called before the VPU has completed sequence initialization (initial_info_obtained == false), the initial_info fields contain uninitialized data. The driver checks luma_bitdepth and rejects anything other than 8-bit, so garbage values (e.g. 15) cause STREAMON to fail spuriously. This is reproducible with the following multi-threaded test scenario: 1. Allocate 2 CAPTURE buffers. 2. Call STREAMON on the CAPTURE queue. 3. Call DQBUF, which blocks waiting for a decoded frame. 4. A second thread calls STREAMOFF on the CAPTURE queue. 5. The blocked DQBUF should be released, allowing graceful termination. At step 2, STREAMON reads uninitialized luma_bitdepth and rejects the stream, causing the test to fail. Fix this by checking initial_info_obtained before accessing the bit depth fields, so the validation is only performed when the sequence info has actually been parsed by the VPU. Fixes: 035371c9e509 ("media: chips-media: wave5: Fix timeout while testing 10bit hevc fluster") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: qcom: iris: fix missing hfi_id in gen1 GOP_SIZE cap

2026-09-11T09:51:14+00:00

commit 5eebacbc9a38e1019854ea5f86e367a4d5116387 upstream. Add hfi_id to gen1 encoder GOP_SIZE cap and replace the set function, remove the redundant INTRA_PERIOD cap. Fixes: d22037f3fd33 ("media: iris: Set platform capabilities to firmware for encoder video device") Reviewed-by: Vishnu Reddy Signed-off-by: Wangao Wang Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman

media: qcom: iris: use disable_irq() during power-off

2026-09-11T09:51:14+00:00

commit b9c2215bdedc9c532a7e9d57ec49ee1b6381f863 upstream. The IRQ is registered as a threaded IRQ. Using disable_irq_nosync() in iris_vpu_power_off() does not wait for an already queued threaded IRQ handler to complete before returning. As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off. Replace disable_irq_nosync() with disable_irq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning. Fixes: bb8a95aa038e ("media: iris: implement power management") Cc: stable@vger.kernel.org Suggested-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Hungyu Lin Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman

media: qcom: iris: fix state-change debug log printing stale value

2026-09-11T09:51:14+00:00

commit 460d3257a6dffc7f0bf58009daeb7e0b6eb2d9d3 upstream. The state‑change debug log in iris_inst_change_state() always prints the same value for the old and new state, rendering it useless for debugging. This happens because the state is updated before the log is emitted. Log the transition before updating the state so the previous value is preserved, consistent with the existing sub‑state handling. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Reviewed-by: Bryan O'Donoghue Reviewed-by: Konrad Dybcio Signed-off-by: Dikshita Agarwal Signed-off-by: Vishnu Reddy Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman