Skip to content

FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_e… - #1631

Open
YongxingMou wants to merge 1 commit into
qualcomm-linux:tech/mm/drmfrom
YongxingMou:for-usbdp-preboot
Open

FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_e…#1631
YongxingMou wants to merge 1 commit into
qualcomm-linux:tech/mm/drmfrom
YongxingMou:for-usbdp-preboot

Conversation

@YongxingMou

Copy link
Copy Markdown

…nable

If a downstream consumer (e.g. drm_bridge_connector attached by the msm/dp driver) registers its HPD callback after an upstream driver has already reported a HPD event through drm_aux_hpd_bridge_notify(), the notification is dropped because bridge->hpd_cb is still NULL. This can affect any user of drm_aux_hpd_bridge_notify() whose downstream consumer arms HPD only after upstream events have started.

The race has been observed on Qualcomm X1E-based laptops during boot, when pmic_glink_altmode reports the initial USB-C DP connection state before the DP driver has finished probing and enabled HPD handling on the bridge. The consumer then never observes the initial connected state and the external display remains dark.

Cache the last HPD status reported through drm_aux_hpd_bridge_notify() and replay it when HPD is enabled by the downstream consumer.

The replay is deferred to a work item so that the replayed HPD notification is delivered outside drm_bridge_hpd_enable()'s call context.

This follows the same pattern as display-connector, which also defers an initial HPD notification from .hpd_enable(), but reuses the cached status since aux-hpd-bridge cannot re-detect sink presence on its own.

Fixes: e560518 ("drm/bridge: implement generic DP HPD bridge")

Link: https://lore.kernel.org/all/20260803-drm-usbdp-preboot-v1-1-2539b362be00@oss.qualcomm.com/

CRs-Fixed: 4618390

…nable

If a downstream consumer (e.g. drm_bridge_connector attached by the
msm/dp driver) registers its HPD callback after an upstream driver
has already reported a HPD event through drm_aux_hpd_bridge_notify(),
the notification is dropped because bridge->hpd_cb is still NULL.
This can affect any user of drm_aux_hpd_bridge_notify() whose
downstream consumer arms HPD only after upstream events have started.

The race has been observed on Qualcomm X1E-based laptops during boot,
when pmic_glink_altmode reports the initial USB-C DP connection state
before the DP driver has finished probing and enabled HPD handling on
the bridge. The consumer then never observes the initial connected
state and the external display remains dark.

Cache the last HPD status reported through drm_aux_hpd_bridge_notify()
and replay it when HPD is enabled by the downstream consumer.

The replay is deferred to a work item so that the replayed HPD
notification is delivered outside drm_bridge_hpd_enable()'s call
context.

This follows the same pattern as display-connector, which also defers
an initial HPD notification from .hpd_enable(), but reuses the cached
status since aux-hpd-bridge cannot re-detect sink presence on its own.

Fixes: e560518 ("drm/bridge: implement generic DP HPD bridge")
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260803-drm-usbdp-preboot-v1-1-2539b362be00@oss.qualcomm.com/
@qcomlnxci
qcomlnxci requested review from a team, Rajesh Kemisetti (quic-rajeshk) and riteshk-quic and removed request for a team August 3, 2026 09:10
@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1631

PR: #1631
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/30800264633

# Error File:Line PR-introduced? Root Cause
1 Merge conflict (add/add) drivers/gpu/drm/bridge/lontium-lt9611c.c No Pre-existing integration conflict in topic branch topic/tech/mm/drm unrelated to PR changes

Verdict

0 of 1 errors are introduced by this PR; 1 is a pre-existing integration issue. The PR itself is clean and does not cause any compilation errors. The build failed during the automerge step when integrating the topic branch with the baseline, encountering a merge conflict in a file (lontium-lt9611c.c) that this PR does not modify.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1631

PR: #1631
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/30800264633

# Error File:Line PR-introduced? Root Cause
1 Merge conflict (add/add) drivers/gpu/drm/bridge/lontium-lt9611c.c No Pre-existing integration conflict between topic branches during automerge; unrelated to PR changes

Verdict

This is not a compilation failure. The build failed during the automerge/integration step due to a pre-existing conflict in lontium-lt9611c.c, which is not modified by this PR. The PR changes to aux-hpd-bridge.c are not the cause of this failure.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

PR #1631 — validate-patch

PR: #1631

Verdict Issues Detailed Report
3 Full report

Final Summary

  1. Lore link present: Yes — https://lore.kernel.org/all/20260803-drm-usbdp-preboot-v1-1-2539b362be00@oss.qualcomm.com/
  2. Lore link matches PR commits: No — PR modifies different function (_notify_extra vs _notify), adds extra conditional logic, removes atomic helper hooks, and changes comment wording; these are semantic changes beyond context adaptation
  3. Upstream patch status: ⏳ Decision Pending — posted 2026-08-03, only AI bot reply, no maintainer decision yet
  4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence
Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1631 - FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_enable
Upstream commit: https://lore.kernel.org/all/20260803-drm-usbdp-preboot-v1-1-2539b362be00@oss.qualcomm.com/
Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream Subject identical (FROMLIST: prefix added correctly)
Body preserves rationale Full problem description and fix rationale preserved
Fixes tag present/correct Fixes: e560518a6c2e present and correct
Authorship preserved From: matches lore author (Yongxing Mou)
Backport note (if applicable) N/A FROMLIST: commit, not a backport

Diff

File Status Notes
drivers/gpu/drm/bridge/aux-hpd-bridge.c Multiple semantic changes not present in upstream lore patch

Issues

Critical diff divergences from lore upstream:

  1. Extra conditional logic in notify function — PR adds 8-line comment + if (status != connector_status_unknown) guard around WRITE_ONCE(data->last_status, status) in drm_aux_hpd_bridge_notify_extra(). Lore patch has unconditional WRITE_ONCE(data->last_status, status) in drm_aux_hpd_bridge_notify().

  2. Different function patched — PR modifies drm_aux_hpd_bridge_notify_extra() while lore patch modifies drm_aux_hpd_bridge_notify(). These are different functions with different signatures.

  3. Missing atomic helper hooks — Lore patch includes .atomic_create_state, .atomic_destroy_state, .atomic_duplicate_state in drm_aux_hpd_bridge_funcs. PR patch removes these entirely, leaving only .attach, .hpd_enable, .hpd_disable.

  4. Different comment wording — PR comment says "Deferred to a work because drm_bridge_hpd_notify() takes bridge->hpd_mutex which is already held by drm_bridge_hpd_enable()." Lore comment says "Deferred to a work item so that the replayed HPD notification is delivered outside drm_bridge_hpd_enable()'s call context." (semantic difference: PR explains why mutex is a problem; lore explains what the deferral achieves).

  5. Different include context — Lore patch shows #include <drm/drm_atomic_helper.h> in context; PR shows #include <drm/bridge/aux-bridge.h>. This indicates the PR is based on a different tree version where the file structure differs.

Root cause: This PR appears to be a modified adaptation of the lore patch to a different kernel tree version (likely qcom-next or a vendor tree) where:

  • The file has been refactored (no atomic helpers, different includes)
  • The notify function has been split into _notify() and _notify_extra()
  • Additional logic was added to handle connector_status_unknown filtering

This is not a faithful FROMLIST: backport — it contains significant semantic changes beyond simple context adaptation.

Upstream Patch Status

Commit Community Verdict
drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_enable ⏳ Decision Pending — posted 2026-08-03, only AI bot reply (Sashiko), no maintainer review yet

qcom-next Presence

Commit Status
FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status ⚠️ Partial — subject or partial tree evidence found in qcom-next, but full change not verified (per integration_presence_report.md)

Verdict

Do not merge without correction. This PR is labelled FROMLIST: but contains substantial semantic changes not present in the linked lore patch:

  1. Different function modified (_notify_extra vs _notify)
  2. Extra conditional logic filtering connector_status_unknown
  3. Missing atomic helper function pointers
  4. Different comment rationale

Required fixes:

  • If this is an adaptation to a refactored tree, split into two commits:

    1. FROMLIST: commit with only the changes present in the lore patch (modify _notify(), add work queue, add hpd_enable/disable)
    2. QCLINUX: or PENDING: commit with the extra connector_status_unknown filtering logic and any other vendor-specific adaptations
  • If the lore patch itself needs updating to match this implementation, post a v2 to lore.kernel.org first, then update the PR's Link: tag to point to the new revision.

  • Update the commit message to explain why the PR differs from lore (e.g., "Adapted to qcom-next tree where aux-hpd-bridge has been refactored to split notify functions").

Final Summary

  1. Lore link present: Yes — https://lore.kernel.org/all/20260803-drm-usbdp-preboot-v1-1-2539b362be00@oss.qualcomm.com/
  2. Lore link matches PR commits: No — PR modifies different function (_notify_extra vs _notify), adds extra conditional logic, removes atomic helper hooks, and changes comment wording; these are semantic changes beyond context adaptation
  3. Upstream patch status: ⏳ Decision Pending — posted 2026-08-03, only AI bot reply, no maintainer decision yet
  4. PR present in qcom-next/topics: Partial — integration_presence_report.md shows "partial - subject or partial tree evidence found, but full change was not verified" (1/1 commits partial)

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: 8d5dbc1b17adf8fe86a41adcda686785e73f5414
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 [PATCH] FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status partial - subject or partial tree evidence found, but full change was not verified missing - no subject, patch-id, or full tree-content match found partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

@qlijarvis

Copy link
Copy Markdown

PR #1631 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch Automerge conflict - never reached checker
dt-binding-check Automerge conflict - never reached checker
dtb-check Automerge conflict - never reached checker
sparse-check Automerge conflict - never reached checker
check-uapi-headers Automerge conflict - never reached checker
check-patch-compliance Git fetch failure (HTTP 503)
tag-check Subject has valid FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1631 - FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_enable
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/30800264652

Checker Result Summary
checkpatch Automerge conflict - never reached checker
dt-binding-check Automerge conflict - never reached checker
dtb-check Automerge conflict - never reached checker
sparse-check Automerge conflict - never reached checker
check-uapi-headers Automerge conflict - never reached checker
check-patch-compliance Git fetch failure (HTTP 503)
tag-check Subject has valid FROMLIST: prefix

❌ CI Infrastructure Failures

Root cause: All checker jobs failed during the pre-check automerge phase, not due to patch defects.

Failure details:

1. Automerge conflict (5 checkers):

CONFLICT (add/add): Merge conflict in drivers/gpu/drm/bridge/lontium-lt9611c.c
Automatic merge failed; fix conflicts and then commit the result.
automerge returned non-zero; check logs for conflicts
##[error]Process completed with exit code 1.

The CI workflow attempts to merge the PR branch (topic/tech/mm/drm) with the baseline (qcom-next) before running checkers. This merge encountered a conflict in drivers/gpu/drm/bridge/lontium-lt9611c.c — a file that is not modified by this PR (PR only touches drivers/gpu/drm/bridge/aux-hpd-bridge.c).

This is a pre-existing integration conflict between the topic branch and qcom-next, unrelated to PR #1631.

2. Git fetch failure (check-patch-compliance):

error: RPC failed; HTTP 503 curl 22 The requested URL returned error: 503
fatal: expected flush after ref listing
##[error]Process completed with exit code 128.

GitHub API returned HTTP 503 (Service Unavailable) during git fetch origin qcom-next. This is a transient network/service issue.

Fix:

For the automerge conflict:

For the HTTP 503 error:

  • Re-trigger the CI workflow. This is a transient GitHub service issue.

Reproduce locally:

To verify the automerge conflict independently:

git clone https://github.com/qualcomm-linux/kernel.git
cd kernel
git fetch origin qcom-next
git checkout qcom-next
git fetch https://github.com/qualcomm-linux/kernel-topics.git topic/tech/mm/drm
git merge FETCH_HEAD
# Conflict will appear in lontium-lt9611c.c

✅ Patch Quality (from manual inspection)

Since the checkers never ran, I inspected the patch directly:

Commit: fe51d83f4ef2 - "FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_enable"

  • Subject prefix: Valid FROMLIST: prefix present
  • Link trailer: Contains Link: https://lore.kernel.org/all/20260803-drm-usbdp-preboot-v1-1-2539b362be00@oss.qualcomm.com/
  • Signed-off-by: Present
  • Fixes tag: Present (Fixes: e560518a6c2e)
  • Code changes: Single file modified (drivers/gpu/drm/bridge/aux-hpd-bridge.c), adds HPD status caching and replay logic
  • Style: No obvious checkpatch violations visible in the diff

Verdict

CI failure is not caused by this PR. The patch itself appears well-formed with proper upstream linkage and commit message formatting.

Action required: Re-trigger CI after the topic branch maintainer resolves the lontium-lt9611c.c conflict between topic/tech/mm/drm and qcom-next.

The patch is ready for review from a code quality perspective — the CI infrastructure issues are blocking validation, not patch defects.

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