Re: [PATCH 1/1] arm64: dts: rockchip: fix HDMI RX 5V detection pin on CM3588 NAS

[Heiko Stuebner <heiko@sntech.de>]

Hi Tim,

Am Mittwoch, 11. November 2026, 22:00:27 Mitteleuropäische Normalzeit schrieb Tim Surber:
> 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.

you're fixing _one_ gpio, this does not need a novel size explanation.
Please make sure you're writing commit descriptions yourself and not
let an LLM run amok on it please.


Thanks
Heiko