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

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 <[email protected]>
> > > ---
> > >   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