* [PATCH 0/1] arm64: dts: rockchip: fix HDMI RX HPD on CM3588 NAS
@ 2026-11-11 21:00 Tim Surber
2026-11-11 21:00 ` [PATCH 1/1] arm64: dts: rockchip: fix HDMI RX 5V detection pin " Tim Surber
0 siblings, 1 reply; 2+ messages in thread
From: Tim Surber @ 2026-11-11 21:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Tim Surber, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Valentin Hăloiu, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
The upstream CM3588 NAS device tree uses GPIO3_D4 both as the HDMI
receiver's HPD output and as its 5V detection input. The GPIO setting
wins, so the receiver can never drive HPD. Sources then read the EDID
while the driver is still writing it and keep the damaged copy. This
patch moves the 5V detection to GPIO1_D5, the pin that FriendlyElec's
vendor kernel uses for the CM3588 (rk3588-nanopi6-rev09.dts is the
CM3588 board file there):
hdmirx-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_LOW>;
https://github.com/friendlyarm/kernel-rockchip/blob/30d3e1c2470a7282f37b96fdd4354314dda69aa3/arch/arm64/boot/dts/rockchip/rk3588-nanopi6-rev09.dts#L299-L309
hdmirx_det: rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
https://github.com/friendlyarm/kernel-rockchip/blob/30d3e1c2470a7282f37b96fdd4354314dda69aa3/arch/arm64/boot/dts/rockchip/rk3588-nanopi6-rev09.dts#L584-L586
Testing was done on a CM3588 NAS with HDMI0 looped back into HDMI RX.
Both runs used the same kernel, built from linux-rockchip for-next
(c3baae5f1a15) with nothing else applied, and only the DTB was
swapped:
for-next DTB with this patch
boots with a good EDID on HDMI0 7/10 10/10
pin 124 (GPIO3_D4) function hdmirx GPIO hdmi (HPD)
EDID change via VIDIOC_S_EDID never seen seen in ~0.48 s,
reaching the source 2 HPD IRQs each
pinctrl "not freeing pin 124" 6/6 unbinds 0/6 unbinds
warning on unbind
5V detected (power_present), yes yes
receiver locks to 3840x2160
dtbs_check gives no new warnings.
Tim Surber (1):
arm64: dts: rockchip: fix HDMI RX 5V detection pin on CM3588 NAS
.../boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
base-commit: c3baae5f1a15645cddadcb2b9abddef5df291f59
--
2.55.0
^ permalink raw reply [flat|nested] 2+ messages in thread* [PATCH 1/1] arm64: dts: rockchip: fix HDMI RX 5V detection pin on CM3588 NAS
2026-11-11 21:00 [PATCH 0/1] arm64: dts: rockchip: fix HDMI RX HPD on CM3588 NAS Tim Surber
@ 2026-11-11 21:00 ` Tim Surber
0 siblings, 0 replies; 2+ messages in thread
From: Tim Surber @ 2026-11-11 21:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Tim Surber, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Valentin Hăloiu, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
The HDMI receiver node uses GPIO3_D4 both as the receiver's HPD output
(hdmim1_rx_hpdin) and as its 5V detection input (hpd-gpios and the
hdmirx_hpd pin group). Both pin groups are in the same pinctrl state and
the later one wins, so the pin ends up as a GPIO input with pull-up.
The controller can then never drive HPD: the source sees HPD asserted
all the time, and the 5V detection reads back the HPD line instead of
the source's 5V.
The driver relies on HPD being low while it writes the EDID, at probe
and on VIDIOC_S_EDID. With HPD stuck high, a source may read the EDID
while it is being written. A source that does so at boot keeps the
damaged copy, as it never sees the HPD pulse that should make it read
the EDID again. On a CM3588 NAS with HDMI0 looped back into HDMI RX
this happened on 3 of 10 boots: HDMI0 logged "EDID has corrupt header",
found no valid EDID and fell back to 1024x768. Changing the EDID with
VIDIOC_S_EDID was not noticed by the source at all.
FriendlyElec's vendor device tree for the CM3588 uses GPIO1_D5, active
low with pull-up, for the 5V detection. The NanoPC-T6 uses the same pin
upstream. Use that pin and leave GPIO3_D4 to the HPD function.
With this change the pin multiplexing shows GPIO3_D4 in the HPD
function, the source's HPD interrupt fires on every EDID update, and a
changed EDID reaches the source within 0.5 s. In 10 boots (5 power
cycles, 5 reboots) the EDID read by HDMI0 always matched the one
written by the receiver, and HDMI0 came up at its native mode every
time. The receiver still detects the source's 5V and locks to its
signal.
Using the pin in two groups also made pinctrl warn on every unbind of
the receiver ("not freeing pin 124 (gpio3-28) as part of deactivating
group hdmim1-rx-hpdin - it is already used for some other setting"),
and in earlier testing the following bind sometimes failed with
-EINVAL. With this change the warning is gone.
Fixes: f9f45293f0d8 ("arm64: dts: rockchip: Enable HDMI receiver on CM3588")
Signed-off-by: Tim Surber <me@timsurber.de>
---
.../boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts b/arch/arm64/boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts
index f4c34da61..b2df36113 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts
@@ -376,7 +376,7 @@ &hdmi_receiver_cma {
};
&hdmi_receiver {
- hpd-gpios = <&gpio3 RK_PD4 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_hpd>;
pinctrl-names = "default";
status = "okay";
@@ -571,7 +571,7 @@ hdmi1_tx_on_h: hdmi1-tx-on-h {
hdmirx {
hdmirx_hpd: hdmirx-5v-detection {
- rockchip,pins = <3 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+ rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
};
};
--
2.55.0
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-11-11 21:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-11 21:00 [PATCH 0/1] arm64: dts: rockchip: fix HDMI RX HPD on CM3588 NAS Tim Surber
2026-11-11 21:00 ` [PATCH 1/1] arm64: dts: rockchip: fix HDMI RX 5V detection pin " Tim Surber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®