Re: [PATCH 1/5] drm/bridge: allow hpd_notify() to suppress connector hotplug events

From: Dmitry Baryshkov

Date: Mon Aug 17 2026 - 23:02:05 EST


On Mon, Aug 17, 2026 at 04:01:41PM +0800, Yongxing Mou wrote:
>
>
> On 7/12/2026 6:21 PM, Dmitry Baryshkov wrote:
> > On Mon, Jun 29, 2026 at 10:48:03PM +0800, Yongxing Mou wrote:
> > > 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.
> >
> Hi, thanks for reviwing those patches.
> 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.

> Second, 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?

> > > 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...
> >
> You are right, I will reorganize the patches in next patchset.
> > >
> > > 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(-)
> >
>

--
With best wishes
Dmitry