On 10/21/2026 3:34 PM, Luca Ceresoli wrote:
Hello Yongxing, Dmitry,
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: e560518a6c2e ("drm/bridge: implement generic DP HPD bridge")
Signed-off-by: Yongxing Mou <[email protected]>
Is this patch still current?
It looks mostly OK at quick glance, but there are issues reported by
sashiko which look valid to me. If you could reply to those remarks, either
confirming the issue or explaining why it isn't, it would help reviewing.
Hi, thanks for reminder, will apply AI commenst later and post V2.>
@Dmitry: I'm not familiar with this code, do you have any comment on this
patch?
Luca
