| Message ID | 20260518180206.2480119-19-jonas@kwiboo.se (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-23519-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114]) by mxe881.netcup.net (Postfix) with ESMTPS id 40D301C0029 for <noreply@patchwork.local>; Mon, 18 May 2026 20:06:50 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=kwiboo.se; spf=pass (sender IP is 172.105.105.114) smtp.mailfrom=linux-sunxi+bounces-23519-noreply=patchwork.local@lists.linux.dev smtp.helo=tor.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.105.105.114 as permitted sender) client-ip=172.105.105.114; envelope-from=linux-sunxi+bounces-23519-noreply=patchwork.local@lists.linux.dev; helo=tor.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id D17433069041 for <noreply@patchwork.local>; Mon, 18 May 2026 18:03:44 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A9D6238911F; Mon, 18 May 2026 18:03:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kwiboo.se header.i=@kwiboo.se header.b="GpxA/ofT" X-Original-To: linux-sunxi@lists.linux.dev Received: from smtp.forwardemail.net (smtp.forwardemail.net [121.127.44.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBEA2385506 for <linux-sunxi@lists.linux.dev>; Mon, 18 May 2026 18:03:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=121.127.44.66 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779127419; cv=none; b=CqX5hC0GkVvQcV3OTZzsyCqs+NNdzaHrH9qONXbUvHeo7OrykcGOXplCI0yzb3OpvMBz2WRZ40at/auFUDnmWnOb6iM2kAdEwpPlbNAiIfAISXvFNGetMKz++0v7La2cajxjx8rorrQmWFZ580rvBMv6h8nMFt9IrAvkg02MKCM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779127419; c=relaxed/simple; bh=o5jV3jx0mJ5mgZ4jLLFGXoPXS/YTfsilvhksT+Tc3Nc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=j50T9PAsAnli7dCV3Vkn+zF2iq/7nI6ipV9Cul+1lXuJsBqQL6rMQ0VhmqQO6qNgfHKPIAfJCqhoYKPeQ0G70y5g5uk7WlUQ93tRkSCS/RyLCQ8kO+c0wwq4qyg/fVuRkbF1jgvaDn2nP27T2Tsog5B+oEbMnTdtdpNPTKO8mnk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=kwiboo.se; spf=pass smtp.mailfrom=fe-bounces.kwiboo.se; dkim=pass (2048-bit key) header.d=kwiboo.se header.i=@kwiboo.se header.b=GpxA/ofT; arc=none smtp.client-ip=121.127.44.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=kwiboo.se Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fe-bounces.kwiboo.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kwiboo.se; h=Content-Transfer-Encoding: MIME-Version: References: In-Reply-To: Message-ID: Date: Subject: Cc: To: From; q=dns/txt; s=fe-e1b5cab7be; t=1779127416; bh=/hZiUkfIGiN8nQnQfqNQPTR4hVnEkYNLDTXPMKl0d0I=; b=GpxA/ofTPszh8XDD2h1fr0Ya2OjQ5Mzt/ZpGrDymGCbcWWJJlHWdcGfA9D/qywIcftvOb99lf XMPsq+MhfSzld/em66LRRUYJa7gfL2Sujx5q8ubles0t9oMTosuxefxEfkxRxHQnN8QxffPDXre 8uyZpNXUmDuHVOjLMWQGHQt56WZ/9MnoS82IdppxejCI/glUMVe7FMMj4bQAOYPr5G3fbeo0YG2 g+q8VWGzmmI4sGEzZdJaXT/+7weSp59CRvJO8mpGiK1ZTaTpLLSG6xW6AGFtHcc76dFOXbqQSYt QXCEinIMIwNBQOCDpKBhhlOeOOtqzBBsYWJ38OF5yjkw== X-Forward-Email-ID: 6a0b5472b84dbc72d2274f8f X-Forward-Email-Sender: rfc822; jonas@kwiboo.se, smtp.forwardemail.net, 121.127.44.66 X-Forward-Email-Version: 2.8.12 X-Forward-Email-Website: https://forwardemail.net X-Complaints-To: abuse@forwardemail.net X-Report-Abuse: abuse@forwardemail.net X-Report-Abuse-To: abuse@forwardemail.net From: Jonas Karlman <jonas@kwiboo.se> To: Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org>, Heiko Stuebner <heiko@sntech.de>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Luca Ceresoli <luca.ceresoli@bootlin.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch> Cc: Liu Ying <victor.liu@nxp.com>, Sandy Huang <hjc@rock-chips.com>, Andy Yan <andy.yan@rock-chips.com>, Chen-Yu Tsai <wens@kernel.org>, Christian Hewitt <christianshewitt@gmail.com>, Diederik de Haas <diederik@cknow-tech.com>, Nicolas Frattaroli <nicolas.frattaroli@collabora.com>, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-sunxi@lists.linux.dev, imx@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v7 18/23] drm: bridge: dw_hdmi: Drop call to drm_bridge_hpd_notify() Date: Mon, 18 May 2026 18:01:54 +0000 Message-ID: <20260518180206.2480119-19-jonas@kwiboo.se> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260518180206.2480119-1-jonas@kwiboo.se> References: <20260518180206.2480119-1-jonas@kwiboo.se> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
|
|
Commit Message
Jonas Karlman
May 18, 2026, 6:01 p.m. UTC
The use of calls to both drm_helper_hpd_irq_event() and
drm_bridge_hpd_notify() from the HPD IRQ handler may cause multiple
hotplug uevents and modesets when the bridge connector is used.
Use of drm_helper_hpd_irq_event() cause the internal DRM function
check_connector_changed() to be called, which in turn calls the
connector detect()/force() funcs to detect any connection status or
epoch changes, and when changed trigger a hotplug uevent. This also
help ensure that EDID and CEC phys addr is updated.
If only a call drm_bridge_hpd_notify() would be used, a custom connector
status/EDID change detection logic needs to be implemented, to fully
match what check_connector_changed() already provides.
The bridge connector detect() func also ensures that any hpd_notify()
funcs are called for all bridges in the chain, so there is not really
any need to have a call to drm_bridge_hpd_notify() here.
With both calls there is two hotplug uevents, two modesets and a total
of four .hpd_notify() calls (using a bridge connector):
dw_hdmi_irq(): EVENT=plugout
drm_helper_hpd_irq_event():
dw_hdmi_bridge_hpd_notify(status=2)
[drm:check_connector_changed] [CONNECTOR:46:HDMI-A-1] status updated from connected to disconnected
[drm:check_connector_changed] [CONNECTOR:46:HDMI-A-1] Changed epoch counter 1 => 2
[drm:drm_sysfs_connector_hotplug_event] [CONNECTOR:46:HDMI-A-1] generating connector hotplug event
drm_client_hotplug():
[drm:drm_fb_helper_hotplug_event]
[drm:drm_client_modeset_probe]
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-1]
dw_hdmi_bridge_hpd_notify(status=2)
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-1] disconnected
[drm:drm_edid_connector_update] [CONNECTOR:46:HDMI-A-1] EDID changed, epoch counter 3
[drm:drm_client_modeset_probe] No connectors reported connected with modes
[drm:drm_client_modeset_probe] [CONNECTOR:46:HDMI-A-1] enabled? no
[drm:drm_client_firmware_config.isra.0] Not using firmware configuration
[drm:drm_client_modeset_probe] picking CRTCs for 3840x2160 config
[drm:drm_client_hotplug] fbdev: ret=0
drm_bridge_hpd_notify():
dw_hdmi_bridge_hpd_notify(status=2)
[drm:drm_sysfs_connector_hotplug_event] [CONNECTOR:46:HDMI-A-1] generating connector hotplug event
drm_client_hotplug():
[drm:drm_fb_helper_hotplug_event]
[drm:drm_client_modeset_probe]
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-1]
dw_hdmi_bridge_hpd_notify(status=2)
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-1] disconnected
[drm:drm_client_modeset_probe] No connectors reported connected with modes
[drm:drm_client_modeset_probe] [CONNECTOR:46:HDMI-A-1] enabled? no
[drm:drm_client_firmware_config.isra.0] Not using firmware configuration
[drm:drm_client_modeset_probe] picking CRTCs for 3840x2160 config
[drm:drm_client_hotplug] fbdev: ret=0
Change to only call drm_helper_hpd_irq_event() from HPD IRQ handler to
ensure that only one hotplug uevent is sent to userspace when connection
status or EDID changes.
With only a call the drm_helper_hpd_irq_event() there is only a single
hotplug uevent and only two .hpd_notify() calls:
dw_hdmi_irq(): EVENT=plugout
drm_helper_hpd_irq_event():
dw_hdmi_bridge_hpd_notify(status=2)
[drm:check_connector_changed] [CONNECTOR:46:HDMI-A-1] status updated from connected to disconnected
[drm:check_connector_changed] [CONNECTOR:46:HDMI-A-1] Changed epoch counter 1 => 2
[drm:drm_sysfs_connector_hotplug_event] [CONNECTOR:46:HDMI-A-1] generating connector hotplug event
drm_client_hotplug():
[drm:drm_fb_helper_hotplug_event]
[drm:drm_client_modeset_probe]
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-1]
dw_hdmi_bridge_hpd_notify(status=2)
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:HDMI-A-1] disconnected
[drm:drm_edid_connector_update] [CONNECTOR:46:HDMI-A-1] EDID changed, epoch counter 3
[drm:drm_client_modeset_probe] No connectors reported connected with modes
[drm:drm_client_modeset_probe] [CONNECTOR:46:HDMI-A-1] enabled? no
[drm:drm_client_firmware_config.isra.0] Not using firmware configuration
[drm:drm_client_modeset_probe] picking CRTCs for 3840x2160 config
[drm:drm_client_hotplug] fbdev: ret=0
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # Rock64, RockPro64, Quartz64-B
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
v7: No change
v6: Drop the call from IRQ handler instead, prior to use of a HPD
delayed work to avoid a possible deadlock with use of sync() calls
in the bridge hpd_disable() ops,
Update commit message,
Collect t-b tag
v5: New patch
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Comments
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Removing `drm_bridge_hpd_notify()` violates the `DRM_BRIDGE_OP_HPD` contract and replaces targeted bridge HPD notification with an inefficient global device poll. -- commit f2225f0de66ea8205ddbd49531c0c402dab0c72b Author: Jonas Karlman <jonas@kwiboo.se> drm: bridge: dw_hdmi: Drop call to drm_bridge_hpd_notify() This commit removes the call to drm_bridge_hpd_notify() from the dw_hdmi hotplug interrupt handler. It relies instead solely on drm_helper_hpd_irq_event() to trigger hotplug events in order to prevent multiple hotplug uevents and redundant modeset probes. > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 5dacb8a99715b..8afc9d2401214 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -3101,10 +3101,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) > status == connector_status_connected ? > "plugin" : "plugout"); > > - if (hdmi->bridge.dev) { > + if (hdmi->bridge.dev) > drm_helper_hpd_irq_event(hdmi->bridge.dev); > - drm_bridge_hpd_notify(&hdmi->bridge, status); > - } Does removing the drm_bridge_hpd_notify() call violate the DRM_BRIDGE_OP_HPD API contract? The dw_hdmi driver is registered with the DRM_BRIDGE_OP_HPD flag, which typically requires the driver to call drm_bridge_hpd_notify() on status changes so that registered callbacks like drm_bridge_connector_hpd_cb() are properly invoked. By relying solely on drm_helper_hpd_irq_event(), doesn't this replace the targeted bridge HPD notification with a global device poll? Looking at drm_helper_hpd_irq_event() in drm_probe_helper.c, it acquires dev->mode_config.mutex and iterates over all connectors on the DRM device, calling their detect() functions synchronously. In multi-display systems (for example, HDMI alongside eDP or DSI), will an HDMI hotplug interrupt now trigger slow DDC/I2C/AUX probes on those completely unrelated connectors? While later patches or discussions might address using delayed_work to debounce hotplug events to avoid mutex deadlocks, could the driver resolve those locking issues without bypassing the bridge framework's targeted notification mechanism and forcing an inefficient global poll?
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 5dacb8a99715..8afc9d240121 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -3101,10 +3101,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) status == connector_status_connected ? "plugin" : "plugout"); - if (hdmi->bridge.dev) { + if (hdmi->bridge.dev) drm_helper_hpd_irq_event(hdmi->bridge.dev); - drm_bridge_hpd_notify(&hdmi->bridge, status); - } } hdmi_writeb(hdmi, intr_stat, HDMI_IH_PHY_STAT0);