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

[Yongxing Mou <yongxing.mou@oss.qualcomm.com>]

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@oss.qualcomm.com>
>> ---
>>   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(-)
> 


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic