On 29/07/26 04:07, Dominik Haller wrote:
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. > >
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.
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
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
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://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$>
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(-)
