Skip to content

media: iris: Retain firmware confirmed video_format across GOP restarts - #1121

Open
gouravk-qualcomm wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
gouravk-qualcomm:rewind-fix
Open

gouravk-qualcomm wants to merge 1 commit into
qualcomm-linux:qcom-6.18.yfrom
gouravk-qualcomm:rewind-fix

Conversation

@gouravk-qualcomm

@gouravk-qualcomm gouravk-qualcomm commented Sep 16, 2026

Copy link
Copy Markdown

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.

CRs-fixed:4568445

@qswat-orbit-external

Copy link
Copy Markdown

Merge Check Failed: CR Not Eligible for Merge

CR 4568445 is not eligible for merge.

The parent software image for kernel.qli.2.0 is not development complete.

Entity: kernel.qli.2.0
CR: 4568445
Reason: CR_CANNOT_MERGE

Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations.

@qswat-orbit-external

Copy link
Copy Markdown

Merge Check Failed: No CR Numbers Found

Error: No Change Request numbers were found.

Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests.

@qlijarvis

Copy link
Copy Markdown

PR #1121 — validate-patch

PR: #1121

Verdict Issues Detailed Report
8 Full report

Final Summary

  1. Lore link present: No — FROMLIST: prefix used but no Link: https://lore.kernel.org/r/<message-id> tag found in commit message (required for FROMLIST commits)

  2. Lore link matches PR commits: N/A — cannot verify without a lore link

  3. Upstream patch status: Unknown — cannot determine acceptance status without a lore link; if truly posted to a mailing list, the link must be added to track review status

  4. PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1121 - FROMLIST: media: iris: Retain firmware confirmed video_format across GOP restarts
Upstream commit: N/A (no lore.kernel.org link found)
Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream N/A No lore link to compare against
Body preserves rationale N/A No lore link to compare against
Fixes tag present/correct ⚠️ No Fixes tag present; unclear if this fixes a regression
Authorship preserved N/A No lore link to compare against
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
drivers/media/platform/qcom/iris/iris_hfi_common.h ⚠️ Cannot verify against upstream - no lore link
drivers/media/platform/qcom/iris/iris_hfi_gen2_command.c ⚠️ Cannot verify against upstream - no lore link
drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c ⚠️ Cannot verify against upstream - no lore link

Issues

Critical: Missing lore.kernel.org link

  • The commit uses the FROMLIST: prefix, which indicates the patch was posted to a mailing list
  • Per the validate-patch skill requirements, FROMLIST: commits must include a Link: https://lore.kernel.org/r/<message-id> tag in the commit message
  • No such link is present in this commit

Missing from integration branches

  • Per integration_presence_report.md: This commit is missing from both qcom-next and topics (0/1 commits present)
  • A FROMLIST: patch should typically be present in at least one topic branch before being merged

Commit message structure

  • The commit message body is well-written and explains the problem and solution clearly
  • However, without a lore link, the upstream posting cannot be verified
  • Consider adding a Fixes: tag if this addresses a regression introduced by a specific commit

Verdict

Do not merge until the following issues are resolved:

  1. Add the required lore.kernel.org link - The FROMLIST: prefix requires a Link: tag pointing to the mailing list posting
  2. Verify the patch was actually posted upstream - If not yet posted, consider changing the prefix to PENDING: or QCLINUX: as appropriate
  3. Ensure the patch is in a topic branch - FROMLIST: patches should typically land in a topic branch (visible in kernel-topics) before integration

Final Summary

  1. Lore link present: No — FROMLIST: prefix used but no Link: https://lore.kernel.org/r/<message-id> tag found in commit message (required for FROMLIST commits)

  2. Lore link matches PR commits: N/A — cannot verify without a lore link

  3. Upstream patch status: Unknown — cannot determine acceptance status without a lore link; if truly posted to a mailing list, the link must be added to track review status

  4. PR present in qcom-next/topics: Fail — 1/1 commit(s) are missing from both qcom-next and topics (per integration_presence_report.md)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: d49c33864d06e9672dce57738be8851384578fcf
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 [PATCH] FROMLIST: media: iris: Retain firmware confirmed video_format missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing

Final Status

overall_status: FAIL
present_commits: 0/1
partial_commits: 0/1
missing_commits: 1/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Fail - 1/1 commit(s) are missing from both qcom-next and topics

@qlijarvis

Copy link
Copy Markdown

PR #1121 — checker-log-analyzer

PR: #1121
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/35066765128

Checker Result Summary
Checker Result Summary
checkpatch No style issues
dt-binding-check ⏭️ Skipped (no DT binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check No static analysis warnings
check-uapi-headers No UAPI changes
check-patch-compliance Missing required prefix
tag-check Subject prefix mandatory for qcom-6.18.y

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1121 - FROMLIST: media: iris: Retain firmware confirmed video_format across GOP restarts
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/35066765128
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch No style issues
dt-binding-check ⏭️ Skipped (no DT binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check No static analysis warnings
check-uapi-headers No UAPI changes
check-patch-compliance Missing required prefix
tag-check Subject prefix mandatory for qcom-6.18.y

❌ check-patch-compliance

Root cause: Commit subject line does not start with a required prefix tag.

Failure details:

Checking commit: media: iris: Retain firmware confirmed video_format across GOP restarts
Commit summary does not start with a required prefix

The checker detected the commit subject as:

media: iris: Retain firmware confirmed video_format across GOP restarts

This is missing the FROMLIST: prefix that should appear at the start of the subject line.

Additional issue: The commit message is also missing a Link: tag pointing to the lore.kernel.org URL where this patch was posted upstream.

Fix:

  1. Add the FROMLIST: prefix to the commit subject:

    git rebase -i b15f7bd724dba0a8ad9c1b58f754722e55f37260
    # Mark commit 7dc118a2422b as 'edit'
    git commit --amend -m "FROMLIST: media: iris: Retain firmware confirmed video_format across GOP restarts"
    # Keep the rest of the commit message body unchanged
    git rebase --continue
  2. Add a Link: tag to the commit body (if this patch was posted to a mailing list):

    git rebase -i b15f7bd724dba0a8ad9c1b58f754722e55f37260
    # Mark commit as 'edit'
    git commit --amend
    # Add before the Signed-off-by line:
    # Link: https://lore.kernel.org/...
    git rebase --continue

Note: The patch file (pr.patch) shows FROMLIST: in the subject, but the actual git commit in the tree is missing it. This suggests the commit was amended or rebased incorrectly after the patch file was generated. Ensure the git commit itself has the prefix, not just the patch file.

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base b15f7bd724dba0a8ad9c1b58f754722e55f37260 \
  --head 7dc118a2422b4137feaf5586834ee3b9308ad74b

❌ tag-check

Root cause: Target branch qcom-6.18.y requires all commits to have a subject prefix tag.

Failure details:

The PR targets qcom-6.18.y, which is not qcom-next or qcom-next-staging. All branches except those two require every commit to start with one of these prefixes:

  • FROMLIST: — Patch posted to mailing list (lore.kernel.org)
  • FROMGIT: — Patch taken from a maintainer git tree
  • UPSTREAM: — Patch merged into Linus's mainline tree
  • BACKPORT: — Upstream patch backported with modifications
  • QCLINUX: — Vendor-only change with no upstream equivalent
  • PENDING: — Work-in-progress, not yet posted upstream
  • WORKAROUND: — Temporary fix not suitable for upstream

The commit subject currently reads:

media: iris: Retain firmware confirmed video_format across GOP restarts

This is missing the required prefix.

Fix:

Based on the commit message content (which describes a fix for a decoder issue), this appears to be a patch that should be posted upstream. Use the FROMLIST: prefix:

git rebase -i b15f7bd724dba0a8ad9c1b58f754722e55f37260
# Mark commit 7dc118a2422b as 'edit'
git commit --amend -m "FROMLIST: media: iris: Retain firmware confirmed video_format across GOP restarts"
# Keep the rest of the commit message unchanged
git rebase --continue

If this patch has already been merged upstream, use UPSTREAM: instead. If it's vendor-specific and will never go upstream, use QCLINUX: (though note that check-patch-compliance will still fail for QCLINUX: — this is a known checker limitation).


Verdict

2 blockers must be fixed before merge:

  1. Add FROMLIST: prefix to the commit subject line
  2. Add Link: tag to the commit body pointing to the lore.kernel.org URL (if the patch was posted upstream)

Both issues stem from the same root cause: the commit is missing the required upstream traceability metadata. Once the prefix and Link tag are added, re-push the branch to trigger a new CI run.

…GOP restarts

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.

Link: https://lore.kernel.org/all/20260905-read_video_format_from_firmware-v2-1-21a606cdd288@oss.qualcomm.com/
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants