Re: [PATCH 1/5] drm/bridge: allow hpd_notify() to suppress connector hotplug events
Yongxing Mou <[email protected]>
| Newsgroups | org.infradead.lists.linux-amlogic,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 <[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(-) > _______________________________________________ linux-amlogic mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-amlogic