* [PATCH 17/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-friendlyelec-cm3588-nas
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B1 and GPIO4_B2 lines to control the voltage
bias on the data lines for the HDMI0 and HDMI1 ports. These lines must
be asserted when operating in HDMI 2.1 FRL mode and deasserted for HDMI
1.4/2.0 TMDS mode.
Wire up both HDMI ports to their respective GPIO lines using the
frl-enable-gpios property to allow adjusting the bias when transitioning
between TMDS and FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
.../boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
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 10a7d3691a26..2d17c77e9e5d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts
@@ -331,6 +331,9 @@ &gpio4 {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -347,6 +350,9 @@ hdmi0_out_con: endpoint {
};
&hdmi1 {
+ pinctrl-0 = <&hdmim2_tx1_cec &hdmim0_tx1_hpd
+ &hdmim1_tx1_scl &hdmim1_tx1_sda &hdmi1_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -520,6 +526,16 @@ key1_pin: key1-pin {
};
};
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ hdmi1_frl_en: hdmi1-frl-en {
+ rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hdmirx {
hdmirx_hpd: hdmirx-5v-detection {
rockchip,pins = <3 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 14/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb1-v10
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B1 and GPIO4_B2 lines to control the voltage
bias on the data lines for the HDMI0 and HDMI1 ports. These lines must
be asserted when operating in HDMI 2.1 FRL mode and deasserted for HDMI
1.4/2.0 TMDS mode.
Wire up both HDMI ports to their respective GPIO lines using the
frl-enable-gpios property to allow adjusting the bias when transitioning
between TMDS and FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
index 09bc7b68dcc0..e9f5fda70da5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
@@ -360,6 +360,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -376,6 +379,9 @@ hdmi0_out_con: endpoint {
};
&hdmi1 {
+ pinctrl-0 = <&hdmim2_tx1_cec &hdmim0_tx1_hpd
+ &hdmim1_tx1_scl &hdmim1_tx1_sda &hdmi1_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -612,6 +618,16 @@ rtl8211f_rst: rtl8211f-rst {
};
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ hdmi1_frl_en: hdmi1-frl-en {
+ rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hdmirx {
hdmirx_hpd: hdmirx-5v-detection {
rockchip,pins = <2 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 15/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb2-v10
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO3_C5 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts
index 60ba6ac55b23..42f46b61c585 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts
@@ -143,6 +143,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio3 RK_PC5 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -183,6 +186,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <3 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 12/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-evb
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B0 and GPIO4_B2 lines to control the voltage
bias on the data lines for the HDMI0 and HDMI1 ports. These lines must
be asserted when operating in HDMI 2.1 FRL mode and deasserted for HDMI
1.4/2.0 TMDS mode.
Wire up both HDMI ports to their respective GPIO lines using the
frl-enable-gpios property to allow adjusting the bias when transitioning
between TMDS and FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
index 3d5c8b753208..9555df43f339 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts
@@ -125,6 +125,9 @@ vcc5v0_usb30_otg: regulator-vcc5v0-usb30-otg {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -146,7 +149,9 @@ hdmi0_out_con: endpoint {
&hdmi1 {
pinctrl-names = "default";
- pinctrl-0 = <&hdmim2_tx1_cec &hdmim0_tx1_hpd &hdmim1_tx1_scl &hdmim1_tx1_sda>;
+ pinctrl-0 = <&hdmim2_tx1_cec &hdmim0_tx1_hpd &hdmim1_tx1_scl &hdmim1_tx1_sda
+ &hdmi1_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -211,6 +216,16 @@ &pcie3x4 {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ hdmi1_frl_en: hdmi1-frl-en {
+ rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
lcd {
lcdpwr_en: lcdpwr-en {
rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
--
2.53.0
^ permalink raw reply related
* [PATCH 10/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-sige7
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B1 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts b/arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts
index 39197ee19837..3e64d573bb89 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts
@@ -177,6 +177,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -347,6 +350,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 11/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-w3
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B1 and GPIO4_A1 lines to control the voltage
bias on the data lines for the HDMI0 and HDMI1 ports. These lines must
be asserted when operating in HDMI 2.1 FRL mode and deasserted for HDMI
1.4/2.0 TMDS mode.
Wire up both HDMI ports to their respective GPIO lines using the
frl-enable-gpios property to allow adjusting the bias when transitioning
between TMDS and FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts b/arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts
index 6ad2759ddcca..a042b10d7023 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts
@@ -162,6 +162,9 @@ &combphy2_psu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -182,6 +185,9 @@ &hdmi0_sound {
};
&hdmi1 {
+ pinctrl-0 = <&hdmim2_tx1_cec &hdmim0_tx1_hpd
+ &hdmim1_tx1_scl &hdmim1_tx1_sda &hdmi1_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -330,6 +336,16 @@ &pcie3x4 {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ hdmi1_frl_en: hdmi1-frl-en {
+ rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 13/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-genbook
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B0 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts
index 738637ecaf55..2d6f268aa096 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts
@@ -184,7 +184,9 @@ edp_out_panel: endpoint {
/* HDMI CEC is not used */
&hdmi0 {
- pinctrl-0 = <&hdmim0_tx0_hpd &hdmim0_tx0_scl &hdmim0_tx0_sda>;
+ pinctrl-0 = <&hdmim0_tx0_hpd &hdmim0_tx0_scl &hdmim0_tx0_sda
+ &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -277,6 +279,12 @@ &pcie3x4 {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
lcd {
lcdpwr_en: lcdpwr-en {
rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
--
2.53.0
^ permalink raw reply related
* [PATCH 07/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_C6 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property and drop the line from the vcc5v_hdmi_tx regulator to allow
adjusting the bias when transitioning between TMDS and FRL operating
modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts
index 7ec27b05ff10..21ef369c478c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts
@@ -111,10 +111,7 @@ vcc5v_dcin: regulator-vcc5v-dcin {
vcc5v_hdmi_tx: regulator-vcc5v-hdmi-tx {
compatible = "regulator-fixed";
- enable-active-high;
- gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_tx_on_h>;
+ regulator-always-on;
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
regulator-name = "vcc5v_hdmi_tx";
@@ -252,6 +249,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -717,7 +716,7 @@ led2_h: led2-h {
};
hdmi {
- hdmi_tx_on_h: hdmi-tx-on-h {
+ hdmi_frl_en: hdmi-frl-en {
rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH 09/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
index 899a84b1fbf9..d643fa409187 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
@@ -289,6 +289,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -720,6 +722,12 @@ &pcie0 {
};
&pinctrl {
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_C6 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property and drop the line from the vcc_5v0_hdmi regulator to allow
adjusting the bias when transitioning between TMDS and FRL operating
modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
index 749f0a54b478..93ae37699366 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
@@ -140,10 +140,7 @@ regulator-state-mem {
vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
compatible = "regulator-fixed";
- enable-active-high;
- gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_con_en>;
+ regulator-always-on;
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
regulator-name = "vcc_5v0_hdmi";
@@ -231,6 +228,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -655,7 +654,7 @@ &pcie0 {
&pinctrl {
hdmi {
- hdmi_con_en: hdmi-con-en {
+ hdmi_frl_en: hdmi-frl-en {
rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH 06/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_C6 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
index 7406a4adf810..b889238503a6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
@@ -327,6 +327,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -813,6 +815,12 @@ gmac1_rst: gmac1-rst {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 08/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts
index d0ab1d1e0e11..68f9911bf4d4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts
@@ -283,6 +283,8 @@ ð0m0_rgmii_bus
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -720,6 +722,12 @@ &sdmmc {
};
&pinctrl {
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
rtc_int_l: rtc-int-l {
rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 01/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts b/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts
index b19f9b6be6bf..9f356bfcb663 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts
@@ -278,6 +278,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -738,6 +740,12 @@ hp_det: hp-det {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
pcie {
pcie_reset: pcie-reset {
rockchip,pins = <1 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Several boards based on the RK3576 and RK3588(S) SoCs use a
GPIO-controlled voltage bias circuit on the HDMI data lines that must be
switched according to the active link mode: asserted for HDMI 2.1 FRL
and deasserted for HDMI 1.4/2.0 TMDS.
This series adds the frl-enable-gpios property to the HDMI nodes of all
boards for which the GPIO configuration could be identified from vendor
BSP kernel sources and/or schematics where available. In a small number
of cases it was necessary to extract and disassemble the DTB from the
vendor firmware image.
One board remains unhandled (rk3588-edgeble-neu6a-io), pending
clarification from the vendor.
For each affected board the patches:
- set frl-enable-gpios with the appropriate GPIO reference and
GPIO_ACTIVE_LOW polarity (inverted relative to the BSP enable-gpios /
GPIO_ACTIVE_HIGH convention, which effectively acts as
tmds-enable-gpios)
- extend pinctrl-0 of the HDMI node to include the new pin group
- add the corresponding pinctrl definition under &pinctrl
It's worth noting the Rockchip platform glue driver for the DesignWare
HDMI QP TX controller already drives the frl-enable GPIO, but since FRL
is not yet supported, TMDS mode is unconditionally selected. This
ensures a consistent setup independent of hardware reset defaults and
bootloader state.
Furthermore, this allows removing a few DT quirks hardcoding the active
link mode and paves the way for a follow-up series enabling HDMI 2.1 FRL
support.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Cristian Ciocaltea (40):
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-sige7
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-w3
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-evb
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-genbook
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb1-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb2-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-firefly-itx-3588j
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-friendlyelec-cm3588-nas
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-h96-max-v58
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-jaguar
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-mnt-reform2
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-nanopc-t6
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-max
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-plus
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-ultra
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-roc-rt
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5-itx
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5b-5bp-5t
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-tiger
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-coolpi-4b
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-gameforce-ace
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-indiedroid-nova
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-khadas-edge2
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-nanopi-r6
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-odroid-m2
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-5
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-cm5-base
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-radxa-cm5-io
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5a
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5c
.../boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts | 8 ++++++++
.../boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts | 9 ++++-----
arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts | 17 ++++++++++++++++-
.../boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts | 9 +++++++++
.../boot/dts/rockchip/rk3588-firefly-itx-3588j.dts | 9 +++++++++
.../dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-h96-max-v58.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts | 15 ++++++++++++++-
arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 16 ++++++++++++++++
.../arm64/boot/dts/rockchip/rk3588-orangepi-5-ultra.dts | 9 ++++++++-
arch/arm64/boot/dts/rockchip/rk3588-roc-rt.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 9 ++++++++-
arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 16 +++++++++++++++-
arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 3 ++-
arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 9 ++++++++-
arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-gameforce-ace.dts | 8 +++-----
.../arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts | 13 +++++++++----
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 9 +++++++++
.../boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts | 3 ++-
arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts | 15 ++++++++++++---
arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts | 10 +++++++++-
41 files changed, 392 insertions(+), 35 deletions(-)
---
base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
change-id: 20260417-dts-rk-frl-enable-gpios-ce9930dbf5ca
^ permalink raw reply
* [PATCH 04/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_C6 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
index 98d5d00d63b5..91fca9b31f81 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
@@ -375,6 +375,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -832,6 +834,12 @@ image_pwren: image-pwren {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
rtc_int: rtc-int {
rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 02/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
index 1c100ffd1518..43a5c6859909 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
@@ -304,6 +304,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -819,6 +821,12 @@ hp_det_l: hp-det-l {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 03/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
index fb0dd1bc5148..b112432528ed 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
@@ -370,6 +370,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -895,6 +897,12 @@ host_wake_bt: host-wake-bt {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
rtc_int: rtc-int {
rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v1] clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch on i.MX95
From: Peng Fan @ 2026-04-17 9:21 UTC (permalink / raw)
To: Hongxing Zhu, abelvesa@kernel.org, mturquette@baylibre.com,
sboyd@kernel.org, Frank Li, s.hauer@pengutronix.de,
festevam@gmail.com
Cc: linux-clk@vger.kernel.org, imx@nxp.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <20260417082910.489995-1-hongxing.zhu@nxp.com>
Hi Richard,
> Subject: [PATCH v1] clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch on
> i.MX95
>
> When the internal PLL is used as the PCIe reference clock source on
> i.MX95, a REFCLK rise-fall time mismatch is observed during PCIe Gen1
> compliance testing with the Lfast IO analyzer.
>
> Fix this issue by configuring the IREF_TX field to 0xF (15), which adjusts
> the transmitter current reference to meet the PCIe specification timing
> requirements.
BLK CTRL in HSIOMIX should be save/restore for the settings you configured
in probe phase.
Regards
Peng.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
> drivers/clk/imx/clk-imx95-blk-ctl.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/clk/imx/clk-imx95-blk-ctl.c b/drivers/clk/imx/clk-
> imx95-blk-ctl.c
> index 1f9259f45607..bc6957299cec 100644
> --- a/drivers/clk/imx/clk-imx95-blk-ctl.c
> +++ b/drivers/clk/imx/clk-imx95-blk-ctl.c
> @@ -44,6 +44,8 @@ struct imx95_blk_ctl_clk_dev_data {
> const char * const *parent_names;
> u32 num_parents;
> u32 reg;
> + u32 reg_init_msk;
> + u32 reg_init_val;
> u32 bit_idx;
> u32 bit_width;
> u32 clk_type;
> @@ -289,6 +291,8 @@ static const struct imx95_blk_ctl_clk_dev_data
> hsio_blk_ctl_clk_dev_data[] = {
> .parent_names = (const char *[]){ "func_out_en", },
> .num_parents = 1,
> .reg = 0,
> + .reg_init_msk = GENMASK(10, 7),
> + .reg_init_val = GENMASK(10, 7),
> .bit_idx = 6,
> .bit_width = 1,
> .type = CLK_GATE,
> @@ -410,6 +414,9 @@ static int imx95_bc_probe(struct
> platform_device *pdev)
> const struct imx95_blk_ctl_clk_dev_data *data = &bc-
> >pdata->clk_dev_data[i];
> void __iomem *reg = base + data->reg;
>
> + if (data->reg_init_msk)
> + writel((readl(reg) & ~data->reg_init_msk) |
> data->reg_init_val,
> +reg);
> +
> if (data->type == CLK_MUX) {
> hws[i] = clk_hw_register_mux(dev, data-
> >name, data->parent_names,
> data-
> >num_parents, data->flags, reg,
> --
> 2.37.1
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-17 9:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <aeDmk-t5Lc1zpkg9@monoceros>
Hi Uwe,
On 15:48 Thu 16 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
> one thing I forgot to ask: Is there a public reference manual covering
> the hardware. If yes, please add a link at the top of the driver.
Sort of, it's already reported in this driver top comment (Datasheet: tag).
The PWM controller is part of the RP1 chipset and you can find its description
under the PWM section. This is not a full-fledged datasheet but the registers
for the controller are somewhow documented.
>
> On Thu, Apr 16, 2026 at 12:30:43PM +0200, Andrea della Porta wrote:
> > On 19:31 Fri 10 Apr , Uwe Kleine-König wrote:
> > > I assume there is a glitch if I update two channels and the old
> > > configuration of the first channel ends while I'm in the middle of
> > > configuring the second?
> >
> > The configuration registers are per-channel but the update flag is global.
> > I don't have details of the hw insights, my best guess is that anything that
> > you set in the registers before updating the flag will take effect, so there
> > should be no glitches.
>
> Would be great if you could test that. (Something along the lines of:
> configure a very short period and wait a bit to be sure the short
> configuration is active. Configure something with a long period and wait
> shortly to be sure that the long period started, then change the duty,
> toggle the update bit and modify a 2nd channel without toggling update
> again. Then check the output of the 2nd channel after the first
> channel's period ended.
I stand corrected here: after some more investigation it seems that only the
enable/disable (plus osme other not currently used registers) depends on the
global update flag, while the period and duty per-channel registers are
independtly updatable while they are latched on the end of (specific channel)
period strobe.
I'd say that this should avoid any cross-channel glitches since they are managed
independently. Unfortunately I'm not able to test this with my current (and
rather old) equipment, this would require at least an external trigger channel.
Regarding the setup of a new value exactly during the strobe: I think this is
quite hard to achieve.
>
> > > > + if (ticks > U32_MAX)
> > > > + ticks = U32_MAX;
> > > > + wfhw->period_ticks = ticks;
> > >
> > > What happens if wf->period_length_ns > 0 but ticks == 0?
> >
> > I've added a check, returning 1 to signal teh round-up, and a minimum tick of 1
> > in this case.
>
> Sounds good. Are you able to verify that there is no +1 missing in the
> calculation, e.g. using 1 as register value really gives you a period of
> 1 tick and not 2?
You are right. The scope reveals there's always one extra (low signal) tick at the
end of each period. Let's say that teh user want 10 tick period, we have to use
9 instead to account for the extra tick at the end, so that the complete period
contains that extra tick?
This also means that if we ask for 100% duty cycle, the output waveform will
have the high part of the signal lasting one tick less than expected.a I guess
this is the accepted compromise.
OTOH, the minimum tick period would be 2 tick, less than that will otherwise
degenerate in a disabled channel.
>
> > > > + if (wf->duty_offset_ns + wf->duty_length_ns >= wf->period_length_ns) {
> > >
> > > The maybe surprising effect here is that in the two cases
> > >
> > > wf->duty_offset_ns == wf->period_length_ns and wf->duty_length_ns == 0
> > >
> > > and
> > >
> > > wf->duty_length_ns == wf->period_length_ns and wf->duty_offset_ns == 0
> > >
> > > you're configuring inverted polarity. I doesn't matter technically
> > > because the result is the same, but for consumers still using pwm_state
> > > this is irritating. That's why pwm-stm32 uses inverted polarity only if
> > > also wf->duty_length_ns and wf->duty_offset_ns are non-zero.
>
> Please align to the pwm-stm32 algorithm (as of
> https://patch.msgid.link/c5e7767cee821b5f6e00f95bd14a5e13015646fb.1776264104.git.u.kleine-koenig@baylibre.com)
> here to decide when to select inverted polarity.
Yep, I did already done when you sent that patch.
>
> > > > + }
> > > > +
> > > > + return 0;
> > > > +
> > > > +err_disable_clk:
> > > > + clk_disable_unprepare(rp1->clk);
> > > > +
> > > > + return ret;
> > > > +}
> > >
> > > On remove you miss to balance the call to clk_prepare_enable() (if no
> > > failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
> >
> > Since this driver now exports a syscon, it's only builtin (=Y) so
> > it cannot be unloaded.
> > I've also avoided the .remove callback via .suppress_bind_attrs.
>
> Oh no, please work cleanly here and make the driver unbindable. This
> yields better code quality and also helps during development and
> debugging.
I wish to, but the issue here is that this driver exports a syscon via
of_syscon_register_regmap() which I think doesn't have the unregister
counterpart. So the consumer will break in case we can unbind/unload
the module and the syscon will leak.
If you have any alternative I'll be glad to discuss.
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Arnd Bergmann @ 2026-04-17 8:59 UTC (permalink / raw)
To: Stefan Dösinger, Jonathan Corbet, Shuah Khan, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial
In-Reply-To: <20260416-send-v4-7-e19d02b944ec@gmail.com>
On Thu, Apr 16, 2026, at 22:19, Stefan Dösinger wrote:
>
> The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
> stable regardless of the other enabled UARTs. UART0, as the name
> implies, has a lower MMIO address, but uart1 is the one that usually has
> the boot output and console.
I'm not sure I'm following here. You generally want to either make
sure the alias matches whatever number is printed on the product
if there are multiple numbered ports, or you just use 'serial0'
as the only alias if there is only one port.
> + aliases {
> + serial1 = &uart1;
> + };
Either way, the alias should go into the board specific file, not
the general SoC file, as a board might be using a different
set of UARTs.
> +
> + /* The UART clock defaults to 26 mhz. It will be replaced when the zx29 clock
> + * framework is added.
> + */
> + uartclk: uartclk: clock-26000000 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <26000000>;
> + };
> +
> + uart1: serial@1408000 {
> + compatible = "arm,pl011", "arm,primecell";
> + arm,primecell-periphid = <0x001feffe>;
> + reg = <0x01408000 0x1000>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&uartclk>;
> + clock-names = "apb_pclk";
> + };
Since you know the addresses of the other uart instances, I would
suggest you add all of them at the same time.
Arnd
^ permalink raw reply
* Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id
From: Jie Gan @ 2026-04-17 8:58 UTC (permalink / raw)
To: Leo Yan
Cc: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel,
suzuki.poulose, mike.leach, james.clark, alexander.shishkin
In-Reply-To: <61c957b5-6072-4936-a37f-84e9aad8f5e3@oss.qualcomm.com>
On 4/17/2026 4:51 PM, Jie Gan wrote:
>
>
> On 4/17/2026 4:41 PM, Leo Yan wrote:
>> Hi Jie,
>>
>
> Hi Leo,
>
>> On Fri, Apr 17, 2026 at 09:01:17AM +0800, Jie Gan wrote:
>>
>> [...]
>>
>>> ... we still need support static trace ID allocation in parallel for
>>> the dummy sources and we should not break this logic in future refactor.
>>
>> Just confirm what is the reason you need to use static trace ID for the
>> dummy sources?
>>
>> I am wandering if we could use dev->devt as trace ID for dummy
>> devices. Since the device's MAJOR number is non-zero and occupies the
>> upper bits (see MINORBITS), it is naturally separated from the hardware
>> trace ID range. If so, we even don't need to bother ID alloc/release.
>>
>
> The data frame is generated by the dummy source(static TPDM, or some
I shouldnt take TPDM as example here, TPDM is a special source device
and it's trace data will be re-constructed in it's connected TPDA device
with TPDA's trace ID.
We have some other dummy sources designed for the CDSP/ADSP/MODEM
subsystems... which cannot be directly accessed by the kernel.
Thanks,
Jie
> other static devices, connected to a funnel or replicator, or TPDA
> device) automatically(contained pre-assigned trace ID) and the data
> trace is enabled by default. What we should do for the dummy source is
> enabling its connected port in driver for outputting the trace data to
> the connected device(funnel/TPDA/replicator etc...).
>
> For this scenario, we cannot dynamic allocate trace ID for the dummy
> source device. Because it's pre-assigned during the hardware design.
>
> Thanks,
> Jie
>
>> Thanks,
>> Leo
>
^ permalink raw reply
* Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id
From: Jie Gan @ 2026-04-17 8:51 UTC (permalink / raw)
To: Leo Yan
Cc: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel,
suzuki.poulose, mike.leach, james.clark, alexander.shishkin
In-Reply-To: <20260417084118.GP356832@e132581.arm.com>
On 4/17/2026 4:41 PM, Leo Yan wrote:
> Hi Jie,
>
Hi Leo,
> On Fri, Apr 17, 2026 at 09:01:17AM +0800, Jie Gan wrote:
>
> [...]
>
>> ... we still need support static trace ID allocation in parallel for
>> the dummy sources and we should not break this logic in future refactor.
>
> Just confirm what is the reason you need to use static trace ID for the
> dummy sources?
>
> I am wandering if we could use dev->devt as trace ID for dummy
> devices. Since the device's MAJOR number is non-zero and occupies the
> upper bits (see MINORBITS), it is naturally separated from the hardware
> trace ID range. If so, we even don't need to bother ID alloc/release.
>
The data frame is generated by the dummy source(static TPDM, or some
other static devices, connected to a funnel or replicator, or TPDA
device) automatically(contained pre-assigned trace ID) and the data
trace is enabled by default. What we should do for the dummy source is
enabling its connected port in driver for outputting the trace data to
the connected device(funnel/TPDA/replicator etc...).
For this scenario, we cannot dynamic allocate trace ID for the dummy
source device. Because it's pre-assigned during the hardware design.
Thanks,
Jie
> Thanks,
> Leo
^ permalink raw reply
* Re: [PATCH 3/5] media: synopsys: Add PHY stopstate wait for i.MX93
From: Frank Li @ 2026-04-17 8:51 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-3-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:54AM +0800, Guoniu Zhou wrote:
> Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
> ensures proper PHY initialization by verifying that the clock lane and
> all active data lanes have entered the stop state before proceeding with
> further operations.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
...
>
> +static int imx93_csi2rx_wait_for_phy_stopstate(struct dw_mipi_csi2rx_device *csi2)
> +{
> + struct device *dev = csi2->dev;
> + void __iomem *addr;
> + u32 stopstate_mask;
> + u32 val;
> + int ret;
> +
> + if (!dw_mipi_csi2rx_has_reg(csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE)) {
> + dev_err(dev, "phy_stopstate register not available\n");
> + return -ENXIO;
> + }
Needn't this check, you just implment this specfic callback for imx93, so
DW_MIPI_CSI2RX_PHY_STOPSTATE must be there.
> +
> + stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2->lanes_num - 1, 0);
> + addr = dw_mipi_csi2rx_get_regaddr(csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
> +
> + ret = readl_poll_timeout(addr, val, (val & stopstate_mask) != stopstate_mask,
> + 1000, 2000000);
There are dw_mipi_csi2rx_read() helper function. So you already use
read_poll_timeout(dw_mipi_csi2rx_read, ...)
Frank
^ permalink raw reply
* Re: [PATCH v2 1/1] reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
From: Philipp Zabel @ 2026-04-17 8:47 UTC (permalink / raw)
To: Robby Cai, Frank.Li, s.hauer, festevam
Cc: krzk+dt, andrew.smirnov, kernel, imx, linux-arm-kernel,
linux-kernel, aisheng.dong, guoniu.zhou
In-Reply-To: <20260417080851.489303-1-robby.cai@nxp.com>
On Fr, 2026-04-17 at 16:08 +0800, Robby Cai wrote:
> On i.MX8MQ, the MIPI CSI reset lines are active-low and not self-clearing.
> Writing '0' asserts reset and it remains asserted until explicitly
> deasserted by software.
>
> This driver previously treated the MIPI CSI reset signals as active-high,
> which led to incorrect reset assert/deassert sequencing. This issue was
> exposed by commit 6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly
> release reset").
If this patch is backported without 6d79bb8fd2aa, or the other way
around, will that break MIPI CSI-2 on older kernels? That would warrant
a Cc: stable tag.
Otherwise,
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: dts: bst: enable eMMC controller in C1200 CDCU1.0 board
From: gordon.ge @ 2026-04-17 8:47 UTC (permalink / raw)
To: yangzh0906
Cc: krzk, arnd, krzk+dt, robh, conor+dt, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260310091211.4171307-2-yangzh0906@thundersoft.com>
Acked-by: Gordon Ge <gordon.ge@bst.ai>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox