FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_e… - #1631
FROMLIST: drm/bridge: aux-hpd-bridge: replay last HPD status on hpd_e…#1631YongxingMou wants to merge 1 commit into
Conversation
…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/
🔨 Build Failure Analysis — PR #1631PR: #1631
Verdict0 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 ( 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1631PR: #1631
VerdictThis is not a compilation failure. The build failed during the automerge/integration step due to a pre-existing conflict in 📎 Detailed analysis: Full report |
PR #1631 — validate-patchPR: #1631
Final Summary
|
PR #1631 — checker-log-analyzerPR: #1631
Detailed report: Full report
|
…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