Re: [PATCH 1/5] drm/bridge: allow hpd_notify() to suppress connector hotplug events
From: Yongxing Mou
Date: Wed Sep 16 2026 - 02:38:58 EST
On 9/8/2026 9:10 PM, Dmitry Baryshkov wrote:
On Mon, Aug 24, 2026 at 11:15:44AM +0800, Yongxing Mou wrote:I’m not objecting to the single-API approach. I’m just not completely sure yet how it simplifies the driver-side handling, since the driver may still need to deal with HPD and IRQ_HPD arriving at around the same time, or IRQ_HPD arriving when the link is no longer present.
On 8/21/2026 3:20 PM, Yongxing Mou wrote:
Sorry, after thinking about it again, this idea is not fundamentally
On 8/18/2026 11:01 AM, Dmitry Baryshkov wrote:
On Mon, Aug 17, 2026 at 04:01:41PM +0800, Yongxing Mou wrote:The DRM API should simply pass both long HPD IRQs and short HPD IRQs to
On 7/12/2026 6:21 PM, Dmitry Baryshkov wrote:
On Mon, Jun 29, 2026 at 10:48:03PM +0800, Yongxing Mou wrote:Hi, thanks for reviwing those patches.
The bridge connector framework currently invokes all bridge
hpd_notify() callbacks and unconditionally emits a connector hotplug
event afterwards.
However, not every HPD notification requires a userspace
hotplug event.
In particular, DP MST bridges may use hpd_notify() to
propagate HPD and
IRQ notifications through the bridge chain while the actual hotplug
handling is performed by the DRM DP MST core. Connector creation,
removal and userspace hotplug events are already managed by the MST
topology framework.
Allow hpd_notify() implementations to suppress the bridge connector
hotplug event by introducing a bool *send_hotplug parameter. Drivers
can clear this flag when HPD processing should not result in a
connector hotplug notification.
Why? Worst case the kernel receives another hotplug notification which
gets ignored by the driver.
Let me try to explain the motivation.
Semantically, IRQ_HPD is just an IRQ notification, not a
connection state
transition, and shouldn't be turned into a userspace hotplug in
the first
place. However, drm_bridge_connector_handle_hpd() currently calls
drm_kms_helper_connector_hotplug_event() unconditionally after
processing
the event, so every IRQ_HPD ends up reported as a hotplug.
What if the IRQ_HPD is delivered together with the first HPD event (for
example because of the TCPM processing those events)? See the mechanism
in the displayport.c AltMode driver.
the driver as they are, and let the driver decide how to handle them.
Based on my review of the implementations from all three vendors, when
long and short HPD IRQs occur simultaneously, the long HPD IRQ is always
handled first, followed by the short HPD IRQ.
I have another thought regarding the current DRM API. Could we have the
DRM layer pass only the HPD event information (long IRQ and/or short
IRQ) instead of connector status, and leave all handling decisions to
the driver? The DRM core would simply report LONG_HPD | SHORT_HPD, and
each driver could decide how to process the event. This seems like a
pattern that could be shared across different drivers.
This is just my current understanding. Please let me know if I've missed
anything or got something wrong. Thanks.
different from your current approach. In the end, we still need to handle
HPD state transitions in the driver. It seems my previous suggestion does
not really simplify the problem, so I apologize if it has caused any
confusion or misled the discussion.
No worries.
I'm currently stuck between two ideas: continue pursuing the current
"single API for both events" or implement new "two API for two events".
I think that the second might sound more plausible, but in the end it
would complicate drivers much more, because now they'd need to handle
synchronisation issues on their own.
If we start from the DP AltMode, we have a single state word which
specifies exactly, 'HPD pin status' and 'was the IRQ_HPD captured'. Our
DP controller also has about the same status word: the connected status
and the IRQ_HPD pulse. Which (for me) points out that the single API is
a correct way to handle the HPD/IRQ_HPD.
For reference, Intel, AMD, and Nouveau appear to process HPD state changes and IRQ_HPD handling in separate workers. I’m not sure whether that is relevant here, but I thought it might be useful information.
Now, coming to the drivers/userspace side. Let's leave the MST storyAgree.
aside for a moment. For the DP branch devices connected to the USB-C the
AltMode will always report 'connected', but the DP's detect callback
would rightfully report 'disconnected' if there is no actual monitor.
The kernel should do it's best in this case and report that the
connector is disconnected without any interim states. I think we do it
already. The compositor should do it's job and skip full scene
evaluation of the disconnected connector gets disconnected again.
Event filtering. Historically, drm_bridge_connector was trying to filterYes, i want to update a new verison to do this and update the 'HPD come with irq' case. One question, do you have any rough timeline in mind for the next revision of the IRQ series?
HPD event. We had to remove it because for the DP prefiltering doesn't
work. This might have left the gap, which now needs to be filled. The
bridge_connector uses drm_kms_helper_connector_hotplug_event() which
just reports the even to the userspace. Consider reworking
drm_bridge_connector_handle_hpd() to behave more like
drm_connector_helper_hpd_irq_event(). Execute hpd_notify under the same
mutex lock, capture if the status has actually changed afterwards and
report it to userspace only if there was a change.
The driver revalidates the actual connector state, and a hotplug eventSecond, MST IRQ_HPD is level-sticky -- as long as the ACK has not been
cleared, the IRQ keeps firing repeatedly, and MST bring-up (link
training
/ MST enable handshake) itself generates a burst of IRQ_HPDs. So this is
not about "one extra hotplug", but about a burst of them within a short
window.
Ok, if it is level-sticky, it should be handled as such.
Every one of those hotplugs is delivered to userspace via udev and
prompts the compositor to re-probe the connector. In the window before
mst_active is set, that re-probe walks back into msm_dp_bridge_detect()
and performs aux/DPCD accesses, racing with the MST enable flow.
If there is a race, the path needs to have a lock, preventing concurrent
access. Otherwise, you are just shortening the window instead of solving
the problem.
The amplification also isn't limited to a single connector: on Hamoa
there are 4 connectors (3x DP + eDP), and we observe that a hotplug on
any one connector causes the compositor to re-query all 4. So this burst
Please fix the compositor, it should not need to query all 4 connectors
if the HPD event came from the single one.
of spurious IRQ_HPDs during MST enable ends up amplified across the
whole card.
How do i915, amdgpu and nouveau respond to IRQ_HPD? When do they send
the HPD event to the userspace?
is triggered only when an actual connector state change or a link status
change is detected.
You are right, I will reorganize the patches in next patchset.A NULL pointer indicates that hotplug suppression is not supported by
the caller, such as the connector detect polling path.
And nothing in this patch makes any use of it. I'd say, it's
questionable addition. Let me check other patches...
Signed-off-by: Yongxing Mou <yongxing.mou@xxxxxxxxxxxxxxxx>
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 ++-
drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++------
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_display.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 ++-
include/drm/drm_bridge.h | 3 ++-
7 files changed, 21 insertions(+), 12 deletions(-)