Skip to contentSkip to conversation

Add no-hpd property to the cadence bridge

PATCH Superseded Yashas D 4 participants 10 messages Jul 28 – Aug 2

Subsystems (4)
Device tree bindings DRM drivers DRM misc DRM drivers for bridge chips

v5 of 7 Superseded Latest is v7 →

lore
Share & tools
lore

Yashas D

author
#0 lore raw

v5 cover Add no-hpd property to the cadence bridge

This series adds 'no-hpd' device tree property support to the Cadence MHDP8546 bridge driver for boards where the HPD line cannot be used for hotplug detection.

On TI J721S2 EVMs, the HPD signal is routed to SoC pin AA24 (MCASP1_ACLKX/DP0_HPD). This pin is muxed with the McASP1 audio bit clock; selecting DP0_HPD breaks audio. There is no alternative pin carrying the HPD signal which makes it impossible to use HPD without loosing the audio capabilities.

When 'no-hpd' is set, DRM_BRIDGE_OP_HPD is omitted so the framework falls back to polling .detect() every ~10 seconds. Monitor presence is determined via AUX DPCD reads instead of firmware HPD status registers. The .detect() callback drives cdns_mhdp_update_link_status() on each poll to keep mhdp->plugged current. At attach time, the driver waits for firmware to be ready before performing the initial AUX poll since no interrupt will trigger it.

Changes since v4:
- Corrected the dt-binding Subject

Link to v4: https://lore.kernel.org/all/[email protected]/

Rahul T R (2):
dt-bindings: display: bridge: cdns,mhdp8546: Add no-hpd property to
the cadence bridge
drm: bridge: cdns-mhdp8546: Add no-hpd property

 .../display/bridge/cdns,mhdp8546.yaml         | 17 ++++++
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 58 ++++++++++++++++---
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  1 +
 3 files changed, 69 insertions(+), 7 deletions(-)
Signature · 1 line
2.34.1
author
#1 lore raw

PATCH v5 1/2 dt-bindings: display: bridge: cdns, mhdp8546: Add no-hpd property to the cadence bridge

From: Rahul T R <[email protected]>

The mhdp bridge can work without its HPD pin hooked up to the connector, but the current bridge driver throws an error when hpd line is not connected to the connector. For such cases, we need an indication for no-hpd, using which we can bypass the hpd detection and instead use the auxiliary channels connected to the DP connector to confirm the connection.
So add no-hpd property to the bindings, to disable hpd when not connected or cannot be used for hotplug detection.

Signed-off-by Rahul T R <[email protected]>
Signed-off-by Jayesh Choudhary <[email protected]>
Signed-off-by Yashas D <[email protected]>
---
 .../bindings/display/bridge/cdns,mhdp8546.yaml  | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +17 -0
index c2b369456e4e..f19a4900ecd8 100644
@@ -57,6 +57,23 @@ properties:
   interrupts:
     maxItems: 1
 
+  no-hpd:
+    type: boolean
+    description:
+      Set if the HPD line on the bridge isn't physically connected to the
+      DisplayPort connector or cannot be used for hotplug detection.
+
+      Valid use cases include:
+      - HPD pin not routed to the connector on the PCB
+      - HPD signal muxed with another function (e.g., audio) on the SoC,
+        making it unavailable for hotplug detection
+      - Hardware design where HPD cannot reliably detect monitor presence
+
+      When this property is set, the driver will use auxiliary channel (AUX)
+      DPCD reads to detect monitor connection instead of relying on the
+      hardware HPD signal. Monitor detection will use polling rather than
+      interrupt-driven detection.
+
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
Signature · 1 line
2.34.1
AI review
#2 lore raw

Re: [PATCH v5 1/2] dt-bindings: display: bridge: cdns, mhdp8546: Add no-hpd property to the cadence bridge

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The `no-hpd` property is documented in the device tree bindings but has no corresponding…

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The no-hpd property is documented in the device tree bindings but has no corresponding implementation in the driver. --

--- Patch [1]: [PATCH v5 1/2] dt-bindings: display: bridge: cdns, mhdp8546: Add no-hpd property to the cadence bridge --- commit 4ac60fbbcafba148711703269045306014cd935a
Author: Rahul T R <[email protected]>

dt-bindings: display: bridge: cdns, mhdp8546: Add no-hpd property to the cadence bridge

This commit introduces the no-hpd property to the mhdp8546 device tree bindings. It provides a way to indicate when the hardware HPD line is not available, specifying that the driver should fall back to auxiliary channel DPCD reads for hotplug detection.

Quoted 3 lines
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +0 -0

[ ... ]

Quoted 11 lines
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +7 -0
@@ -57,6 +57,23 @@ properties:
   interrupts:
     maxItems: 1
 
+  no-hpd:
+    type: boolean
+    description:
+      Set if the HPD line on the bridge isn't physically connected to the
+      DisplayPort connector or cannot be used for hotplug detection.
+
+      Valid use cases include:

Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml properties: · line 76

Quoted 10 lines
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +10 -0
+      - HPD pin not routed to the connector on the PCB
+      - HPD signal muxed with another function (e.g., audio) on the SoC,
+        making it unavailable for hotplug detection
+      - Hardware design where HPD cannot reliably detect monitor presence
+
+      When this property is set, the driver will use auxiliary channel (AUX)
+      DPCD reads to detect monitor connection instead of relying on the
+      hardware HPD signal. Monitor detection will use polling rather than
+      interrupt-driven detection.
+

[Severity: Medium]
Is the driver implementation missing for this new property?

The binding documentation states that the driver will use polling rather than interrupt-driven detection when this property is set. However, looking at the driver in cdns_mhdp_probe(), it unconditionally requires hardware HPD operations:

drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:cdns_mhdp_probe() {
	...
	mhdp->bridge.of_node = pdev->dev.of_node;
	mhdp->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
			   DRM_BRIDGE_OP_HPD;
	mhdp->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
	...
}

Does the driver need logic to parse the no-hpd property and conditionally adjust these operations to enable polling instead of enforcing hardware HPD?

Quoted 3 lines
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +0 -0
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
#3 lore raw

Re: [PATCH v5 1/2] dt-bindings: display: bridge: cdns, mhdp8546: Add no-hpd property to the cadence bridge

In reply to Yashas D
Quoted 11 lines · Yashas D

From: Rahul T R <[email protected]>

The mhdp bridge can work without its HPD pin hooked up to the connector, but the current bridge driver throws an error when hpd line is not connected to the connector. For such cases, we need an indication for no-hpd, using which we can bypass the hpd detection and instead use the auxiliary channels connected to the DP connector to confirm the connection.
So add no-hpd property to the bindings, to disable hpd when not connected or cannot be used for hotplug detection.

Quoted 3 lines
Signed-off-by Rahul T R <[email protected]>
Signed-off-by Jayesh Choudhary <[email protected]>
Signed-off-by Yashas D <[email protected]>

I don't get why v5 is sent that way.

Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of people, so fix your workflow. Tools might also fail if you work on some ancient tree (don't, instead use mainline) or work on fork of kernel (don't, instead use mainline). Just use b4 and everything should be fine, although remember about b4 prep --auto-to-cc if you added new patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be tested by automated tooling. Performing review on untested code might be a waste of time.

Please kindly resend and include all necessary To/Cc entries.

Best regards,
Krzysztof

author
#4 lore raw

PATCH v5 2/2 drm: bridge: cdns-mhdp8546: Add no-hpd property

In reply to Yashas D

From: Rahul T R <[email protected]>

Add a 'no-hpd' boolean property to support boards where the HPD line cannot be used for hotplug detection due to hardware limitations.

On TI J721S2 EVMs, the DP0 HPD signal has a MUX conflict with audio functionality. While the HPD pin is physically connected to GPIO0_18, routing it to the SoC requires sacrificing audio capability due to pin muxing constraints. This board-level hardware limitation necessitates an alternative detection mechanism.

When this property is set, the driver uses auxiliary channel (AUX) DPCD reads to detect monitor presence instead of hardware HPD signals. The DRM framework polls the connection status via the .detect() callback, providing hotplug detection without requiring the HPD pin.

Valid use cases:
- HPD pin not routed to connector on PCB
- HPD signal muxed with another function (e.g., audio) on SoC
- Hardware designs where HPD cannot reliably detect monitor presence

Limitations:
- DP "attention" IRQs from sink will not be received
- Hotplug detection latency increases to ~10 seconds (polling interval)

This follows the same pattern as 'no-hpd' in ti-sn65dsi86 and panel-edp bindings, providing consistent semantics across the DRM subsystem.

Signed-off-by Rahul T R <[email protected]>
Signed-off-by Jayesh Choudhary <[email protected]>
Signed-off-by Harikrishna Shenoy <[email protected]>
Signed-off-by Yashas D <[email protected]>
---
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 58 ++++++++++++++++---
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  1 +
 2 files changed, 52 insertions(+), 7 deletions(-)
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +51 -7
index 504a3186ebb3..73d5c718c7db 100644
@@ -53,6 +53,8 @@
 #include "cdns-mhdp8546-hdcp.h"
 #include "cdns-mhdp8546-j721e.h"
 
+static int cdns_mhdp_update_link_status(struct cdns_mhdp_device *mhdp);
+
 static void cdns_mhdp_bridge_hpd_enable(struct drm_bridge *bridge)
 {
 	struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);

@@ -698,7 +700,9 @@ static int cdns_mhdp_fw_activate(const struct firmware *fw,
 	 * MHDP_HW_STOPPED happens only due to driver removal when
 	 * bridge should already be detached.
 	 */
-	cdns_mhdp_bridge_hpd_enable(&mhdp->bridge);
+
+	if (!mhdp->no_hpd)
+		cdns_mhdp_bridge_hpd_enable(&mhdp->bridge);
 
 	spin_unlock(&mhdp->start_lock);
 

@@ -788,9 +792,14 @@ static ssize_t cdns_mhdp_transfer(struct drm_dp_aux *aux,
 		ret = cdns_mhdp_dpcd_read(mhdp, msg->address,
 					  msg->buffer, msg->size);
 		if (ret) {
-			dev_dbg(mhdp->dev,
-				"Failed to read DPCD addr %u\n",
-				msg->address);
+			if (mhdp->no_hpd)
+				dev_dbg(mhdp->dev,
+					"Failed to read DPCD addr %u\n",
+					msg->address);
+			else
+				dev_err(mhdp->dev,
+					"Failed to read DPCD addr %u\n",
+					msg->address);
 
 			return ret;
 		}

@@ -1523,6 +1532,26 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
 
 	spin_unlock(&mhdp->start_lock);
 
+	if (mhdp->no_hpd) {
+		/*
+		 * In no-hpd mode there is no interrupt to signal firmware
+		 * readiness. The firmware loads asynchronously after probe(),
+		 * so we must wait here until the uCPU is running before
+		 * attempting the first AUX channel poll for monitor presence.
+		 */
+		ret = wait_event_timeout(mhdp->fw_load_wq,
+					 mhdp->hw_state == MHDP_HW_READY,
+					 msecs_to_jiffies(100));
+		if (ret == 0) {
+			dev_err(mhdp->dev, "%s: Timeout waiting for fw loading\n",
+				__func__);
+			return -ETIMEDOUT;
+		}
+
+		cdns_mhdp_update_link_status(mhdp);
+		return 0;
+	}
+
 	/* Enable SW event interrupts */
 	if (hw_ready)
 		cdns_mhdp_bridge_hpd_enable(bridge);

@@ -2013,6 +2042,9 @@ cdns_mhdp_bridge_detect(struct drm_bridge *bridge, struct drm_connector *connect
 {
 	struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
 
+	if (mhdp->no_hpd)
+		cdns_mhdp_update_link_status(mhdp);
+
 	return cdns_mhdp_detect(mhdp);
 }
 

@@ -2100,7 +2132,16 @@ static int cdns_mhdp_update_link_status(struct cdns_mhdp_device *mhdp)
 
 	mutex_lock(&mhdp->link_mutex);
 
-	mhdp->plugged = cdns_mhdp_detect_hpd(mhdp, &hpd_pulse);
+	if (mhdp->no_hpd) {
+		ret = drm_dp_dpcd_read_link_status(&mhdp->aux, status);
+		hpd_pulse = false;
+		if (ret < 0)
+			mhdp->plugged = false;
+		else
+			mhdp->plugged = true;
+	} else {
+		mhdp->plugged = cdns_mhdp_detect_hpd(mhdp, &hpd_pulse);
+	}
 
 	if (!mhdp->plugged) {
 		cdns_mhdp_link_down(mhdp);

@@ -2288,6 +2329,8 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
 	mhdp->aux.dev = dev;
 	mhdp->aux.transfer = cdns_mhdp_transfer;
 
+	mhdp->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
+
 	mhdp->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(mhdp->regs)) {
 		dev_err(dev, "Failed to get memory resource\n");

@@ -2360,8 +2403,9 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
 	mhdp->display_fmt.bpc = 8;
 
 	mhdp->bridge.of_node = pdev->dev.of_node;
-	mhdp->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
-			   DRM_BRIDGE_OP_HPD;
+	mhdp->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID;
+	if (!mhdp->no_hpd)
+		mhdp->bridge.ops |= DRM_BRIDGE_OP_HPD;
 	mhdp->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
 
 	ret = phy_init(mhdp->phy);
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h +1 -0
index b53335b0d22c..24ffb732a207 100644
@@ -388,6 +388,7 @@ struct cdns_mhdp_device {
 
 	bool link_up;
 	bool plugged;
+	bool no_hpd;
 
 	/*
 	 * "start_lock" protects the access to bridge_attached and
Signature · 1 line
2.34.1
AI review
#5 lore raw

Re: [PATCH v5 2/2] drm: bridge: cdns-mhdp8546: Add no-hpd property

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider: - [High] Reading `DP_LANE0_1_STATUS` (0x202) for connection polling violates DRM guidelines and disrupts…

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Reading DP_LANE0_1_STATUS (0x202) for connection polling violates DRM guidelines and disrupts link training state machines.
- [High] The .detect() callback unconditionally triggers hardware stream re-enablement during periodic polling in no-hpd mode.
- [High] Resource leak of drm_dp_aux if firmware loading times out during cdns_mhdp_attach(), leading to a Use-After-Free.
- [Medium] Hardcoded 100ms timeout for asynchronous firmware loading in cdns_mhdp_attach() can spuriously fail bridge attachment.
- [Medium] Changing DPCD read failures to dev_err() will flood the kernel log with false-positive errors during normal operations. --

--- Patch [2]: [PATCH v5 2/2] drm: bridge: cdns-mhdp8546: Add no-hpd property --- commit d6385d712222c0d749e282f8179c659c2e87c45d
Author: Rahul T R <[email protected]>
Subject: drm: bridge: cdns-mhdp8546: Add no-hpd property

This commit adds a 'no-hpd' property to support boards where the HPD line cannot be used for hotplug detection due to hardware limitations. When set, the driver uses auxiliary channel (AUX) DPCD reads to detect monitor presence by polling the connection status via the .detect() callback.

Quoted 3 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +0 -0

[ ... ]

Quoted 5 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +0 -1
@@ -788,9 +792,14 @@ static ssize_t cdns_mhdp_transfer(struct drm_dp_aux *aux,
 		ret = cdns_mhdp_dpcd_read(mhdp, msg->address,
 					  msg->buffer, msg->size);
 		if (ret) {
-			dev_dbg(mhdp->dev,

drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c static ssize_t cdns_mhdp_transfer(struct drm_dp_aux *aux, · line 802

Quoted 10 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +8 -2
-				"Failed to read DPCD addr %u\n",
-				msg->address);
+			if (mhdp->no_hpd)
+				dev_dbg(mhdp->dev,
+					"Failed to read DPCD addr %u\n",
+					msg->address);
+			else
+				dev_err(mhdp->dev,
+					"Failed to read DPCD addr %u\n",
+					msg->address);

[Severity: Medium]
Will this change spam the kernel log with false-positive errors during normal operations?

DP AUX channel transactions routinely fail during normal operations, such as when a disconnected monitor is probed, during DP sleep states, or when the DRM DP helper retries transient link training failures. Emitting a dev_err() on every AUX read failure might flood the kernel log on standard hardware.

[ ... ]

Quoted 4 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +0 -0
@@ -1523,6 +1532,26 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
 
 	spin_unlock(&mhdp->start_lock);

drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c static int cdns_mhdp_attach(struct drm_bridge *bridge, · line 1544

Quoted 10 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +10 -0
+	if (mhdp->no_hpd) {
+		/*
+		 * In no-hpd mode there is no interrupt to signal firmware
+		 * readiness. The firmware loads asynchronously after probe(),
+		 * so we must wait here until the uCPU is running before
+		 * attempting the first AUX channel poll for monitor presence.
+		 */
+		ret = wait_event_timeout(mhdp->fw_load_wq,
+					 mhdp->hw_state == MHDP_HW_READY,
+					 msecs_to_jiffies(100));

[Severity: Medium]
Could this hardcoded 100ms timeout spuriously fail bridge attachment?

Firmware loading from a filesystem (via request_firmware_nowait) can easily take hundreds of milliseconds or longer depending on storage performance and system load. If the timeout expires prematurely, the driver aborts with -ETIMEDOUT, which could permanently break the display pipeline for that boot.

drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c static int cdns_mhdp_attach(struct drm_bridge *bridge, · line 1548

Quoted 4 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +4 -0
+		if (ret == 0) {
+			dev_err(mhdp->dev, "%s: Timeout waiting for fw loading\n",
+				__func__);
+			return -ETIMEDOUT;

[Severity: High]
Does this direct return leak the drm_dp_aux resource?

If the firmware loading timeout expires, this returns -ETIMEDOUT directly instead of jumping to the aux_unregister error handling label.

Since drm_dp_aux_register() sets up an I2C adapter and the DRM core does not call .detach() if attach fails, bypassing drm_dp_aux_unregister() leaks the I2C adapter. Because the memory backing the drm_dp_aux structure is devm-managed, unloading the module frees the memory while the adapter is still registered, which can cause a use-after-free when the I2C subsystem accesses it.

Quoted 5 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +5 -0
+		}
+
+		cdns_mhdp_update_link_status(mhdp);
+		return 0;
+	}

[ ... ]

drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c static int cdns_mhdp_update_link_status(struct cdns_mhdp_device *mhdp) · line 2136

Quoted 7 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +2 -1
@@ -2100,7 +2132,16 @@ static int cdns_mhdp_update_link_status(struct cdns_mhdp_device *mhdp)
 
 	mutex_lock(&mhdp->link_mutex);
 
-	mhdp->plugged = cdns_mhdp_detect_hpd(mhdp, &hpd_pulse);
+	if (mhdp->no_hpd) {
+		ret = drm_dp_dpcd_read_link_status(&mhdp->aux, status);

[Severity: High]
Does reading the link status here violate DRM subsystem guidelines and disrupt link training state machines?

The DRM core polls .detect() every 10 seconds when no-hpd is set, which calls cdns_mhdp_update_link_status(). This unconditionally calls drm_dp_dpcd_read_link_status() which reads DP_LANE0_1_STATUS (0x202).

According to DRM guidelines, registers in the link training status range (0x202-0x207) participate in the CR/EQ training state machine and are not safe for arbitrary read access outside of a link training sequence. Reading this register continuously for presence detection can induce hardware instability, screen flickering, and link drops. Should a safe register like DP_DPCD_REV (0x000) be used instead?

drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c static int cdns_mhdp_update_link_status(struct cdns_mhdp_device *mhdp) · line 2137

Quoted 1 line
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +1 -0
+		hpd_pulse = false;

[Severity: High]
Does hardcoding hpd_pulse to false cause the active display stream to be re-initialized on every 10-second poll?

In no-hpd mode, .detect() is polled every 10 seconds. Because hpd_pulse is hardcoded to false here, the later logic bypasses the check that validates link status without state mutation:

    if (hpd_pulse && old_plugged == mhdp->plugged) {
        ret = drm_dp_dpcd_read_link_status(&mhdp->aux, status);
        if (!ret && ...)
            goto out;
        ...
    }

Instead, execution falls through to the end of the function. If mhdp->bridge_enabled is true, this causes cdns_mhdp_sst_enable() to be called:

    if (mhdp->bridge_enabled) {
        ...
        cdns_mhdp_sst_enable(mhdp, current_mode);
    }

This repeatedly re-programs active stream and framer configuration registers on every poll, which can cause the active video stream to reset and glitch every 10 seconds.

Quoted 7 lines
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +7 -0
+		if (ret < 0)
+			mhdp->plugged = false;
+		else
+			mhdp->plugged = true;
+	} else {
+		mhdp->plugged = cdns_mhdp_detect_hpd(mhdp, &hpd_pulse);
+	}
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
#6 lore raw
In reply to Yashas D
Quoted 10 lines · Yashas D

This series adds 'no-hpd' device tree property support to the Cadence MHDP8546 bridge driver for boards where the HPD line cannot be used for
hotplug detection.

On TI J721S2 EVMs, the HPD signal is routed to SoC pin AA24 (MCASP1_ACLKX/DP0_HPD). This pin is muxed with the McASP1 audio bit clock; selecting DP0_HPD breaks audio. There is no alternative pin carrying the HPD signal which makes it impossible to use HPD without loosing the audio capabilities.

Hi Yashas,

this description is not correct. On the J721S2 EVM the pin AA24 MCASP1_ACLKX is not used for audio.
The pin is just floating unless this "GESI"-board with an additional ethernet interface is connect. AA24 is used as as MCASP1_ACLKX.RGMII1_RD0 in this case.
See arch/arm64/boot/dts/ti/k3-j721s2-evm-gesi-exp-board.dtso

Also the AA24 pin needs to be configured as HPD pin (muxmode 3) otherwise the mhdp firmware will not turn on the bridge.

Dominik

Quoted 27 lines

When 'no-hpd' is set, DRM_BRIDGE_OP_HPD is omitted so the framework falls back to polling .detect() every ~10 seconds. Monitor presence is
determined via AUX DPCD reads instead of firmware HPD status registers.
The .detect() callback drives cdns_mhdp_update_link_status() on each poll to keep mhdp->plugged current. At attach time, the driver waits for firmware to be ready before performing the initial AUX poll since no interrupt will trigger it.

Changes since v4:
- Corrected the dt-binding Subject

Link to v4:
https://lore.kernel.org/all/[email protected]/

Rahul T R (2):
  dt-bindings: display: bridge: cdns,mhdp8546: Add no-hpd property to the cadence bridge
  drm: bridge: cdns-mhdp8546: Add no-hpd property

 .../display/bridge/cdns,mhdp8546.yaml         | 17 ++++++ .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 58 ++++++++++++++++- --
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  1 +

 3 files changed, 69 insertions(+), 7 deletions(-)
author
#7 lore raw
Quoted 23 lines · Dominik Haller

On Di, 2026-07-28 at 18: 23 +0530, Yashas D wrote: > This series adds 'no-hpd' device tree property support to the Cadence > MHDP8546 bridge driver for boards where the HPD line cannot be used > for > hotplug detection. > >

Quoted 10 lines · Yashas D

This series adds 'no-hpd' device tree property support to the Cadence MHDP8546 bridge driver for boards where the HPD line cannot be used for
hotplug detection.

On TI J721S2 EVMs, the HPD signal is routed to SoC pin AA24 (MCASP1_ACLKX/DP0_HPD). This pin is muxed with the McASP1 audio bit clock; selecting DP0_HPD breaks audio. There is no alternative pin carrying the HPD signal which makes it impossible to use HPD without loosing the audio capabilities.

Hi Yashas,

this description is not correct. On the J721S2 EVM the pin AA24 MCASP1_ACLKX is not used for audio.
The pin is just floating unless this "GESI"-board with an additional ethernet interface is connect. AA24 is used as as MCASP1_ACLKX.RGMII1_RD0 in this case.
See arch/arm64/boot/dts/ti/k3-j721s2-evm-gesi-exp-board.dtso

Quoted 6 lines

Also the AA24 pin needs to be configured as HPD pin (muxmode 3) otherwise the mhdp firmware will not turn on the bridge.

Dominik

Hi Dominik,

You are correct, I apologise for the error. The SoC PAD mux conflict on AA24 is with RGMII1_RD0 (GESI ethernet expansion board), not MCASP1 audio. I will fix the commit message.

The full picture on J721S2X-PM1-SOM rev E2:

- The HPD resistor is DNI from factory, so AA24 is not physically connected to the DP connector HPD line by default. However AA24 must still be configured in DP0_HPD mux mode (mode 3) for the MHDP firmware to operate at all — configuring it in any other mode prevents the
bridge from loading.

- When we physically connected HPD by populating the resistor, the E2 board failed to boot with a monitor attached. The HPD line leaks voltage from the monitor into the SoC while powered off, causing a PMIC error. This was fixed in rev E3+ with an HPD buffer. Our boards are rev E2.

The audio conflict in earlier message versions was our mistake. It came from investigating whether an alternative routing path through a board-level signal MUX chip (MUX1/MUX2) on the SOM could expose a GPIO for HPD — changing that MUX's port selection would have affected audio. That is unrelated to the SoC PAD mux and should not have been mentioned.

I will fix the message and send a new version.

Thanks,
Yashas D

Quoted 29 lines
Quoted 10 lines

When 'no-hpd' is set, DRM_BRIDGE_OP_HPD is omitted so the framework falls back to polling .detect() every ~10 seconds. Monitor presence is
determined via AUX DPCD reads instead of firmware HPD status registers.
The .detect() callback drives cdns_mhdp_update_link_status() on each poll to keep mhdp->plugged current. At attach time, the driver waits for firmware to be ready before performing the initial AUX poll since no interrupt will trigger it.

Quoted 5 lines

Changes since v4:
- Corrected the dt-binding Subject

Link to v4:
https://urldefense.com/v3/__https://lore.kernel.org/

all/[email protected]/__;!!G3vK! XKetSJhTJzSznMTBeoww63bvXSPD3xrWstRrf4H6AhnrM5IjIvNFa9uHVVWEYPEoe0GNrZXGb8IF$ <https://urldefense.com/v3/__https://lore.kernel.org/all/[email protected]/__;!!G3vK!XKetSJhTJzSznMTBeoww63bvXSPD3xrWstRrf4H6AhnrM5IjIvNFa9uHVVWEYPEoe0GNrZXGb8IF$>

Quoted 12 lines

Rahul T R (2):
  dt-bindings: display: bridge: cdns,mhdp8546: Add no-hpd property to the cadence bridge
  drm: bridge: cdns-mhdp8546: Add no-hpd property

 .../display/bridge/cdns,mhdp8546.yaml         | 17 ++++++ .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 58 ++++++++++++++++- --
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  1 +

 3 files changed, 69 insertions(+), 7 deletions(-)
#8 lore raw
Quoted 77 lines · Yashas D
Quoted 33 lines · Dominik Haller

On Di, 2026-07-28 at 18: 23 +0530, Yashas D wrote: > This series adds
'no-hpd' device tree property support to the Cadence > MHDP8546 bridge
driver for boards where the HPD line cannot be used > for > hotplug detection. > >

Quoted 7 lines · Yashas D

This series adds 'no-hpd' device tree property support to the Cadence
MHDP8546 bridge driver for boards where the HPD line cannot be used
for
hotplug detection.

Quoted 7 lines

On TI J721S2 EVMs, the HPD signal is routed to SoC pin AA24 (MCASP1_ACLKX/DP0_HPD). This pin is muxed with the McASP1 audio bit
clock; selecting DP0_HPD breaks audio. There is no alternative pin
carrying the HPD signal which makes it impossible to use HPD without loosing the audio capabilities.

Hi Yashas,

this description is not correct. On the J721S2 EVM the pin AA24 MCASP1_ACLKX is not used for audio.
The pin is just floating unless this "GESI"-board with an additional
ethernet interface is connect. AA24 is used as as MCASP1_ACLKX.RGMII1_RD0 in this case.
See arch/arm64/boot/dts/ti/k3-j721s2-evm-gesi-exp-board.dtso

Quoted 6 lines

Also the AA24 pin needs to be configured as HPD pin (muxmode 3) otherwise the mhdp firmware will not turn on the bridge.

Dominik

Hi Dominik,

You are correct, I apologise for the error. The SoC PAD mux conflict on AA24 is with RGMII1_RD0 (GESI ethernet expansion board), not MCASP1
audio. I will fix the commit message.

The full picture on J721S2X-PM1-SOM rev E2:

- The HPD resistor is DNI from factory, so AA24 is not physically connected to the DP connector HPD line by default. However AA24
must
still be configured in DP0_HPD mux mode (mode 3) for the MHDP
firmware
to operate at all — configuring it in any other mode prevents the
bridge from loading.

- When we physically connected HPD by populating the resistor, the E2 board failed to boot with a monitor attached. The HPD line leaks
voltage
from the monitor into the SoC while powered off, causing a PMIC
error.
This was fixed in rev E3+ with an HPD buffer. Our boards are rev
E2.

The audio conflict in earlier message versions was our mistake. It came from investigating whether an alternative routing path through a board-level signal MUX chip (MUX1/MUX2) on the SOM could expose a GPIO
for HPD — changing that MUX's port selection would have affected audio.
That is unrelated to the SoC PAD mux and should not have been mentioned.

Quoted 1 line

I will fix the message and send a new version.

Hi Yashas,

please also update the commit description of the actual patch 2/2 as it implies at the moment that you can use the AA24 pin for other functions while using the display port.

Thanks

Dominik

Quoted 54 lines

Thanks,
Yashas D

Quoted 49 lines
Quoted 15 lines

When 'no-hpd' is set, DRM_BRIDGE_OP_HPD is omitted so the framework
falls back to polling .detect() every ~10 seconds. Monitor presence
is
determined via AUX DPCD reads instead of firmware HPD status registers.
The .detect() callback drives cdns_mhdp_update_link_status() on each
poll to keep mhdp->plugged current. At attach time, the driver waits
for firmware to be ready before performing the initial AUX poll since
no interrupt will trigger it.

Quoted 6 lines

Changes since v4:
- Corrected the dt-binding Subject

Link to v4:
https://urldefense.com/v3/__https://lore.kernel.org/

all/[email protected]/__;!!G3vK! XKetSJhTJzSznMTBeoww63bvXSPD3xrWstRrf4H6AhnrM5IjIvNFa9uHVVWEYPEoe0G NrZXGb8IF$
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2F
urldefense.com%2Fv3%2F__https%3A%2F%2Flore.kernel.org%2Fall%2F20260 630102610.1849902-1-y- d%40ti.com%2F__%3B!!G3vK!XKetSJhTJzSznMTBeoww63bvXSPD3xrWstRrf4H6Ah nrM5IjIvNFa9uHVVWEYPEoe0GNrZXGb8IF%24&data=05%7C02%7Cd.haller%40phy tec.de%7Ce1e53182268a4df81d1908deed4ada4b%7Ce609157c80e2446d9be39c9 9c2399d29%7C0%7C0%7C639209102909756678%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2TH3dx%2FirnEKUcHFu9vOz%2F ZT9JSyfcyMp%2BDjQPDUC%2F0%3D&reserved=0>

Quoted 14 lines

Rahul T R (2):
dt-bindings: display: bridge: cdns,mhdp8546: Add no-hpd
property to
the cadence bridge
drm: bridge: cdns-mhdp8546: Add no-hpd property

 .../display/bridge/cdns,mhdp8546.yaml         | 17 ++++++
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 58
++++++++++++++++-
--
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  1 +
 3 files changed, 69 insertions(+), 7 deletions(-)
author
#9 lore raw
Quoted 81 lines · Dominik Haller
Quoted 77 lines · Yashas D
Quoted 33 lines · Dominik Haller

On Di, 2026-07-28 at 18: 23 +0530, Yashas D wrote: > This series adds
'no-hpd' device tree property support to the Cadence > MHDP8546 bridge
driver for boards where the HPD line cannot be used > for > hotplug detection. > >

Quoted 7 lines · Yashas D

This series adds 'no-hpd' device tree property support to the Cadence
MHDP8546 bridge driver for boards where the HPD line cannot be used
for
hotplug detection.

Quoted 7 lines

On TI J721S2 EVMs, the HPD signal is routed to SoC pin AA24 (MCASP1_ACLKX/DP0_HPD). This pin is muxed with the McASP1 audio bit
clock; selecting DP0_HPD breaks audio. There is no alternative pin
carrying the HPD signal which makes it impossible to use HPD without loosing the audio capabilities.

Hi Yashas,

this description is not correct. On the J721S2 EVM the pin AA24 MCASP1_ACLKX is not used for audio.
The pin is just floating unless this "GESI"-board with an additional
ethernet interface is connect. AA24 is used as as MCASP1_ACLKX.RGMII1_RD0 in this case.
See arch/arm64/boot/dts/ti/k3-j721s2-evm-gesi-exp-board.dtso

Quoted 6 lines

Also the AA24 pin needs to be configured as HPD pin (muxmode 3) otherwise the mhdp firmware will not turn on the bridge.

Dominik

Hi Dominik,

You are correct, I apologise for the error. The SoC PAD mux conflict on AA24 is with RGMII1_RD0 (GESI ethernet expansion board), not MCASP1
audio. I will fix the commit message.

The full picture on J721S2X-PM1-SOM rev E2:

- The HPD resistor is DNI from factory, so AA24 is not physically connected to the DP connector HPD line by default. However AA24
must
still be configured in DP0_HPD mux mode (mode 3) for the MHDP
firmware
to operate at all — configuring it in any other mode prevents the
bridge from loading.

- When we physically connected HPD by populating the resistor, the E2 board failed to boot with a monitor attached. The HPD line leaks
voltage
from the monitor into the SoC while powered off, causing a PMIC
error.
This was fixed in rev E3+ with an HPD buffer. Our boards are rev
E2.

The audio conflict in earlier message versions was our mistake. It came from investigating whether an alternative routing path through a board-level signal MUX chip (MUX1/MUX2) on the SOM could expose a GPIO
for HPD — changing that MUX's port selection would have affected audio.
That is unrelated to the SoC PAD mux and should not have been mentioned.

Quoted 1 line

I will fix the message and send a new version.

Hi Yashas,

Quoted 11 lines

please also update the commit description of the actual patch 2/2 as it implies at the moment that you can use the AA24 pin for other functions while using the display port.

Thanks

Dominik

Quoted 4 lines

Thanks,
Yashas D

Hi Dominik,
Have updated it in v6.

Thanks,
Yashas D

Quoted 51 lines
Quoted 50 lines
Quoted 49 lines
Quoted 15 lines

When 'no-hpd' is set, DRM_BRIDGE_OP_HPD is omitted so the framework
falls back to polling .detect() every ~10 seconds. Monitor presence
is
determined via AUX DPCD reads instead of firmware HPD status registers.
The .detect() callback drives cdns_mhdp_update_link_status() on each
poll to keep mhdp->plugged current. At attach time, the driver waits
for firmware to be ready before performing the initial AUX poll since
no interrupt will trigger it.

Quoted 6 lines

Changes since v4:
- Corrected the dt-binding Subject

Link to v4:
https://urldefense.com/v3/__https://lore.kernel.org/

all/[email protected]/__;!!G3vK! XKetSJhTJzSznMTBeoww63bvXSPD3xrWstRrf4H6AhnrM5IjIvNFa9uHVVWEYPEoe0G NrZXGb8IF$
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2F
urldefense.com%2Fv3%2F__https%3A%2F%2Flore.kernel.org%2Fall%2F20260 630102610.1849902-1-y- d%40ti.com%2F__%3B!!G3vK!XKetSJhTJzSznMTBeoww63bvXSPD3xrWstRrf4H6Ah nrM5IjIvNFa9uHVVWEYPEoe0GNrZXGb8IF%24&data=05%7C02%7Cd.haller%40phy tec.de%7Ce1e53182268a4df81d1908deed4ada4b%7Ce609157c80e2446d9be39c9 9c2399d29%7C0%7C0%7C639209102909756678%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2TH3dx%2FirnEKUcHFu9vOz%2F ZT9JSyfcyMp%2BDjQPDUC%2F0%3D&reserved=0>

Quoted 14 lines

Rahul T R (2):
dt-bindings: display: bridge: cdns,mhdp8546: Add no-hpd
property to
the cadence bridge
drm: bridge: cdns-mhdp8546: Add no-hpd property

  .../display/bridge/cdns,mhdp8546.yaml         | 17 ++++++
  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 58
++++++++++++++++-
--
  .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  1 +
  3 files changed, 69 insertions(+), 7 deletions(-)