mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tim Surber <me@timsurber.de>
To: Heiko Stuebner <heiko@sntech.de>
Cc: "Tim Surber" <me@timsurber.de>, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Valentin Hăloiu" <valentin.haloiu@gmail.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH 1/1] arm64: dts: rockchip: fix HDMI RX 5V detection pin on CM3588 NAS
Date: Wed, 11 Nov 2026 22:00:27 +0100	[thread overview]
Message-ID: <20261111210059.3489502-2-me@timsurber.de> (raw)
In-Reply-To: <20261111210059.3489502-1-me@timsurber.de>

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


      reply	other threads:[~2026-11-11 21:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 21:00 [PATCH 0/1] arm64: dts: rockchip: fix HDMI RX HPD " Tim Surber
2026-11-11 21:00 ` Tim Surber [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261111210059.3489502-2-me@timsurber.de \
    --to=me@timsurber.de \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh@kernel.org \
    --cc=valentin.haloiu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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®