[PATCH AUTOSEL 6.19-6.12] media: chips-media: wave5: Process ready frames when CMD_STOP sent to Encoder

[Sasha Levin <sashal@kernel.org>]

From: Brandon Brnich <b-brnich@ti.com>

[ Upstream commit 5da0380de41439ed64ed9a5218850db38544e315 ]

CMD_STOP being sent to encoder before last job is executed by device_run
can lead to an occasional dropped frame. Ensure that remaining ready
buffers are drained by making a call to v4l2_m2m_try_schedule.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Here is my complete analysis:

---

## Analysis of: "media: chips-media: wave5: Process ready frames when
CMD_STOP sent to Encoder"

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly describes a bug: **CMD_STOP being sent to the
encoder before the last job is executed by `device_run` can lead to an
occasional dropped frame.** The fix is to call `v4l2_m2m_try_schedule()`
to ensure remaining ready buffers are drained. This is a data integrity
issue - users lose the last frame of their encoded video.

### 2. CODE CHANGE ANALYSIS

The change is a **two-line addition** (one blank line + one function
call) in `wave5_vpu_enc_encoder_cmd()`:

```653:654:drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
                m2m_ctx->is_draining = true;

                v4l2_m2m_try_schedule(m2m_ctx);
```

**The bug mechanism:**

When userspace sends `V4L2_ENC_CMD_STOP`, the driver:
1. Sets `m2m_ctx->last_src_buf` to the last queued source buffer
2. Sets `m2m_ctx->is_draining = true`
3. Returns - **without triggering the m2m scheduler**

The problem is a race: if CMD_STOP arrives between when the last buffer
is queued and when `device_run` picks it up, the m2m framework has no
trigger to schedule the remaining work. The `wave5_vpu_enc_job_ready()`
callback (line 1542) checks `is_draining` and returns `true` to indicate
the encoder is ready for a drain job - but nobody calls the scheduler to
check this.

`v4l2_m2m_try_schedule()` simply calls `__v4l2_m2m_try_queue()` +
`v4l2_m2m_try_run()` - it checks if there's work ready and runs it. It's
completely safe - if there's nothing to do, it returns without side
effects.

### 3. COMPARISON WITH OTHER DRIVERS

This is an **inconsistency bug** that's obvious when comparing with
other m2m codec drivers:

- **wave5 decoder** (`wave5_vpu_dec_decoder_cmd`, line 888): Already
  calls `v4l2_m2m_try_schedule(m2m_ctx)` after DEC_CMD_STOP, with the
  comment "Just in case we don't have anything to decode anymore"
- **MediaTek encoder** (`vidioc_encoder_cmd` in `mtk_vcodec_enc.c`, line
  734): Calls `v4l2_m2m_try_schedule(ctx->m2m_ctx)` after ENC_CMD_STOP
- **MediaTek decoder** (`stateful_decoder_cmd`, line 116): Same pattern
- **CODA decoder** (`coda_decoder_cmd`, line 1268): Same pattern

The wave5 encoder was the **only** m2m encoder/decoder driver that set
`is_draining = true` without calling `v4l2_m2m_try_schedule()`. This is
clearly a bug present since the driver's initial submission.

### 4. CLASSIFICATION

**Bug fix** - fixes dropped frames (data loss) during video encoding
drain. Not a feature, not cleanup.

### 5. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 2 (1 blank + 1 function call)
- **Files touched**: 1
- **Risk**: Extremely low. `v4l2_m2m_try_schedule()` is the standard
  V4L2 m2m API for triggering job scheduling. It's called in every other
  similar driver. It's safe to call at any time - if conditions aren't
  met for scheduling a job, it simply returns.
- **Subsystem**: media/chips-media/wave5 - a hardware video encoder
  driver for Chips&Media Wave5 IP used on TI platforms

### 6. USER IMPACT

Users encoding video with the Wave5 hardware encoder (e.g., on TI
AM62x/AM62Ax platforms) can **lose the last frame** when stopping
encoding. This is a real data integrity issue for anyone doing video
encoding with this hardware. The symptom is intermittent, making it
harder to diagnose.

### 7. STABILITY INDICATORS

- **Reviewed-by**: Nicolas Dufresne (Collabora - well-known
  V4L2/GStreamer developer)
- **Signed-off-by**: Hans Verkuil (media subsystem co-maintainer)
- **Author**: Brandon Brnich from TI (the SoC vendor that ships this IP)
- The fix follows established patterns from other drivers

### 8. DEPENDENCY CHECK

**No dependencies.** This is a self-contained one-line fix that adds a
call to an existing exported V4L2 m2m API function. The
`v4l2_m2m_try_schedule()` function has been available since long before
the wave5 driver was added.

### 9. STABLE TREE APPLICABILITY

The wave5 driver was added in v6.8-rc1 (commit `9707a6254a8a6`). It
exists in stable trees 6.8.y and later. The fix should apply cleanly
since the `wave5_vpu_enc_encoder_cmd` function hasn't changed
significantly since it was added.

### Summary

This is a textbook stable-worthy fix:
- **Small**: 2 lines added
- **Obviously correct**: Matches the pattern used by every other V4L2
  m2m encoder/decoder driver
- **Fixes a real bug**: Dropped frames during encoding drain (data loss)
- **Low risk**: Uses standard API, no side effects if conditions aren't
  met
- **Well-reviewed**: By V4L2 experts and the media subsystem maintainer
- **Self-contained**: No dependencies on other patches

**YES**

 drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
index bca881a0a1617..8e3dd9e34abc3 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
@@ -649,6 +649,8 @@ static int wave5_vpu_enc_encoder_cmd(struct file *file, void *fh, struct v4l2_en
 
 		m2m_ctx->last_src_buf = v4l2_m2m_last_src_buf(m2m_ctx);
 		m2m_ctx->is_draining = true;
+
+		v4l2_m2m_try_schedule(m2m_ctx);
 		break;
 	case V4L2_ENC_CMD_START:
 		break;
-- 
2.51.0