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

[Yongxing Mou]

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.

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.

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.

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
of spurious IRQ_HPDs during MST enable ends up amplified across the
whole card.

> > 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(-)