Re: [PATCH v2] media: iris: Retain firmware confirmed video_format across GOP restarts

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

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@oss.qualcomm.com>
> ---
> Changes in v2:
> - Updated the commit description (Konrad)
> - Link to v1:https://patch.msgid.link/20260901-read_video_format_from_firmware- 
> v1-1-499edea4d200@oss.qualcomm.com
> ---
>   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@oss.qualcomm.com>