[PATCH 0/2] drm/bridge: display-connector: detect DP state if cable is plugged on boot

[PATCH 0/2] drm/bridge: display-connector: detect DP state if cable is plugged on boot

[Dmitry Baryshkov]

Unlike the USB-C AltMode handling and unlike the DP controller handling
the HPD on its own, if the display-connector is being used to handle the
HPD pin, DP controller might not be able to get either the HPD
notification nor detect the cable state if the cable is plugged in
before the system has booted.

Make the display-connector send the HPD notifications during system
startup for DisplayPort connectors.

It's typically not a problem for other types of display connectors since
there is no special procedure to detect if the monitor is actually
plugged in or not.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Dmitry Baryshkov (2):
      drm/bridge: display-connector: don't autoenable HPD IRQ
      drm/bridge: display-connector: trigger initial HPD event for DP

 drivers/gpu/drm/bridge/display-connector.c | 36 ++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
---
base-commit: 5c9e55fecf9365890c64f14761a80f9413a3b1d1
change-id: 20260314-dp-connector-hpd-f069e66bc6af

Best regards,
-- 
With best wishes
Dmitry

[PATCH 1/2] drm/bridge: display-connector: don't autoenable HPD IRQ

[Dmitry Baryshkov]

If HPD IRQ is enabled in the display_connector's probe, it can be
triggered too early, before the DRM connector is completely setup. Use
the enable_hpd / disable_hpd callbacks to control enablement of the HPD
IRQ.

Fixes: 0c275c30176b ("drm/bridge: Add bridge driver for display connectors")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/gpu/drm/bridge/display-connector.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c
index 16c0631adeb1..6bb1134f75c3 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -87,6 +87,20 @@ display_connector_bridge_detect(struct drm_bridge *bridge, struct drm_connector
 	return display_connector_detect(bridge);
 }
 
+static void display_connector_hpd_enable(struct drm_bridge *bridge)
+{
+	struct display_connector *conn = to_display_connector(bridge);
+
+	enable_irq(conn->hpd_irq);
+}
+
+static void display_connector_hpd_disable(struct drm_bridge *bridge)
+{
+	struct display_connector *conn = to_display_connector(bridge);
+
+	disable_irq(conn->hpd_irq);
+}
+
 static const struct drm_edid *display_connector_edid_read(struct drm_bridge *bridge,
 							  struct drm_connector *connector)
 {
@@ -178,6 +192,8 @@ static u32 *display_connector_get_input_bus_fmts(struct drm_bridge *bridge,
 static const struct drm_bridge_funcs display_connector_bridge_funcs = {
 	.attach = display_connector_attach,
 	.detect = display_connector_bridge_detect,
+	.hpd_enable = display_connector_hpd_enable,
+	.hpd_disable = display_connector_hpd_disable,
 	.edid_read = display_connector_edid_read,
 	.atomic_get_output_bus_fmts = display_connector_get_output_bus_fmts,
 	.atomic_get_input_bus_fmts = display_connector_get_input_bus_fmts,
@@ -307,6 +323,7 @@ static int display_connector_probe(struct platform_device *pdev)
 						NULL, display_connector_hpd_irq,
 						IRQF_TRIGGER_RISING |
 						IRQF_TRIGGER_FALLING |
+						IRQF_NO_AUTOEN |
 						IRQF_ONESHOT,
 						"HPD", conn);
 		if (ret) {

-- 
2.47.3

Claude review: drm/bridge: display-connector: don't autoenable HPD IRQ

[Claude Code Review Bot]

Patch Review

This patch adds `IRQF_NO_AUTOEN` to the IRQ request flags and implements `hpd_enable`/`hpd_disable` callbacks that call `enable_irq()`/`disable_irq()`.

**Looks correct.** The `hpd_enable`/`hpd_disable` callbacks are the intended mechanism per the `drm_bridge_funcs` documentation: bridges that set `DRM_BRIDGE_OP_HPD` should implement these. Using `IRQF_NO_AUTOEN` prevents the IRQ from firing before the DRM connector is fully set up, which is the bug being fixed.

One minor observation:

- The `hpd_enable`/`hpd_disable` callbacks are unconditionally wired into `display_connector_bridge_funcs`, but `conn->hpd_irq` is only valid (>= 0) when an HPD GPIO with IRQ capability was found. If `hpd_irq` is `-EINVAL` (no HPD GPIO, or IRQ request failed), calling `enable_irq(-EINVAL)` / `disable_irq(-EINVAL)` would be invalid. However, in practice, the `hpd_enable` callback is only invoked by `drm_bridge_hpd_enable()` when `DRM_BRIDGE_OP_HPD` is set in `bridge->ops`, and `DRM_BRIDGE_OP_HPD` is only set when `conn->hpd_irq >= 0`. So this is safe by design, but adding a guard like:

```c
if (conn->hpd_irq < 0)
    return;
```

would be defensive and make the contract clearer. Not strictly necessary though.

**Fixes tag looks appropriate** – the original commit introduced the auto-enabled IRQ.

---
Generated by Claude Code Patch Reviewer

[PATCH 2/2] drm/bridge: display-connector: trigger initial HPD event for DP

[Dmitry Baryshkov]

If the DisplayPort drivers use display-connector for the HPD detection,
the internal HPD state machine might be not active and thus the hardware
might be not able to handle cable detection correctly. Instead it will
depend on the externall HPD notifications to set the cable state,
bypassing the internal HPD state machine (for example this is the case
for the msm DP driver).

However if the cable has been plugged before the HPD IRQ has been
enabled, there will be no HPD event coming. The drivers might fail
detection in such a case. Trigger the HPD notification after enabling
the HPD IRQ, propagating the cable insertion state.

Fixes: 2e2bf3a5584d ("drm/bridge: display-connector: add DP support")
Reported-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/gpu/drm/bridge/display-connector.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c
index 6bb1134f75c3..f7a5bfd9c075 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -12,6 +12,7 @@
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/consumer.h>
+#include <linux/workqueue.h>
 
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_bridge.h>
@@ -25,6 +26,8 @@ struct display_connector {
 
 	struct regulator	*supply;
 	struct gpio_desc	*ddc_en;
+
+	struct work_struct	hpd_work;
 };
 
 static inline struct display_connector *
@@ -92,15 +95,29 @@ static void display_connector_hpd_enable(struct drm_bridge *bridge)
 	struct display_connector *conn = to_display_connector(bridge);
 
 	enable_irq(conn->hpd_irq);
+
+	if (conn->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
+		schedule_work(&conn->hpd_work);
 }
 
 static void display_connector_hpd_disable(struct drm_bridge *bridge)
 {
 	struct display_connector *conn = to_display_connector(bridge);
 
+	if (conn->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
+		cancel_work_sync(&conn->hpd_work);
+
 	disable_irq(conn->hpd_irq);
 }
 
+static void display_connector_hpd_work(struct work_struct *work)
+{
+	struct display_connector *conn = container_of(work, struct display_connector, hpd_work);
+	struct drm_bridge *bridge = &conn->bridge;
+
+	drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
+}
+
 static const struct drm_edid *display_connector_edid_read(struct drm_bridge *bridge,
 							  struct drm_connector *connector)
 {
@@ -395,6 +412,8 @@ static int display_connector_probe(struct platform_device *pdev)
 		conn->bridge.ops |= DRM_BRIDGE_OP_DETECT;
 	if (conn->hpd_irq >= 0)
 		conn->bridge.ops |= DRM_BRIDGE_OP_HPD;
+	if (conn->hpd_irq >= 0 && type == DRM_MODE_CONNECTOR_DisplayPort)
+		INIT_WORK(&conn->hpd_work, display_connector_hpd_work);
 
 	dev_dbg(&pdev->dev,
 		"Found %s display connector '%s' %s DDC bus and %s HPD GPIO (ops 0x%x)\n",

-- 
2.47.3

Claude review: drm/bridge: display-connector: trigger initial HPD event for DP

[Claude Code Review Bot]

Patch Review

This patch adds a `work_struct` to schedule an initial HPD notification when `hpd_enable` is called for DP connectors. On `hpd_disable`, it cancels the work with `cancel_work_sync`.

**The use of a workqueue is appropriate** because `hpd_enable` is called under `bridge->hpd_mutex` (see `drm_bridge_hpd_enable()` in `drm_bridge.c`), and `drm_bridge_hpd_notify()` also takes `hpd_mutex`. Calling `drm_bridge_hpd_notify()` directly from `hpd_enable` would deadlock. The workqueue defers the notification outside the mutex.

**Observations:**

1. **`INIT_WORK` is conditional but callbacks are not.** The `INIT_WORK` call at line 661 is guarded by `conn->hpd_irq >= 0 && type == DRM_MODE_CONNECTOR_DisplayPort`, and the `schedule_work`/`cancel_work_sync` calls are guarded by `conn->bridge.type == DRM_MODE_CONNECTOR_DisplayPort`. This is consistent – DP connectors without HPD IRQ won't reach `hpd_enable` (since `DRM_BRIDGE_OP_HPD` won't be set), and non-DP connectors won't touch the work. However, if `INIT_WORK` is never called, the `work_struct` is zero-initialized (from `devm_drm_bridge_alloc` which uses `devm_kzalloc`), and `cancel_work_sync` on an uninitialized (zero) `work_struct` is technically undefined behavior. In practice, this path is unreachable for non-DP connectors because the `bridge.type` check guards it. Still, it would be slightly cleaner to always call `INIT_WORK` when `hpd_irq >= 0`, removing the type check from the init path, since the `schedule_work` is already guarded by the DP type check.

2. **Race between work and disable.** The ordering in `hpd_disable` is: `cancel_work_sync` first, then `disable_irq`. This is correct – it ensures the synthetic HPD work is cancelled before the IRQ is disabled. If the order were reversed, a pending work item could call `display_connector_detect` → `gpiod_get_value_cansleep` after the IRQ was disabled, which would be fine functionally but inconsistent.

3. **No cleanup on remove.** The `display_connector_remove` function doesn't call `cancel_work_sync`. This should be fine because `drm_bridge_hpd_disable` (and thus `hpd_disable`) is called during connector cleanup before bridge removal, so the work should already be cancelled. But it's worth considering whether there's a window where `hpd_enable` was called but `hpd_disable` was not before `remove`. Given the DRM lifecycle, this shouldn't happen.

4. **Minor typo in commit message:** "externall" should be "external".

Overall, this is a well-structured fix for a real problem. The series is correct and ready to merge with perhaps the typo fix in the commit message.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/bridge: display-connector: detect DP state if cable is plugged on boot

[Claude Code Review Bot]

Overall Series Review

Subject: drm/bridge: display-connector: detect DP state if cable is plugged on boot
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patches: 3
Reviewed: 2026-03-16T12:14:39.415482

---

This is a clean, well-motivated 2-patch series from Dmitry Baryshkov fixing a real boot-time HPD detection issue for DisplayPort connectors using the `display-connector` bridge driver. If a DP cable is plugged in before the system boots, there's no rising/falling edge on the HPD GPIO, so no IRQ fires and the DP controller never learns about the connection. The fix is straightforward: (1) defer IRQ enabling to the `hpd_enable` callback, and (2) synthesize an initial HPD notification for DP connectors when HPD is enabled.

The approach is sound and the patches are correctly ordered. I have a few observations below.

---
Generated by Claude Code Patch Reviewer