* [PATCH v2] media: iris: Retain firmware confirmed video_format across GOP restarts
@ 2026-09-05 13:57 Vishnu Reddy
2026-10-05 13:00 ` Vikash Garodia
0 siblings, 1 reply; 2+ messages in thread
From: Vishnu Reddy @ 2026-09-05 13:57 UTC (permalink / raw)
To: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Vikash Garodia
Cc: linux-media, linux-arm-msm, linux-kernel, Vishnu Reddy
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(-)
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.h b/drivers/media/platform/qcom/iris/iris_hfi_common.h
index a27447eb2519..439197e9e199 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_common.h
+++ b/drivers/media/platform/qcom/iris/iris_hfi_common.h
@@ -141,6 +141,7 @@ struct hfi_subscription_params {
u32 fw_min_count;
u32 pic_order_cnt;
u32 color_info;
+ u32 video_format;
u32 profile;
u32 level;
u32 tier;
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c b/drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c
index 388a36ff2b07..a43a9d7687ad 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c
@@ -358,7 +358,7 @@ static int iris_hfi_gen2_set_colorspace(struct iris_inst *inst, u32 plane)
struct v4l2_pix_format_mplane *pixmp = &inst->fmt_src->fmt.pix_mp;
u32 video_signal_type_present_flag = 0, color_info;
u32 matrix_coeff = HFI_MATRIX_COEFF_RESERVED;
- u32 video_format = UNSPECIFIED_COLOR_FORMAT;
+ u32 video_format = inst_hfi_gen2->src_subcr_params.video_format;
u32 full_range = V4L2_QUANTIZATION_DEFAULT;
u32 transfer_char = HFI_TRANSFER_RESERVED;
u32 port = iris_hfi_gen2_get_port(inst, plane);
@@ -806,6 +806,7 @@ static int iris_hfi_gen2_session_open(struct iris_inst *inst)
inst_hfi_gen2->ipsc_properties_set = false;
inst_hfi_gen2->opsc_properties_set = false;
+ inst_hfi_gen2->src_subcr_params.video_format = UNSPECIFIED_COLOR_FORMAT;
inst_hfi_gen2->packet = kzalloc(4096, GFP_KERNEL);
if (!inst_hfi_gen2->packet)
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c b/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
index 8c2644c7f6e8..8b1ff253a560 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
@@ -581,6 +581,8 @@ static void iris_hfi_gen2_read_input_subcr_params(struct iris_inst *inst)
full_range = (subsc_params.color_info & 0x2000000) >> 25;
video_signal_type_present_flag =
(subsc_params.color_info & 0x20000000) >> 29;
+ inst_hfi_gen2->src_subcr_params.video_format =
+ (subsc_params.color_info & 0x1C000000) >> 26;
pixmp_op->colorspace = V4L2_COLORSPACE_DEFAULT;
pixmp_op->xfer_func = V4L2_XFER_FUNC_DEFAULT;
---
base-commit: 9d80aa4617b32f5054c5aa471d06b66704854935
change-id: 20260905-read_video_format_from_firmware-ecbb322a6fd4
Best regards,
--
Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [PATCH v2] media: iris: Retain firmware confirmed video_format across GOP restarts
2026-09-05 13:57 [PATCH v2] media: iris: Retain firmware confirmed video_format across GOP restarts Vishnu Reddy
@ 2026-10-05 13:00 ` Vikash Garodia
0 siblings, 0 replies; 2+ messages in thread
From: Vikash Garodia @ 2026-10-05 13:00 UTC (permalink / raw)
To: Vishnu Reddy, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab
Cc: linux-media, linux-arm-msm, linux-kernel
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>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-05 13:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-05 13:57 [PATCH v2] media: iris: Retain firmware confirmed video_format across GOP restarts Vishnu Reddy
2026-10-05 13:00 ` Vikash Garodia
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®