Re: [PATCH v2] media: iris: Retain firmware confirmed video_format across GOP restarts
From: Vikash Garodia
Date: Mon Oct 05 2026 - 09:03:00 EST
On 9/5/2026 7:27 PM, Vishnu Reddy wrote:
During speed-based rewind, the client restarts the decoder queues once per
group of pictures (GOP). This is because playing a GOP-based stream in
reverse requires decoding each group forward first and then showing its
frames in reverse order. Each restart makes the driver resend the colour
info property on the bitstream port, which firmware always treats as a
sign that the stream's properties may have changed. The driver never
stored the video_format value that firmware had last confirmed, so it
resent colour info with a fixed unspecified value instead of the real one,
and the value firmware received kept differing from what it already had.
On every restart during rewind, this looked to firmware like a real change
on the bitstream port, so firmware sent a settings-change notification,
and the driver treated it as a dynamic resolution change and paused the
port. The client then removed its buffers and built new ones for a
resolution that had not actually changed, stalling playback once per GOP.
Store and send back the same video_format value firmware already confirmed
so both sides stay in agreement across every restart, avoiding the false
settings-change notification.
Signed-off-by: Vishnu Reddy<busanna.reddy@xxxxxxxxxxxxxxxx>
---
Changes in v2:
- Updated the commit description (Konrad)
- Link to v1:https://patch.msgid.link/20260901-read_video_format_from_firmware- v1-1-499edea4d200@xxxxxxxxxxxxxxxx
---
drivers/media/platform/qcom/iris/iris_hfi_common.h | 1 +
drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c | 3 ++-
drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>