Skip to contentSkip to conversation

arm64: dts: rockchip: Add rk3576 evb2 board

PATCH Superseded Chaoyi Chen 7 participants 26 messages Jan 7 – Jan 8

Subsystems (2)

v2 of 5 Superseded Latest is v5 →

lore
Share & tools
lore
#0 lore raw

v2 cover arm64: dts: rockchip: Add rk3576 evb2 board

From: Chaoyi Chen <[email protected]>

Hi,

This series add support for rk3576 evb2 board.

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Changes in v2:
- Link to v1: https://lore.kernel.org/all/[email protected]/
- Enable hdmi_sound and sai6.
- Add more cpu-supply.
- Use regulator to control sata power.
- Remove "cap-mmc-highspeed" prop in sdmmc.
- Add regulator supply for ufshc.
- Add the missing vcc3v3_hubreset regulator.
- Add otg capability for usb_drd0_dwc3.

Chaoyi Chen (2):
dt-bindings: arm: rockchip: Add rk3576 evb2 board
arm64: dts: rockchip: Add rk3576 evb2 board

 .../devicetree/bindings/arm/rockchip.yaml     |   4 +-
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3576-evb2-v10.dts     | 997 ++++++++++++++++++
 3 files changed, 1001 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
Signature · 7 lines
2.51.1


_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
#1 lore raw

PATCH v2 1/2 dt-bindings: arm: rockchip: Add rk3576 evb2 board

From: Chaoyi Chen <[email protected]>

Add devicetree binding for the rk3576 evb2 board.

---

(no changes since v1)

 Documentation/devicetree/bindings/arm/rockchip.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/arm/rockchip.yaml +3 -1
index 6aceaa8acbb2..59ed57082003 100644
@@ -1136,7 +1136,9 @@ properties:
 
       - description: Rockchip RK3576 Evaluation board
         items:
-          - const: rockchip,rk3576-evb1-v10
+          - enum:
+              - rockchip,rk3576-evb1-v10
+              - rockchip,rk3576-evb2-v10
           - const: rockchip,rk3576
 
       - description: Rockchip RK3588 Evaluation board

--
2.51.1

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

#2 lore raw

PATCH v2 2/2 arm64: dts: rockchip: Add rk3576 evb2 board

In reply to Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

---

Changes in v2:
- Enable hdmi_sound and sai6.
- Add more cpu-supply.
- Use regulator to control sata power.
- Remove "cap-mmc-highspeed" prop in sdmmc.
- Add regulator supply for ufshc.
- Add the missing vcc3v3_hubreset regulator.
- Add otg capability for usb_drd0_dwc3.

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3576-evb2-v10.dts     | 997 ++++++++++++++++++
 2 files changed, 998 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
arch/arm64/boot/dts/rockchip/Makefile +1 -0
index c7617e06e1c1..cff95657d406 100644
@@ -153,6 +153,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb2-v10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-luckfox-omni3576.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-nanopi-m5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-roc-pc.dtb
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +997 -0

997 lines not on this page · raw message

Signature · 7 lines
2.51.1


_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
Reviewed-by on v2 2/2
#3 lore raw

Hi Chaoyi,

Quoted 141 lines · Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

---

Changes in v2:
- Enable hdmi_sound and sai6.
- Add more cpu-supply.
- Use regulator to control sata power.
- Remove "cap-mmc-highspeed" prop in sdmmc.
- Add regulator supply for ufshc.
- Add the missing vcc3v3_hubreset regulator.
- Add otg capability for usb_drd0_dwc3.

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3576-evb2-v10.dts     | 997 ++++++++++++++++++
 2 files changed, 998 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
arch/arm64/boot/dts/rockchip/Makefile +1 -0
index c7617e06e1c1..cff95657d406 100644
@@ -153,6 +153,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb2-v10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-luckfox-omni3576.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-nanopi-m5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-roc-pc.dtb
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +87 -0
new file mode 100644
index 000000000000..52788c514ec0
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3576.dtsi"
+
+/ {
+       model = "Rockchip RK3576 EVB2 V10 Board";
+       compatible = "rockchip,rk3576-evb2-v10", "rockchip,rk3576";
+
+       aliases {
+               ethernet0 = &gmac0;
+               ethernet1 = &gmac1;
+       };
+
+       chosen: chosen {
+               stdout-path = "serial0:1500000n8";
+       };
+
+       adc_keys: adc-keys {
+               compatible = "adc-keys";
+               io-channels = <&saradc 1>;
+               io-channel-names = "buttons";
+               keyup-threshold-microvolt = <1800000>;
+               poll-interval = <100>;
+
+               button-back {
+                       label = "back";
+                       linux,code = <KEY_BACK>;
+                       press-threshold-microvolt = <1235000>;
+               };
+
+               button-menu {
+                       label = "menu";
+                       linux,code = <KEY_MENU>;
+                       press-threshold-microvolt = <890000>;
+               };
+
+               button-vol-down {
+                       label = "volume down";
+                       linux,code = <KEY_VOLUMEDOWN>;
+                       press-threshold-microvolt = <417000>;
+               };
+
+               button-vol-up {
+                       label = "volume up";
+                       linux,code = <KEY_VOLUMEUP>;
+                       press-threshold-microvolt = <17000>;
+               };
+       };
+
+       hdmi-con {
+               compatible = "hdmi-connector";
+               type = "a";
+
+               port {
+                       hdmi_con_in: endpoint {
+                               remote-endpoint = <&hdmi_out_con>;
+                       };
+               };
+       };
+
+       leds: leds {
+               compatible = "gpio-leds";
+
+               work_led: led-0 {
+                       gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
+                       linux,default-trigger = "heartbeat";
+               };
+       };
+
+       sdio_pwrseq: sdio-pwrseq {
+               compatible = "mmc-pwrseq-simple";
+               pinctrl-names = "default";
+               pinctrl-0 = <&wifi_pwren>;
+
+               /*
+                * On the module itself this is one of these (depending
+                * on the actual card populated):

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 97

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+                * - SDIO_RESET_L_WL_REG_ON
+                * - PDN (power down when low)
+                */
+               post-power-on-delay-ms = <200>;
+               reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
+       };
+
+       vbus5v0_typec: regulator-vbus5v0-typec {
+               compatible = "regulator-fixed";
+               regulator-name = "vbus5v0_typec";

This might better be renamed, given that last time you mentioned this board doesn't have a Type-C connector. Perhaps regulator-vbus5v0-otg?

Quoted 33 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +33 -0
+               regulator-min-microvolt = <5000000>;
+               regulator-max-microvolt = <5000000>;
+               enable-active-high;
+               gpio = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
+               vin-supply = <&vcc5v0_device>;
+               pinctrl-names = "default";
+               pinctrl-0 = <&usb_otg0_pwren>;
+       };
+
+       vcc12v_dcin: regulator-vcc12v-dcin {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc12v_dcin";
+               regulator-always-on;
+               regulator-boot-on;
+               regulator-min-microvolt = <12000000>;
+               regulator-max-microvolt = <12000000>;
+       };
+
+       vcc1v2_ufs_vccq_s0: regulator-vcc1v2-ufs-vccq-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v2_ufs_vccq_s0";
+               regulator-boot-on;
+               regulator-always-on;
+               regulator-min-microvolt = <1200000>;
+               regulator-max-microvolt = <1200000>;
+               vin-supply = <&vcc_sys>;
+       };
+
+       vcc1v8_ufs_vccq2_s0: regulator-vcc1v8-ufs-vccq2-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v8_ufs_vccq2_s0";
+               regulator-boot-on;
+               regulator-always-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 140

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+               regulator-min-microvolt = <1800000>;
+               regulator-max-microvolt = <1800000>;
+               vin-supply = <&vcc_1v8_s3>;
+       };
+
+       vcc3v3_hubreset: vcc3v3-hubreset {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc3v3_hubreset";
+               regulator-boot-on;
+               regulator-always-on;

If this regulator supplies a soldered-on discrete hub and is required to power it up, won't it be better to describe the hub in the device tree (see binding at [1]), make the regulator its supply, and perhaps drop the "regulator-boot-on/regulator-always-on" annotation here, letting the regulator core deal with its enabling instead?

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml

[snip]

Other than these, LGTM - thanks for addressing my comments from v1! Feel free to include my:

Best regards,
Alexey

maintainer
#4 lore raw

Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:

Quoted 23 lines

Hi Chaoyi,

Quoted 20 lines · Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

[...]

Quoted 6 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 97

Quoted 3 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +3 -0
+       vbus5v0_typec: regulator-vbus5v0-typec {
+               compatible = "regulator-fixed";
+               regulator-name = "vbus5v0_typec";

This might better be renamed, given that last time you mentioned this board doesn't have a Type-C connector. Perhaps regulator-vbus5v0-otg?

Alternatively a comment above it.

I.e. regulator-naming should always follow the naming used in the schematics, so that it gets easier to reference between schematics and devicetree.

Quoted 50 lines
Quoted 33 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +33 -0
+               regulator-min-microvolt = <5000000>;
+               regulator-max-microvolt = <5000000>;
+               enable-active-high;
+               gpio = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
+               vin-supply = <&vcc5v0_device>;
+               pinctrl-names = "default";
+               pinctrl-0 = <&usb_otg0_pwren>;
+       };
+
+       vcc12v_dcin: regulator-vcc12v-dcin {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc12v_dcin";
+               regulator-always-on;
+               regulator-boot-on;
+               regulator-min-microvolt = <12000000>;
+               regulator-max-microvolt = <12000000>;
+       };
+
+       vcc1v2_ufs_vccq_s0: regulator-vcc1v2-ufs-vccq-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v2_ufs_vccq_s0";
+               regulator-boot-on;
+               regulator-always-on;
+               regulator-min-microvolt = <1200000>;
+               regulator-max-microvolt = <1200000>;
+               vin-supply = <&vcc_sys>;
+       };
+
+       vcc1v8_ufs_vccq2_s0: regulator-vcc1v8-ufs-vccq2-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v8_ufs_vccq2_s0";
+               regulator-boot-on;
+               regulator-always-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 140

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+               regulator-min-microvolt = <1800000>;
+               regulator-max-microvolt = <1800000>;
+               vin-supply = <&vcc_1v8_s3>;
+       };
+
+       vcc3v3_hubreset: vcc3v3-hubreset {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc3v3_hubreset";
+               regulator-boot-on;
+               regulator-always-on;

If this regulator supplies a soldered-on discrete hub and is required to power it up, won't it be better to describe the hub in the device tree (see binding at [1]), make the regulator its supply, and perhaps drop the "regulator-boot-on/regulator-always-on" annotation here, letting the regulator core deal with its enabling instead?

Quoted 1 line

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml

Yep, it would be nicer to it this way.
A live example can be found in the Rock 5 ITX [2]

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts#n1266

Heiko

Quoted 10 lines

[snip]

Other than these, LGTM - thanks for addressing my comments from v1! Feel free to include my:

Best regards,
Alexey

#5 lore raw

Hi Heiko,

Quoted 31 lines · Heiko Stübner

Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:

Quoted 23 lines

Hi Chaoyi,

Quoted 20 lines · Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

[...]

Quoted 4 lines
Quoted 3 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +3 -0
+       vbus5v0_typec: regulator-vbus5v0-typec {
+               compatible = "regulator-fixed";
+               regulator-name = "vbus5v0_typec";
Quoted 9 lines
Quoted 2 lines

This might better be renamed, given that last time you mentioned this board doesn't have a Type-C connector. Perhaps regulator-vbus5v0-otg?

Alternatively a comment above it.

I.e. regulator-naming should always follow the naming used in the schematics, so that it gets easier to reference between schematics and devicetree.

Thanks for the explanation. I will fix this in v3.

Quoted 51 lines
Quoted 51 lines
Quoted 34 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +33 -0
+               regulator-min-microvolt = <5000000>;
+               regulator-max-microvolt = <5000000>;
+               enable-active-high;
+               gpio = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
+               vin-supply = <&vcc5v0_device>;
+               pinctrl-names = "default";
+               pinctrl-0 = <&usb_otg0_pwren>;
+       };
+
+       vcc12v_dcin: regulator-vcc12v-dcin {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc12v_dcin";
+               regulator-always-on;
+               regulator-boot-on;
+               regulator-min-microvolt = <12000000>;
+               regulator-max-microvolt = <12000000>;
+       };
+
+       vcc1v2_ufs_vccq_s0: regulator-vcc1v2-ufs-vccq-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v2_ufs_vccq_s0";
+               regulator-boot-on;
+               regulator-always-on;
+               regulator-min-microvolt = <1200000>;
+               regulator-max-microvolt = <1200000>;
+               vin-supply = <&vcc_sys>;
+       };
+
+       vcc1v8_ufs_vccq2_s0: regulator-vcc1v8-ufs-vccq2-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v8_ufs_vccq2_s0";
+               regulator-boot-on;
+               regulator-always-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 140

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+               regulator-min-microvolt = <1800000>;
+               regulator-max-microvolt = <1800000>;
+               vin-supply = <&vcc_1v8_s3>;
+       };
+
+       vcc3v3_hubreset: vcc3v3-hubreset {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc3v3_hubreset";
+               regulator-boot-on;
+               regulator-always-on;

If this regulator supplies a soldered-on discrete hub and is required to power it up, won't it be better to describe the hub in the device tree (see binding at [1]), make the regulator its supply, and perhaps drop the "regulator-boot-on/regulator-always-on" annotation here, letting the regulator core deal with its enabling instead?

Quoted 6 lines
Quoted 1 line

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml

Yep, it would be nicer to it this way.
A live example can be found in the Rock 5 ITX [2]

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts#n1266

Thank you for the great example. BTW the hub used here is CH344. It looks like we need to add a new binding :)

Quoted 21 lines

Heiko

Quoted 10 lines

[snip]

Other than these, LGTM - thanks for addressing my comments from v1! Feel free to include my:

Best regards,
Alexey

Signature · 7 lines
Best, 
Chaoyi

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
#6 lore raw
Quoted 99 lines · Chaoyi Chen

Hi Heiko,

Quoted 31 lines · Heiko Stübner

Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:

Quoted 23 lines

Hi Chaoyi,

Quoted 20 lines · Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

[...]

Quoted 4 lines
Quoted 3 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +3 -0
+       vbus5v0_typec: regulator-vbus5v0-typec {
+               compatible = "regulator-fixed";
+               regulator-name = "vbus5v0_typec";
Quoted 9 lines
Quoted 2 lines

This might better be renamed, given that last time you mentioned this board doesn't have a Type-C connector. Perhaps regulator-vbus5v0-otg?

Alternatively a comment above it.

I.e. regulator-naming should always follow the naming used in the schematics, so that it gets easier to reference between schematics and devicetree.

Thanks for the explanation. I will fix this in v3.

Quoted 53 lines
Quoted 52 lines
Quoted 34 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +33 -0
+               regulator-min-microvolt = <5000000>;
+               regulator-max-microvolt = <5000000>;
+               enable-active-high;
+               gpio = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
+               vin-supply = <&vcc5v0_device>;
+               pinctrl-names = "default";
+               pinctrl-0 = <&usb_otg0_pwren>;
+       };
+
+       vcc12v_dcin: regulator-vcc12v-dcin {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc12v_dcin";
+               regulator-always-on;
+               regulator-boot-on;
+               regulator-min-microvolt = <12000000>;
+               regulator-max-microvolt = <12000000>;
+       };
+
+       vcc1v2_ufs_vccq_s0: regulator-vcc1v2-ufs-vccq-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v2_ufs_vccq_s0";
+               regulator-boot-on;
+               regulator-always-on;
+               regulator-min-microvolt = <1200000>;
+               regulator-max-microvolt = <1200000>;
+               vin-supply = <&vcc_sys>;
+       };
+
+       vcc1v8_ufs_vccq2_s0: regulator-vcc1v8-ufs-vccq2-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v8_ufs_vccq2_s0";
+               regulator-boot-on;
+               regulator-always-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 140

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+               regulator-min-microvolt = <1800000>;
+               regulator-max-microvolt = <1800000>;
+               vin-supply = <&vcc_1v8_s3>;
+       };
+
+       vcc3v3_hubreset: vcc3v3-hubreset {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc3v3_hubreset";
+               regulator-boot-on;
+               regulator-always-on;

If this regulator supplies a soldered-on discrete hub and is required to power it up, won't it be better to describe the hub in the device tree (see binding at [1]), make the regulator its supply, and perhaps drop the "regulator-boot-on/regulator-always-on" annotation here, letting the regulator core deal with its enabling instead?

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml

Quoted 8 lines
Quoted 4 lines

Yep, it would be nicer to it this way.
A live example can be found in the Rock 5 ITX [2]

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts#n1266

Thank you for the great example. BTW the hub used here is CH344. It looks like we need to add a new binding :)

Typo... It is WCH CH334.

Quoted 22 lines
Quoted 21 lines

Heiko

Quoted 10 lines

[snip]

Other than these, LGTM - thanks for addressing my comments from v1! Feel free to include my:

Best regards,
Alexey

Signature · 7 lines
Best, 
Chaoyi

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
maintainer
#7 lore raw

Am Mittwoch, 7. Januar 2026, 11:04:42 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:

Quoted 4 lines · Chaoyi Chen
Quoted 3 lines · Heiko Stübner
Quoted 2 lines

Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:

Quoted 1 line · Chaoyi Chen

[...]

Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 6 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 140

Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +5 -0
+       vcc3v3_hubreset: vcc3v3-hubreset {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc3v3_hubreset";
+               regulator-boot-on;
+               regulator-always-on;
Quoted 7 lines

If this regulator supplies a soldered-on discrete hub and is required to power it up, won't it be better to describe the hub in the device tree (see binding at [1]), make the regulator its supply, and perhaps drop the "regulator-boot-on/regulator-always-on" annotation here, letting the regulator core deal with its enabling instead?

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml

Yep, it would be nicer to it this way.
A live example can be found in the Rock 5 ITX [2]

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts#n1266

Thank you for the great example. BTW the hub used here is CH344. It looks like we need to add a new binding :)

Typo... It is WCH CH334.

I don't think you need a new compatible at all :-)

When you look at the usb-device.yaml linked above you'll the compatible already defined as a pattern:

compatible:
contains:
pattern: "^usb[0-9a-f]{1,4},[0-9a-f]{1,4}$"
description: Device nodes or combined nodes.
"usbVID,PID", where VID is the vendor id and PID the product id. The textual representation of VID and PID shall be in lower case hexadecimal with leading zeroes suppressed. The other compatible strings from the above standard binding could also be used, but a device adhering to this binding may leave out all except for "usbVID,PID".

Which will match everything VID + PID combination, so you just need to use the VID+PID from your hub.

Heiko

maintainer
#8 lore raw

Am Mittwoch, 7. Januar 2026, 15:54:47 Mitteleuropäische Normalzeit schrieb Heiko Stübner:

Quoted 27 lines

Am Mittwoch, 7. Januar 2026, 11:04:42 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:

Quoted 4 lines · Chaoyi Chen
Quoted 3 lines · Heiko Stübner
Quoted 2 lines

Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:

Quoted 1 line · Chaoyi Chen

[...]

Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 6 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 140

Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +5 -0
+       vcc3v3_hubreset: vcc3v3-hubreset {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc3v3_hubreset";
+               regulator-boot-on;
+               regulator-always-on;
Quoted 7 lines

If this regulator supplies a soldered-on discrete hub and is required to power it up, won't it be better to describe the hub in the device tree (see binding at [1]), make the regulator its supply, and perhaps drop the "regulator-boot-on/regulator-always-on" annotation here, letting the regulator core deal with its enabling instead?

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml

Yep, it would be nicer to it this way.
A live example can be found in the Rock 5 ITX [2]

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts#n1266

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

Thank you for the great example. BTW the hub used here is CH344. It looks like we need to add a new binding :)

Typo... It is WCH CH334.

I don't think you need a new compatible at all :-)

Please ignore everything I wrote :-)

I just looked farther into the usb bindings. So yes you'll probably need a binding for your hub.

Sorry about the noise
Heiko

Quoted 20 lines

When you look at the usb-device.yaml linked above you'll the compatible already defined as a pattern:

compatible:
contains:
pattern: "^usb[0-9a-f]{1,4},[0-9a-f]{1,4}$"
description: Device nodes or combined nodes.
"usbVID,PID", where VID is the vendor id and PID the product id. The textual representation of VID and PID shall be in lower case hexadecimal with leading zeroes suppressed. The other compatible strings from the above standard binding could also be used, but a device adhering to this binding may leave out all except for "usbVID,PID".

Which will match everything VID + PID combination, so you just need to use the VID+PID from your hub.

Heiko

#9 lore raw
In reply to Alexey Charkov

Hi Alexey,

Quoted 149 lines · Alexey Charkov

Hi Chaoyi,

Quoted 146 lines · Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

---

Changes in v2:
- Enable hdmi_sound and sai6.
- Add more cpu-supply.
- Use regulator to control sata power.
- Remove "cap-mmc-highspeed" prop in sdmmc.
- Add regulator supply for ufshc.
- Add the missing vcc3v3_hubreset regulator.
- Add otg capability for usb_drd0_dwc3.

 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3576-evb2-v10.dts     | 997 ++++++++++++++++++
 2 files changed, 998 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
arch/arm64/boot/dts/rockchip/Makefile +1 -0
index c7617e06e1c1..cff95657d406 100644
@@ -153,6 +153,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb2-v10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-luckfox-omni3576.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-nanopi-m5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-roc-pc.dtb
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +92 -0
new file mode 100644
index 000000000000..52788c514ec0
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3576.dtsi"
+
+/ {
+       model = "Rockchip RK3576 EVB2 V10 Board";
+       compatible = "rockchip,rk3576-evb2-v10", "rockchip,rk3576";
+
+       aliases {
+               ethernet0 = &gmac0;
+               ethernet1 = &gmac1;
+       };
+
+       chosen: chosen {
+               stdout-path = "serial0:1500000n8";
+       };
+
+       adc_keys: adc-keys {
+               compatible = "adc-keys";
+               io-channels = <&saradc 1>;
+               io-channel-names = "buttons";
+               keyup-threshold-microvolt = <1800000>;
+               poll-interval = <100>;
+
+               button-back {
+                       label = "back";
+                       linux,code = <KEY_BACK>;
+                       press-threshold-microvolt = <1235000>;
+               };
+
+               button-menu {
+                       label = "menu";
+                       linux,code = <KEY_MENU>;
+                       press-threshold-microvolt = <890000>;
+               };
+
+               button-vol-down {
+                       label = "volume down";
+                       linux,code = <KEY_VOLUMEDOWN>;
+                       press-threshold-microvolt = <417000>;
+               };
+
+               button-vol-up {
+                       label = "volume up";
+                       linux,code = <KEY_VOLUMEUP>;
+                       press-threshold-microvolt = <17000>;
+               };
+       };
+
+       hdmi-con {
+               compatible = "hdmi-connector";
+               type = "a";
+
+               port {
+                       hdmi_con_in: endpoint {
+                               remote-endpoint = <&hdmi_out_con>;
+                       };
+               };
+       };
+
+       leds: leds {
+               compatible = "gpio-leds";
+
+               work_led: led-0 {
+                       gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
+                       linux,default-trigger = "heartbeat";
+               };
+       };
+
+       sdio_pwrseq: sdio-pwrseq {
+               compatible = "mmc-pwrseq-simple";
+               pinctrl-names = "default";
+               pinctrl-0 = <&wifi_pwren>;
+
+               /*
+                * On the module itself this is one of these (depending
+                * on the actual card populated):
+                * - SDIO_RESET_L_WL_REG_ON
+                * - PDN (power down when low)
+                */
+               post-power-on-delay-ms = <200>;
+               reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
Quoted 9 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 97

Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +5 -0
+       };
+
+       vbus5v0_typec: regulator-vbus5v0-typec {
+               compatible = "regulator-fixed";
+               regulator-name = "vbus5v0_typec";

This might better be renamed, given that last time you mentioned this board doesn't have a Type-C connector. Perhaps regulator-vbus5v0-otg?

Sorry, I missed this part. I will fix it in v3.

Quoted 50 lines
Quoted 33 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +33 -0
+               regulator-min-microvolt = <5000000>;
+               regulator-max-microvolt = <5000000>;
+               enable-active-high;
+               gpio = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
+               vin-supply = <&vcc5v0_device>;
+               pinctrl-names = "default";
+               pinctrl-0 = <&usb_otg0_pwren>;
+       };
+
+       vcc12v_dcin: regulator-vcc12v-dcin {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc12v_dcin";
+               regulator-always-on;
+               regulator-boot-on;
+               regulator-min-microvolt = <12000000>;
+               regulator-max-microvolt = <12000000>;
+       };
+
+       vcc1v2_ufs_vccq_s0: regulator-vcc1v2-ufs-vccq-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v2_ufs_vccq_s0";
+               regulator-boot-on;
+               regulator-always-on;
+               regulator-min-microvolt = <1200000>;
+               regulator-max-microvolt = <1200000>;
+               vin-supply = <&vcc_sys>;
+       };
+
+       vcc1v8_ufs_vccq2_s0: regulator-vcc1v8-ufs-vccq2-s0 {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc1v8_ufs_vccq2_s0";
+               regulator-boot-on;
+               regulator-always-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 140

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+               regulator-min-microvolt = <1800000>;
+               regulator-max-microvolt = <1800000>;
+               vin-supply = <&vcc_1v8_s3>;
+       };
+
+       vcc3v3_hubreset: vcc3v3-hubreset {
+               compatible = "regulator-fixed";
+               regulator-name = "vcc3v3_hubreset";
+               regulator-boot-on;
+               regulator-always-on;

If this regulator supplies a soldered-on discrete hub and is required to power it up, won't it be better to describe the hub in the device tree (see binding at [1]), make the regulator its supply, and perhaps drop the "regulator-boot-on/regulator-always-on" annotation here, letting the regulator core deal with its enabling instead?

Quoted 1 line

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml

Yes. I will try to do this in v3. Thank you!

Quoted 12 lines

[snip]

Other than these, LGTM - thanks for addressing my comments from v1! Feel free to include my:

Best regards,
Alexey

Signature · 7 lines
Best, 
Chaoyi

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
#10 lore raw
In reply to Chaoyi Chen

Hi Chaoyi,

On 1/7/26 8:03 AM, Chaoyi Chen wrote:
[...]

Quoted 20 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +14 -0
new file mode 100644
index 000000000000..52788c514ec0
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3576.dtsi"
+

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 24

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+/ {
+	model = "Rockchip RK3576 EVB2 V10 Board";
+	compatible = "rockchip,rk3576-evb2-v10", "rockchip,rk3576";
+
+	aliases {
+		ethernet0 = &gmac0;
+		ethernet1 = &gmac1;
+	};
+
+	chosen: chosen {

Why a label here?

There are also many other instances of nodes being labelled but whose label is never used. I would understand for some if you want to have DTSOs working with this DTB, but here chosen really doesn't make much sense to me?

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 28

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +4 -0
+		stdout-path = "serial0:1500000n8";
+	};
+
+	adc_keys: adc-keys {

Are we expecting to extend this node from another DT? Why the label?

Won't comment on all other labeled-but-no-phandle-use instances, please check.

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 175

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+	vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_rtc_s5";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;

If this is for the rtc, shouldn't we declare this dependency in the RTC device node and not have it always-on?

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 183

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+	};
+
+	vcc3v3_sata_pwren: vcc3v3-sata-pwren {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sata_pwren";
+		enable-active-high;
+		regulator-boot-on;
+		regulator-always-on;

Why do we have this always-on? Seems like we're missing a dependency on this regulator in the SATA controller?

Quoted 19 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +19 -0
+		gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&satapm_pwren>;
+	};
+
+	vcc5v0_device: regulator-vcc5v0-device {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_device";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_host: regulator-vcc5v0-host {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 212

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren>;
+	};
+

I assume both of the above are related to USB operating in host or device mode? Maybe there's a way to have something more useful to the user in regulator-name (and possibly the regulator node name) so that they have an idea what this pertains to?

Additionally, why is this always-on? I would assume the USB controller is capable of controlling its regulator(s)?

[...]

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 263

Quoted 1 line
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +1 -0
+	vcc_ufs_s0: regulator-vcc-ufs-s0 {

We also have another regulator for UFS that is mentioned in the UFS controller node but not this one, why?

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 267

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +4 -0
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_ufs_s0";
+		regulator-boot-on;
+		regulator-always-on;

Why always on?

[...]

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 762

Quoted 3 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +3 -0
+&mdio0 {
+	rgmii_phy0: ethernet-phy@1 {
+		compatible = "ethernet-phy-id4f51.e91b";

Is MDIO auto-detection broken such that you need to specify the PHY vendor and product id? Which PHY is that? Why can't you use c22 or c45 compatible? A comment would be nice.

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 774

Quoted 12 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +12 -0
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rgmii_phy0_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PD3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&mdio1 {
+	rgmii_phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-id4f51.e91b";

Ditto.

[...]

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 892

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +4 -0
+&sdhci {
+	bus-width = <8>;
+	full-pwr-cycle-in-suspend;
+	max-frequency = <200000000>;

Already that value in rk3576.dtsi.

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 905

Quoted 13 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +13 -0
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	no-sdio;
+	no-sd;
+	non-removable;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <200000000>;

Already that value in rk3576.dtsi.

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 913

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+	no-sdio;
+	no-mmc;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&saradc {

This is not alphabetically sorted, it should be before &sata0.

[...]

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 955

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&hym8563>;
+		clock-names = "lpo";
+		device-wakeup-gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB1 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-0 = <&bt_reg_on &bt_wake_host &host_wake_bt>;
+		pinctrl-names = "default";
+		shutdown-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_HIGH>;

Is this GPIO only controlling Bluetooth or also WiFi? I've seen a few combo chips where there's a common GPIO that controls both WiFi and Bluetooth. Making this bluetooth-specific means we need Bluetooth on for WiFi to work, a bit unexpected and should probably be modeled another way.

Cheers,
Quentin

#11 lore raw

Hi Quentin,

Thank you for your patient review.

Quoted 37 lines · Quentin Schulz

Hi Chaoyi,

On 1/7/26 8:03 AM, Chaoyi Chen wrote:
[...]

Quoted 20 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +14 -0
new file mode 100644
index 000000000000..52788c514ec0
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3576.dtsi"
+

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 24

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+/ {
+    model = "Rockchip RK3576 EVB2 V10 Board";
+    compatible = "rockchip,rk3576-evb2-v10", "rockchip,rk3576";
+
+    aliases {
+        ethernet0 = &gmac0;
+        ethernet1 = &gmac1;
+    };
+
+    chosen: chosen {

Why a label here?

Quoted 2 lines

There are also many other instances of nodes being labelled but whose label is never used. I would understand for some if you want to have DTSOs working with this DTB, but here chosen really doesn't make much sense to me?

Hmm, I will delete them in v3.

Quoted 9 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 28

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +4 -0
+        stdout-path = "serial0:1500000n8";
+    };
+
+    adc_keys: adc-keys {

Are we expecting to extend this node from another DT? Why the label?

Won't comment on all other labeled-but-no-phandle-use instances, please check.

I think one exception is the regulator labels. Even though their phandles are unused, they match the names on the schematic, so it seems meaningful to keep them.

Quoted 11 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 175

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc3v3_rtc_s5";
+        regulator-boot-on;
+        regulator-always-on;
+        regulator-min-microvolt = <3300000>;
+        regulator-max-microvolt = <3300000>;
+        vin-supply = <&vcc_sys>;

If this is for the rtc, shouldn't we declare this dependency in the RTC device node and not have it always-on?

I checked other boards that use the hym8563 device and couldn't find a similar approach. Could you give an example?

Quoted 11 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 183

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    };
+
+    vcc3v3_sata_pwren: vcc3v3-sata-pwren {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc3v3_sata_pwren";
+        enable-active-high;
+        regulator-boot-on;
+        regulator-always-on;

Why do we have this always-on? Seems like we're missing a dependency on this regulator in the SATA controller?

In v1 we set the pinctrl inside the SATA node. To keep the pins from being reused by mistake we added this regulator in v2.

Quoted 23 lines
Quoted 23 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +23 -0
+        gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&satapm_pwren>;
+    };
+
+    vcc5v0_device: regulator-vcc5v0-device {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_device";
+        regulator-always-on;
+        regulator-boot-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        vin-supply = <&vcc12v_dcin>;
+    };
+
+    vcc5v0_host: regulator-vcc5v0-host {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_host";
+        regulator-boot-on;
+        regulator-always-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        enable-active-high;
Quoted 8 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 212

Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +6 -0
+        gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+        vin-supply = <&vcc5v0_device>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&usb_host_pwren>;
+    };
+

I assume both of the above are related to USB operating in host or device mode? Maybe there's a way to have something more useful to the user in regulator-name (and possibly the regulator node name) so that they have an idea what this pertains to?

It's a good idea. Actually, we have two regulators here, one for USB0 and another for USB1. I'll try to rename them in v2.

Quoted 3 lines

Additionally, why is this always-on? I would assume the USB controller is capable of controlling its regulator(s)?

Oh, it should be remove.

Quoted 5 lines

[...]

Quoted 1 line

+ vcc_ufs_s0: regulator-vcc-ufs-s0 {

We also have another regulator for UFS that is mentioned in the UFS controller node but not this one, why?

I rechecked the schematic, and found that this regulator should be set to vcc-supply. You are right, thank you!

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 267

Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +4 -0
+        compatible = "regulator-fixed";
+        regulator-name = "vcc_ufs_s0";
+        regulator-boot-on;
+        regulator-always-on;

Why always on?

[...]

This is related to the hardware design. The power rail is always on in hardware.

Quoted 6 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts

Quoted 3 lines

+&mdio0 {

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +2 -0
+    rgmii_phy0: ethernet-phy@1 {
+        compatible = "ethernet-phy-id4f51.e91b";

Is MDIO auto-detection broken such that you need to specify the PHY vendor and product id? Which PHY is that? Why can't you use c22 or c45 compatible? A comment would be nice.

No, c22 compatible also works. I will use it in v3.

Quoted 15 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 774

Quoted 12 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +12 -0
+        reg = <0x1>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&rgmii_phy0_rst>;
+        reset-assert-us = <20000>;
+        reset-deassert-us = <100000>;
+        reset-gpios = <&gpio3 RK_PD3 GPIO_ACTIVE_LOW>;
+    };
+};
+
+&mdio1 {
+    rgmii_phy1: ethernet-phy@1 {
+        compatible = "ethernet-phy-id4f51.e91b";

Ditto.

Quoted 9 lines

[...]

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 892

Quoted 4 lines

+&sdhci {

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +3 -0
+    bus-width = <8>;
+    full-pwr-cycle-in-suspend;
+    max-frequency = <200000000>;

Already that value in rk3576.dtsi.

I will drop them in v3.

Quoted 7 lines
Quoted 7 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +7 -0
+    mmc-hs400-1_8v;
+    mmc-hs400-enhanced-strobe;
+    no-sdio;
+    no-sd;
+    non-removable;
+    status = "okay";
+};
Quoted 9 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 905

Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +6 -0
+
+&sdmmc {
+    bus-width = <4>;
+    cap-sd-highspeed;
+    disable-wp;
+    max-frequency = <200000000>;

Already that value in rk3576.dtsi.

I will drop them in v3.

Quoted 11 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 913

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    no-sdio;
+    no-mmc;
+    sd-uhs-sdr104;
+    vqmmc-supply = <&vccio_sd_s0>;
+    status = "okay";
+};
+
+&saradc {

This is not alphabetically sorted, it should be before &sata0.

Quoted 2 lines

[...]

Oh, that's true. I will fix it in v3.

Quoted 11 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 955

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+    bluetooth {
+        compatible = "brcm,bcm43438-bt";
+        clocks = <&hym8563>;
+        clock-names = "lpo";
+        device-wakeup-gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
+        interrupt-parent = <&gpio0>;
+        interrupts = <RK_PB1 IRQ_TYPE_LEVEL_HIGH>;
+        pinctrl-0 = <&bt_reg_on &bt_wake_host &host_wake_bt>;
+        pinctrl-names = "default";
+        shutdown-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_HIGH>;
Quoted 1 line

Is this GPIO only controlling Bluetooth or also WiFi? I've seen a few combo chips where there's a common GPIO that controls both WiFi and Bluetooth. Making this bluetooth-specific means we need Bluetooth on for WiFi to work, a bit unexpected and should probably be modeled another way.

No. BT and Wi-Fi functions are controlled by two separate sets of GPIOs.

Signature · 7 lines
Best, 
Chaoyi

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
#12 lore raw

Hi Chaoyi,

Quoted 8 lines · Chaoyi Chen

Hi Quentin,

Thank you for your patient review.

Quoted 3 lines · Quentin Schulz

Hi Chaoyi,

On 1/7/26 8:03 AM, Chaoyi Chen wrote:

[...]

Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +4 -0
+        stdout-path = "serial0:1500000n8";
+    };
+
+    adc_keys: adc-keys {
Quoted 9 lines
Quoted 4 lines

Are we expecting to extend this node from another DT? Why the label?

Won't comment on all other labeled-but-no-phandle-use instances, please check.

I think one exception is the regulator labels. Even though their phandles are unused, they match the names on the schematic, so it seems meaningful to keep them.

Can't you use the regulator-name property for that? Or a comment if you realllly want it to be somewhere in the DTS? If I remember correctly, labels make it to the DTB when building it with symbols (-@, enabled whenever there's a DTSO for the board; see __symbols__ node when decompiling), this will unnecessarily bloat the final DTB.

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc3v3_rtc_s5";
+        regulator-boot-on;
+        regulator-always-on;
+        regulator-min-microvolt = <3300000>;
+        regulator-max-microvolt = <3300000>;
+        vin-supply = <&vcc_sys>;
Quoted 6 lines
Quoted 2 lines

If this is for the rtc, shouldn't we declare this dependency in the RTC device node and not have it always-on?

I checked other boards that use the hym8563 device and couldn't find a similar approach. Could you give an example?

If this is truly always on by hardware design, then I guess it's "fine". That other boards aren't doing isn't much of an argument, as they may not need it. Typically, you could need to update the driver (and its binding) to accept and control power supplies so that you can link the two together in the device tree. I'm assuming for an RTC it doesn't make much sense to have its power supply controllable as it likely needs to be powered even when the device is turned off (otherwise the RTC stops counting :) ).

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    };
+
+    vcc3v3_sata_pwren: vcc3v3-sata-pwren {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc3v3_sata_pwren";
+        enable-active-high;
+        regulator-boot-on;
+        regulator-always-on;
Quoted 6 lines
Quoted 2 lines

Why do we have this always-on? Seems like we're missing a dependency on this regulator in the SATA controller?

In v1 we set the pinctrl inside the SATA node. To keep the pins from being reused by mistake we added this regulator in v2.

This is a controllable regulator, which seems to be dedicated to SATA (from the name of it). Why isn't it something that the SATA controller controls?

You have ahci-supply, target-supply and phy-supply in ahci-common.yaml DT binding that may be appropriate for this regulator.

The issue is if this regulator is probed *after* your SATA device, SATA probably won't work. Imagine REGULATOR_FIXED_VOLTAGE=m (or even =n, but then you likely have other issues) and your SATA controller driver is built-in, this will be broken.

Remove the always-on and set the proper link in the SATA controller device node so that this is handled properly.

Quoted 32 lines
Quoted 23 lines
Quoted 23 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +23 -0
+        gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&satapm_pwren>;
+    };
+
+    vcc5v0_device: regulator-vcc5v0-device {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_device";
+        regulator-always-on;
+        regulator-boot-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        vin-supply = <&vcc12v_dcin>;
+    };
+
+    vcc5v0_host: regulator-vcc5v0-host {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_host";
+        regulator-boot-on;
+        regulator-always-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        enable-active-high;
Quoted 8 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 212

Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +6 -0
+        gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+        vin-supply = <&vcc5v0_device>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&usb_host_pwren>;
+    };
+

I assume both of the above are related to USB operating in host or device mode? Maybe there's a way to have something more useful to the user in regulator-name (and possibly the regulator node name) so that they have an idea what this pertains to?

Quoted 3 lines

It's a good idea. Actually, we have two regulators here, one for USB0 and another for USB1. I'll try to rename them in v2.

Are you sure? vcc5v0_device is a supply for vcc5v0_host, so it'd be odd that in order for USB1 to work, you need USB0 powered?

[...]

Cheers,
Quentin

#13 lore raw

Hi Quentin,

Quoted 24 lines · Quentin Schulz

Hi Chaoyi,

Quoted 8 lines · Chaoyi Chen

Hi Quentin,

Thank you for your patient review.

Quoted 3 lines · Quentin Schulz

Hi Chaoyi,

On 1/7/26 8:03 AM, Chaoyi Chen wrote:

[...]

Quoted 10 lines
Quoted 9 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 28

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +4 -0
+        stdout-path = "serial0:1500000n8";
+    };
+
+    adc_keys: adc-keys {

Are we expecting to extend this node from another DT? Why the label?

Won't comment on all other labeled-but-no-phandle-use instances, please check.

Quoted 7 lines
Quoted 4 lines

I think one exception is the regulator labels. Even though their phandles are unused, they match the names on the schematic, so it seems meaningful to keep them.

Can't you use the regulator-name property for that? Or a comment if you realllly want it to be somewhere in the DTS? If I remember correctly, labels make it to the DTB when building it with symbols (-@, enabled whenever there's a DTSO for the board; see __symbols__ node when decompiling), this will unnecessarily bloat the final DTB.

Oh, it make sense.

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc3v3_rtc_s5";
+        regulator-boot-on;
+        regulator-always-on;
+        regulator-min-microvolt = <3300000>;
+        regulator-max-microvolt = <3300000>;
+        vin-supply = <&vcc_sys>;
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines

If this is for the rtc, shouldn't we declare this dependency in the RTC device node and not have it always-on?

I checked other boards that use the hym8563 device and couldn't find a similar approach. Could you give an example?

If this is truly always on by hardware design, then I guess it's "fine". That other boards aren't doing isn't much of an argument, as they may not need it. Typically, you could need to update the driver (and its binding) to accept and control power supplies so that you can link the two together in the device tree. I'm assuming for an RTC it doesn't make much sense to have its power supply controllable as it likely needs to be powered even when the device is turned off (otherwise the RTC stops counting :) ).

Yes, this seems unnecessary, which is why I'm asking if you've encountered similar designs before.

Quoted 12 lines
Quoted 12 lines
Quoted 11 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 183

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    };
+
+    vcc3v3_sata_pwren: vcc3v3-sata-pwren {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc3v3_sata_pwren";
+        enable-active-high;
+        regulator-boot-on;
+        regulator-always-on;

Why do we have this always-on? Seems like we're missing a dependency on this regulator in the SATA controller?

Quoted 8 lines
Quoted 3 lines

In v1 we set the pinctrl inside the SATA node. To keep the pins from being reused by mistake we added this regulator in v2.

This is a controllable regulator, which seems to be dedicated to SATA (from the name of it). Why isn't it something that the SATA controller controls?

You have ahci-supply, target-supply and phy-supply in ahci-common.yaml DT binding that may be appropriate for this regulator.

Thank you for provide these info. I will try to add them in v3.

Quoted 4 lines

The issue is if this regulator is probed *after* your SATA device, SATA probably won't work. Imagine REGULATOR_FIXED_VOLTAGE=m (or even =n, but then you likely have other issues) and your SATA controller driver is built-in, this will be broken.

Remove the always-on and set the proper link in the SATA controller device node so that this is handled properly.

Oh! I did overlook that point! I will try to do it in v3.

Quoted 32 lines
Quoted 32 lines
Quoted 31 lines
Quoted 19 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +19 -0
+        gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&satapm_pwren>;
+    };
+
+    vcc5v0_device: regulator-vcc5v0-device {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_device";
+        regulator-always-on;
+        regulator-boot-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        vin-supply = <&vcc12v_dcin>;
+    };
+
+    vcc5v0_host: regulator-vcc5v0-host {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_host";
+        regulator-boot-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 212

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+        regulator-always-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        enable-active-high;
+        gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+        vin-supply = <&vcc5v0_device>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&usb_host_pwren>;
+    };
+

I assume both of the above are related to USB operating in host or device mode? Maybe there's a way to have something more useful to the user in regulator-name (and possibly the regulator node name) so that they have an idea what this pertains to?

Quoted 5 lines
Quoted 3 lines

It's a good idea. Actually, we have two regulators here, one for USB0 and another for USB1. I'll try to rename them in v2.

Are you sure? vcc5v0_device is a supply for vcc5v0_host, so it'd be odd that in order for USB1 to work, you need USB0 powered?

No, the "vcc5v0_device" serves as the vin-supply for both "VCC5V0_USB3_HOST0" and "VCC5V0_USB3_HOST1".
And "VCC5V0_USB3_HOSTx" is supply for USB VBUS.

All the names marked here are those shown in the schematic. As you suggested, it would be better to set regulator-name to the schematic name "VCC5V0_USB3_HOSTx" and use "usbx_vbus" for the label.

Signature · 2 lines
Best, 
Chaoyi
#14 lore raw

Hi Chaoyi,

Quoted 14 lines · Chaoyi Chen

Hi Quentin,

Quoted 11 lines · Quentin Schulz

Hi Chaoyi,

Quoted 8 lines · Chaoyi Chen

Hi Quentin,

Thank you for your patient review.

Quoted 3 lines · Quentin Schulz

Hi Chaoyi,

On 1/7/26 8:03 AM, Chaoyi Chen wrote:

[...]

Quoted 16 lines
Quoted 16 lines
Quoted 15 lines
Quoted 11 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 175

Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +8 -0
+    vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc3v3_rtc_s5";
+        regulator-boot-on;
+        regulator-always-on;
+        regulator-min-microvolt = <3300000>;
+        regulator-max-microvolt = <3300000>;
+        vin-supply = <&vcc_sys>;

If this is for the rtc, shouldn't we declare this dependency in the RTC device node and not have it always-on?

I checked other boards that use the hym8563 device and couldn't find a similar approach. Could you give an example?

Quoted 6 lines
Quoted 2 lines

If this is truly always on by hardware design, then I guess it's "fine". That other boards aren't doing isn't much of an argument, as they may not need it. Typically, you could need to update the driver (and its binding) to accept and control power supplies so that you can link the two together in the device tree. I'm assuming for an RTC it doesn't make much sense to have its power supply controllable as it likely needs to be powered even when the device is turned off (otherwise the RTC stops counting :) ).

Yes, this seems unnecessary, which is why I'm asking if you've encountered similar designs before.

I think it's fine for me. It's not a controllable regulator and its parent supply (and the parent supply of that supply) all are always-on as well and non-configurable so there cannot be a way for this to not be on. Please ignore this comment.

[...]

Quoted 38 lines
Quoted 32 lines
Quoted 32 lines
Quoted 31 lines
Quoted 19 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +19 -0
+        gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&satapm_pwren>;
+    };
+
+    vcc5v0_device: regulator-vcc5v0-device {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_device";
+        regulator-always-on;
+        regulator-boot-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        vin-supply = <&vcc12v_dcin>;
+    };
+
+    vcc5v0_host: regulator-vcc5v0-host {
+        compatible = "regulator-fixed";
+        regulator-name = "vcc5v0_host";
+        regulator-boot-on;

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 212

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+        regulator-always-on;
+        regulator-min-microvolt = <5000000>;
+        regulator-max-microvolt = <5000000>;
+        enable-active-high;
+        gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+        vin-supply = <&vcc5v0_device>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&usb_host_pwren>;
+    };
+

I assume both of the above are related to USB operating in host or device mode? Maybe there's a way to have something more useful to the user in regulator-name (and possibly the regulator node name) so that they have an idea what this pertains to?

Quoted 5 lines
Quoted 3 lines

It's a good idea. Actually, we have two regulators here, one for USB0 and another for USB1. I'll try to rename them in v2.

Are you sure? vcc5v0_device is a supply for vcc5v0_host, so it'd be odd that in order for USB1 to work, you need USB0 powered?

Quoted 8 lines

No, the "vcc5v0_device" serves as the vin-supply for both "VCC5V0_USB3_HOST0" and "VCC5V0_USB3_HOST1".
And "VCC5V0_USB3_HOSTx" is supply for USB VBUS.

All the names marked here are those shown in the schematic. As you suggested, it would be better to set regulator-name to the schematic name "VCC5V0_USB3_HOSTx" and use "usbx_vbus" for the label.

Yes, that does make sense to me.

Cheers,
Quentin

#15 lore raw
In reply to Chaoyi Chen

Review

Quoted 3 lines

+&gmac0 {

(quoted diff) +2 -0
+	clock_in_out = "output";
+	phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Andrew

#16 lore raw
Quoted 9 lines · Andrew Lunn

Review

Quoted 4 lines

+&gmac0 {

(quoted diff) +2 -0
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay duration introduced by a single delay element in GMAC-IOMUX delay lines, which are controlled in the GMAC driver by the {tx,rx}_delay properties. Maybe we could then switch to using {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side as envisaged in DT bindings [1], and use phy-mode = "rgmii-id" throughout. Chaoyi, any chance you could ask around in your hardware team?

Currently though removing the delays at GMAC side altogether causes unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Best regards,
Alexey

#17 lore raw

Hello Alexey, Andrew,

Quoted 20 lines · Alexey Charkov
Quoted 9 lines · Andrew Lunn

Review

Quoted 4 lines

+&gmac0 {

(quoted diff) +2 -0
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay duration introduced by a single delay element in GMAC-IOMUX delay lines, which are controlled in the GMAC driver by the {tx,rx}_delay properties. Maybe we could then switch to using {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side as envisaged in DT bindings [1], and use phy-mode = "rgmii-id" throughout. Chaoyi, any chance you could ask around in your hardware team?

Quoted 5 lines

Currently though removing the delays at GMAC side altogether causes unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Sorry, this problem has been discussed many times before. It's because the gmac on the Rockchip platform currently relies on setting the corresponding delay via phy-mode [3].

[3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/

The delay introduced by the delay line is not absolute. In reality, it depends on factors such as the chip's design and process technology.

And for RK3576, you can assume that:

	time(ns) = 0.0579 * delay_line_count + 0.105

For example, tx_delay = <0x20> means:

	time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns

And I believe {tx,rx}_internal_delay_ps is indeed a good idea. I'll try to add them in v3. Thanks.

Signature · 7 lines
Best, 
Chaoyi

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
#18 lore raw
Quoted 40 lines · Chaoyi Chen

Hello Alexey, Andrew,

Quoted 20 lines · Alexey Charkov
Quoted 9 lines · Andrew Lunn

Review

Quoted 4 lines

+&gmac0 {

(quoted diff) +2 -0
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay duration introduced by a single delay element in GMAC-IOMUX delay lines, which are controlled in the GMAC driver by the {tx,rx}_delay properties. Maybe we could then switch to using {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side as envisaged in DT bindings [1], and use phy-mode = "rgmii-id" throughout. Chaoyi, any chance you could ask around in your hardware team?

Quoted 5 lines

Currently though removing the delays at GMAC side altogether causes unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Sorry, this problem has been discussed many times before. It's because the gmac on the Rockchip platform currently relies on setting the corresponding delay via phy-mode [3].

[3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/

The delay introduced by the delay line is not absolute. In reality, it depends on factors such as the chip's design and process technology.

And for RK3576, you can assume that:

Quoted 9 lines
	time(ns) = 0.0579 * delay_line_count + 0.105

For example, tx_delay = <0x20> means:

	time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns

And I believe {tx,rx}_internal_delay_ps is indeed a good idea. I'll try to add them in v3. Thanks.

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY, and compared to doing it in the MAC, which one is the better choice?

Signature · 8 lines
Best, 
Chaoyi


_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
#19 lore raw
Quoted 46 lines · Chaoyi Chen
Quoted 44 lines · Chaoyi Chen

Hello Alexey, Andrew,

Quoted 20 lines · Alexey Charkov
Quoted 9 lines · Andrew Lunn

Review

Quoted 4 lines

+&gmac0 {

(quoted diff) +2 -0
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay duration introduced by a single delay element in GMAC-IOMUX delay lines, which are controlled in the GMAC driver by the {tx,rx}_delay properties. Maybe we could then switch to using {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side as envisaged in DT bindings [1], and use phy-mode = "rgmii-id" throughout. Chaoyi, any chance you could ask around in your hardware team?

Quoted 5 lines

Currently though removing the delays at GMAC side altogether causes unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Sorry, this problem has been discussed many times before. It's because the gmac on the Rockchip platform currently relies on setting the corresponding delay via phy-mode [3].

[3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/

The delay introduced by the delay line is not absolute. In reality, it depends on factors such as the chip's design and process technology.

And for RK3576, you can assume that:

      time(ns) = 0.0579 * delay_line_count + 0.105

For example, tx_delay = <0x20> means:

Quoted 8 lines
Quoted 5 lines
      time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns

And I believe {tx,rx}_internal_delay_ps is indeed a good idea. I'll try to add them in v3. Thanks.

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY, and compared to doing it in the MAC, which one is the better choice?

Your PHY defaults to 1950ps in rgmii-id [1], so adding anything on top of that on GMAC side would land you with a longer total TX delay than you currently get according to the coefficients you've just posted (1784.1ps). I would say go for "tx-internal-delay-ps = <1800>" on the PHY side for the closest match.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

Best regards,
Alexey

#20 lore raw
Quoted 56 lines · Alexey Charkov
Quoted 46 lines · Chaoyi Chen
Quoted 44 lines · Chaoyi Chen

Hello Alexey, Andrew,

Quoted 20 lines · Alexey Charkov
Quoted 9 lines · Andrew Lunn

Review

Quoted 4 lines

+&gmac0 {

(quoted diff) +2 -0
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay duration introduced by a single delay element in GMAC-IOMUX delay lines, which are controlled in the GMAC driver by the {tx,rx}_delay properties. Maybe we could then switch to using {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side as envisaged in DT bindings [1], and use phy-mode = "rgmii-id" throughout. Chaoyi, any chance you could ask around in your hardware team?

Quoted 5 lines

Currently though removing the delays at GMAC side altogether causes unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Sorry, this problem has been discussed many times before. It's because the gmac on the Rockchip platform currently relies on setting the corresponding delay via phy-mode [3].

[3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/

The delay introduced by the delay line is not absolute. In reality, it depends on factors such as the chip's design and process technology.

And for RK3576, you can assume that:

      time(ns) = 0.0579 * delay_line_count + 0.105

For example, tx_delay = <0x20> means:

Quoted 8 lines
Quoted 5 lines
      time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns

And I believe {tx,rx}_internal_delay_ps is indeed a good idea. I'll try to add them in v3. Thanks.

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY, and compared to doing it in the MAC, which one is the better choice?

Quoted 7 lines

Your PHY defaults to 1950ps in rgmii-id [1], so adding anything on top of that on GMAC side would land you with a longer total TX delay than you currently get according to the coefficients you've just posted (1784.1ps). I would say go for "tx-internal-delay-ps = <1800>" on the PHY side for the closest match.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

Ah, I thought it was something like this:

&gmac0 {
	phy-mode = "rgmii";
	tx-internal-delay-ps = <1784>;
};

But what you actually said was this:

&mdio1 {
	rgmii_phy: ethernet-phy@1 {
		compatible = "ethernet-phy-ieee802.3-c22";
		reg = <0x1>;
		tx-internal-delay-ps = <1784>;
	};
};

These two tx-internal-delay-ps things shouldn't be the same, right?

Signature · 2 lines
Best, 
Chaoyi
#21 lore raw
Quoted 64 lines · Chaoyi Chen
Quoted 62 lines · Alexey Charkov
Quoted 46 lines · Chaoyi Chen
Quoted 44 lines · Chaoyi Chen

Hello Alexey, Andrew,

Quoted 20 lines · Alexey Charkov
Quoted 9 lines · Andrew Lunn

Review

Quoted 4 lines

+&gmac0 {

(quoted diff) +2 -0
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay duration introduced by a single delay element in GMAC-IOMUX delay lines, which are controlled in the GMAC driver by the {tx,rx}_delay properties. Maybe we could then switch to using {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side as envisaged in DT bindings [1], and use phy-mode = "rgmii-id" throughout. Chaoyi, any chance you could ask around in your hardware team?

Quoted 5 lines

Currently though removing the delays at GMAC side altogether causes unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Sorry, this problem has been discussed many times before. It's because the gmac on the Rockchip platform currently relies on setting the corresponding delay via phy-mode [3].

[3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/

The delay introduced by the delay line is not absolute. In reality, it depends on factors such as the chip's design and process technology.

And for RK3576, you can assume that:

      time(ns) = 0.0579 * delay_line_count + 0.105

For example, tx_delay = <0x20> means:

Quoted 8 lines
Quoted 5 lines
      time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns

And I believe {tx,rx}_internal_delay_ps is indeed a good idea. I'll try to add them in v3. Thanks.

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY, and compared to doing it in the MAC, which one is the better choice?

Your PHY defaults to 1950ps in rgmii-id [1], so adding anything on top of that on GMAC side would land you with a longer total TX delay than you currently get according to the coefficients you've just posted (1784.1ps). I would say go for "tx-internal-delay-ps = <1800>" on the PHY side for the closest match.

Quoted 6 lines
Quoted 1 line

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

Ah, I thought it was something like this:

&gmac0 {
        phy-mode = "rgmii";

phy-mode = "rgmii-id";

Quoted 1 line
        tx-internal-delay-ps = <1784>;

Drop this, as recommended in the lengthy note at the bottom of the binding doc [1] (the GMAC shouldn't be adding a delay that is close to 2ns).

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L354

Quoted 5 lines

};

But what you actually said was this:

&mdio1 {

&mdio0 I guess (but same applies to gmac1+mdio1)

Quoted 4 lines
        rgmii_phy: ethernet-phy@1 {
                compatible = "ethernet-phy-ieee802.3-c22";
                reg = <0x1>;
                tx-internal-delay-ps = <1784>;

The PHY binding [2] says it can't accept arbitrary values here - only 150ps increments. So you'll need either 1650 or 1800 to get close to your calculated value above.

[2] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

Quoted 4 lines
        };
};

These two tx-internal-delay-ps things shouldn't be the same, right?

They add up, which you don't need in this case AFAICT.

Best regards,
Alexey

#22 lore raw
Quoted 99 lines · Alexey Charkov
Quoted 64 lines · Chaoyi Chen
Quoted 62 lines · Alexey Charkov
Quoted 46 lines · Chaoyi Chen
Quoted 44 lines · Chaoyi Chen

Hello Alexey, Andrew,

Quoted 20 lines · Alexey Charkov
Quoted 9 lines · Andrew Lunn

Review

Quoted 4 lines

+&gmac0 {

(quoted diff) +2 -0
+     clock_in_out = "output";
+     phy-mode = "rgmii-rxid";

rgmii-rxid is odd. Does the PCB really have an extra long TX clock line, but a short RX clock line?

Try changing this to rgmii-id, and drop the tx_delay property.

Actually it would be great if Rockchip could clarify the delay duration introduced by a single delay element in GMAC-IOMUX delay lines, which are controlled in the GMAC driver by the {tx,rx}_delay properties. Maybe we could then switch to using {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side as envisaged in DT bindings [1], and use phy-mode = "rgmii-id" throughout. Chaoyi, any chance you could ask around in your hardware team?

Quoted 5 lines

Currently though removing the delays at GMAC side altogether causes unstable link operation - see [2] for example.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
[2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c

Sorry, this problem has been discussed many times before. It's because the gmac on the Rockchip platform currently relies on setting the corresponding delay via phy-mode [3].

[3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/

The delay introduced by the delay line is not absolute. In reality, it depends on factors such as the chip's design and process technology.

And for RK3576, you can assume that:

      time(ns) = 0.0579 * delay_line_count + 0.105

For example, tx_delay = <0x20> means:

Quoted 8 lines
Quoted 5 lines
      time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns

And I believe {tx,rx}_internal_delay_ps is indeed a good idea. I'll try to add them in v3. Thanks.

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY, and compared to doing it in the MAC, which one is the better choice?

Your PHY defaults to 1950ps in rgmii-id [1], so adding anything on top of that on GMAC side would land you with a longer total TX delay than you currently get according to the coefficients you've just posted (1784.1ps). I would say go for "tx-internal-delay-ps = <1800>" on the PHY side for the closest match.

Quoted 6 lines
Quoted 1 line

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

Ah, I thought it was something like this:

&gmac0 {
        phy-mode = "rgmii";

phy-mode = "rgmii-id";

Quoted 1 line
        tx-internal-delay-ps = <1784>;

Drop this, as recommended in the lengthy note at the bottom of the binding doc [1] (the GMAC shouldn't be adding a delay that is close to 2ns).

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L354

Quoted 5 lines

};

But what you actually said was this:

&mdio1 {

&mdio0 I guess (but same applies to gmac1+mdio1)

Quoted 4 lines
        rgmii_phy: ethernet-phy@1 {
                compatible = "ethernet-phy-ieee802.3-c22";
                reg = <0x1>;
                tx-internal-delay-ps = <1784>;

The PHY binding [2] says it can't accept arbitrary values here - only 150ps increments. So you'll need either 1650 or 1800 to get close to your calculated value above.

Quoted 9 lines

[2] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

Quoted 4 lines
        };
};

These two tx-internal-delay-ps things shouldn't be the same, right?

They add up, which you don't need in this case AFAICT.

Ah, got it. Thank you for the clarification :)

Signature · 2 lines
Best, 
Chaoyi
#23 lore raw
In reply to Chaoyi Chen
Quoted 2 lines

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY, and compared to doing it in the MAC, which one is the better choice?

As pointed out in another email, we prefer the PHY does the delay. That preference is to try to make all Linux systems the same.

And since the required delay is so close to the standard 2ns, you should just say rgmii-id, and let the PHY add the RGMII standard required 2ns, and it should just work, no need for any other DT properties.

Andrew

#24 lore raw
In reply to Chaoyi Chen

Hello Chaoyi,

Quoted 65 lines · Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

---

Changes in v2:
- Enable hdmi_sound and sai6.
- Add more cpu-supply.
- Use regulator to control sata power.
- Remove "cap-mmc-highspeed" prop in sdmmc.
- Add regulator supply for ufshc.
- Add the missing vcc3v3_hubreset regulator.
- Add otg capability for usb_drd0_dwc3.

arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3576-evb2-v10.dts | 997 ++++++++++++++++++

2 files changed, 998 insertions(+)

create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts

arch/arm64/boot/dts/rockchip/Makefile +0 -0
index c7617e06e1c1..cff95657d406 100644
@@ -153,6 +153,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo

dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb2-v10.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-luckfox-omni3576.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-nanopi-m5.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-roc-pc.dtb

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +12 -0
new file mode 100644
index 000000000000..52788c514ec0
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 22

Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +10 -0
+#include "rk3576.dtsi"
+
+/ {
+	model = "Rockchip RK3576 EVB2 V10 Board";
+	compatible = "rockchip,rk3576-evb2-v10", "rockchip,rk3576";
+
+	aliases {
+		ethernet0 = &gmac0;
+		ethernet1 = &gmac1;
+	};

I suggest also add aliases for sdmmc and sdhci here as other boards do, so these two storage devices will get fixed label on boot, this will make things easier for set root=/dev/mmcblkXpn in cmdline.

Quoted 983 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +975 -0
+
+	chosen: chosen {
+		stdout-path = "serial0:1500000n8";
+	};
+
+	adc_keys: adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 1>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-back {
+			label = "back";
+			linux,code = <KEY_BACK>;
+			press-threshold-microvolt = <1235000>;
+		};
+
+		button-menu {
+			label = "menu";
+			linux,code = <KEY_MENU>;
+			press-threshold-microvolt = <890000>;
+		};
+
+		button-vol-down {
+			label = "volume down";
+			linux,code = <KEY_VOLUMEDOWN>;
+			press-threshold-microvolt = <417000>;
+		};
+
+		button-vol-up {
+			label = "volume up";
+			linux,code = <KEY_VOLUMEUP>;
+			press-threshold-microvolt = <17000>;
+		};
+	};
+
+	hdmi-con {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+
+		work_led: led-0 {
+			gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_pwren>;
+
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
+	};
+
+	vbus5v0_typec: regulator-vbus5v0-typec {
+		compatible = "regulator-fixed";
+		regulator-name = "vbus5v0_typec";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_otg0_pwren>;
+	};
+
+	vcc12v_dcin: regulator-vcc12v-dcin {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc1v2_ufs_vccq_s0: regulator-vcc1v2-ufs-vccq-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v2_ufs_vccq_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc1v8_ufs_vccq2_s0: regulator-vcc1v8-ufs-vccq2-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v8_ufs_vccq2_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8_s3>;
+	};
+
+	vcc3v3_hubreset: vcc3v3-hubreset {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_hubreset";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_hub_reset>;
+	};
+
+	vcc3v3_lcd_n: regulator-vcc3v3-lcd0-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd0_n";
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc_3v3_s0>;
+	};
+
+	vcc3v3_pcie1: regulator-vcc3v3-pcie1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie1";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+		gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_rtc_s5";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc3v3_sata_pwren: vcc3v3-sata-pwren {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sata_pwren";
+		enable-active-high;
+		regulator-boot-on;
+		regulator-always-on;
+		gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&satapm_pwren>;
+	};
+
+	vcc5v0_device: regulator-vcc5v0-device {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_device";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_host: regulator-vcc5v0-host {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren>;
+	};
+
+	vcc_sys: regulator-vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc_1v8_s0: regulator-vcc-1v8-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v8_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8_s3>;
+	};
+
+	vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_2v0_pldo_s3";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <2000000>;
+		regulator-max-microvolt = <2000000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc_3v3_s0: regulator-vcc-3v3-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc_ufs_s0: regulator-vcc-ufs-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_ufs_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy1_psu {
+	status = "okay";
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-mode = "rgmii-rxid";
+	phy-handle = <&rgmii_phy0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&eth0m1_miim
+		     &eth0m1_tx_bus2
+		     &eth0m1_rx_bus2
+		     &eth0m1_rgmii_clk
+		     &eth0m1_rgmii_bus>;
+	tx_delay = <0x1d>;
+	status = "okay";
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy1>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-names = "default";
+	pinctrl-0 = <&eth1m0_miim
+		     &eth1m0_tx_bus2
+		     &eth1m0_rx_bus2
+		     &eth1m0_rgmii_clk
+		     &eth1m0_rgmii_bus>;
+	tx_delay = <0x1e>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu_s0>;
+	status = "okay";
+};
+
+&hdmi {
+	status = "okay";
+};
+
+&hdmi_in {
+	hdmi_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi>;
+	};
+};
+
+&hdmi_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <&hdmi_con_in>;
+	};
+};
+
+&hdmi_sound {
+	status = "okay";
+};
+
+&hdptxphy {
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+
+	rk806: pmic@23 {
+		compatible = "rockchip,rk806";
+		reg = <0x23>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		system-power-controller;
+
+		vcc1-supply = <&vcc_sys>;
+		vcc2-supply = <&vcc_sys>;
+		vcc3-supply = <&vcc_sys>;
+		vcc4-supply = <&vcc_sys>;
+		vcc5-supply = <&vcc_sys>;
+		vcc6-supply = <&vcc_sys>;
+		vcc7-supply = <&vcc_sys>;
+		vcc8-supply = <&vcc_sys>;
+		vcc9-supply = <&vcc_sys>;
+		vcc10-supply = <&vcc_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc_sys>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs1_slp: dvs1-slp-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs1_pwrdn: dvs1-pwrdn-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs1_rst: dvs1-rst-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs2_slp: dvs2-slp-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs2_pwrdn: dvs2-pwrdn-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs2_rst: dvs2-rst-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs2_dvs: dvs2-dvs-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun4";
+		};
+
+		rk806_dvs2_gpio: dvs2-gpio-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun5";
+		};
+
+		rk806_dvs3_slp: dvs3-slp-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs3_pwrdn: dvs3-pwrdn-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs3_rst: dvs3-rst-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs3_dvs: dvs3-dvs-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun4";
+		};
+
+		rk806_dvs3_gpio: dvs3-gpio-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun5";
+		};
+
+		regulators {
+			vdd_cpu_big_s0: dcdc-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_big_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_npu_s0: dcdc-reg2 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_npu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vdd_gpu_s0: dcdc-reg5 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_logic_s0: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <800000>;
+				regulator-name = "vdd_logic_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pldo2_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_pldo2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "vdda_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcca_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdda_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v75_hdmi_s0: nldo-reg3 {
+				regulator-boot-on;
+				regulator-min-microvolt = <837500>;
+				regulator-max-microvolt = <837500>;
+				regulator-name = "vdda0v75_hdmi_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdda_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdda_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	hym8563: rtc@51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		clock-output-names = "hym8563";
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA5 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int>;
+		wakeup-source;
+		#clock-cells = <0>;
+	};
+};
+
+&mdio0 {
+	rgmii_phy0: ethernet-phy@1 {
+		compatible = "ethernet-phy-id4f51.e91b";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rgmii_phy0_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PD3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&mdio1 {
+	rgmii_phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-id4f51.e91b";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rgmii_phy1_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PD6 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pinctrl {
+	bluetooth {
+		bt_reg_on: bt-reg-on {
+			rockchip,pins = <1 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		bt_wake_host: bt-wake-host {
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		host_wake_bt: host-wake-bt {
+			rockchip,pins = <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	hym8563 {
+		rtc_int: rtc-int {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	network {
+		rgmii_phy0_rst: rgmii-phy0-rst {
+			rockchip,pins = <3 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		rgmii_phy1_rst: rgmii-phy1-rst {
+			rockchip,pins = <3 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie1 {
+		pcie1_rst: pcie1-rst {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sata {
+		satapm_pwren: satapm-pwren {
+			rockchip,pins = <4 RK_PC7 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+
+	usb {
+		usb_host_pwren: usb-host-pwren {
+			rockchip,pins = <0 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_hub_reset: usb-hub-reset {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_otg0_pwren: usb-otg0-pwren {
+			rockchip,pins = <0 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		wifi_host_wake: wifi-host-wake {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		wifi_pwren: wifi-pwren {
+			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
+&sai6 {
+	status = "okay";
+};
+
+&sata0 {
+	status = "okay";
+};
+
+&sdio {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	disable-wp;
+	keep-power-in-suspend;
+	max-frequency = <150000000>;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	no-sd;
+	no-mmc;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc1m0_bus4 &sdmmc1m0_clk &sdmmc1m0_cmd>;
+	sd-uhs-sdr104;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "host-wake";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_host_wake>;
+	};
+};
+
+&sdhci {
+	bus-width = <8>;
+	full-pwr-cycle-in-suspend;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	no-sdio;
+	no-sd;
+	non-removable;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <200000000>;
+	no-sdio;
+	no-mmc;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca_1v8_s0>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+};
+
+&u2phy0_otg {
+	phy-supply = <&vbus5v0_typec>;
+	status = "okay";
+};
+
+&u2phy1 {
+	status = "okay";
+};
+
+&u2phy1_otg {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-0 = <&uart4m1_xfer &uart4m1_ctsn &uart4m1_rtsn>;
+	pinctrl-names = "default";
+	uart-has-rtscts;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&hym8563>;
+		clock-names = "lpo";
+		device-wakeup-gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB1 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-0 = <&bt_reg_on &bt_wake_host &host_wake_bt>;
+		pinctrl-names = "default";
+		shutdown-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_HIGH>;
+		vbat-supply = <&vcc_3v3_s3>;
+		vddio-supply = <&vcc_1v8_s3>;
+	};
+};
+
+&ufshc {
+	vcc-supply = <&vcc_3v3_s0>;
+	vccq-supply = <&vcc1v2_ufs_vccq_s0>;
+	vccq2-supply = <&vcc1v8_ufs_vccq2_s0>;
+	status = "okay";
+};
+
+&usbdp_phy {
+	rockchip,dp-lane-mux = <2 3>;
+	status = "okay";
+};
+
+&usb_drd0_dwc3 {
+	dr_mode = "otg";
+	extcon = <&u2phy0>;
+	status = "okay";
+};
+
+&usb_drd1_dwc3 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&vop {
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
+&vp0 {
+	vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi_in_vp0>;
+	};
+};
Signature · 7 lines
2.51.1


_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

#25 lore raw

Hello Andy,

Quoted 75 lines · Andy Yan

Hello Chaoyi,

Quoted 70 lines · Chaoyi Chen

From: Chaoyi Chen <[email protected]>

General features for rk3576 evb2 board:
- Rockchip RK3576
- LPDDR4/4X
- eMMC5.1
- RK806-2x2pcs + DiscretePower
- 1x HDMI2.1 TX / HDMI2.0 RX
- 1x full size DP1.4 TX (Only 2 Lanes)
- 2x 10/100/1000M Ethernet
- 5x SATA3.0 7Pin Slot
- 2x USB3.2 Gen1 Host
- 3x USB2.0 Host
- WIFI/BT
- ...

Tested with eMMC/SDMMC/HDMI/USB/Ethernet/WIFI/BT module.

---

Changes in v2:
- Enable hdmi_sound and sai6.
- Add more cpu-supply.
- Use regulator to control sata power.
- Remove "cap-mmc-highspeed" prop in sdmmc.
- Add regulator supply for ufshc.
- Add the missing vcc3v3_hubreset regulator.
- Add otg capability for usb_drd0_dwc3.

arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3576-evb2-v10.dts | 997 ++++++++++++++++++

2 files changed, 998 insertions(+)

create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts

arch/arm64/boot/dts/rockchip/Makefile +0 -0
index c7617e06e1c1..cff95657d406 100644
@@ -153,6 +153,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo

dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb2-v10.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-luckfox-omni3576.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-nanopi-m5.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-roc-pc.dtb

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +17 -0
new file mode 100644
index 000000000000..52788c514ec0
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3576.dtsi"
+
+/ {
+	model = "Rockchip RK3576 EVB2 V10 Board";
+	compatible = "rockchip,rk3576-evb2-v10", "rockchip,rk3576";
Quoted 9 lines

arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts line 22

Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +5 -0
+
+	aliases {
+		ethernet0 = &gmac0;
+		ethernet1 = &gmac1;
+	};

I suggest also add aliases for sdmmc and sdhci here as other boards do, so these two storage devices will get fixed label on boot, this will make things easier for set root=/dev/mmcblkXpn in cmdline.

That make sense. I will add them in v3.

Quoted 983 lines
Quoted 983 lines
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts new file +975 -0
+
+	chosen: chosen {
+		stdout-path = "serial0:1500000n8";
+	};
+
+	adc_keys: adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 1>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-back {
+			label = "back";
+			linux,code = <KEY_BACK>;
+			press-threshold-microvolt = <1235000>;
+		};
+
+		button-menu {
+			label = "menu";
+			linux,code = <KEY_MENU>;
+			press-threshold-microvolt = <890000>;
+		};
+
+		button-vol-down {
+			label = "volume down";
+			linux,code = <KEY_VOLUMEDOWN>;
+			press-threshold-microvolt = <417000>;
+		};
+
+		button-vol-up {
+			label = "volume up";
+			linux,code = <KEY_VOLUMEUP>;
+			press-threshold-microvolt = <17000>;
+		};
+	};
+
+	hdmi-con {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+
+		work_led: led-0 {
+			gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_pwren>;
+
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
+	};
+
+	vbus5v0_typec: regulator-vbus5v0-typec {
+		compatible = "regulator-fixed";
+		regulator-name = "vbus5v0_typec";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_otg0_pwren>;
+	};
+
+	vcc12v_dcin: regulator-vcc12v-dcin {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc1v2_ufs_vccq_s0: regulator-vcc1v2-ufs-vccq-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v2_ufs_vccq_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc1v8_ufs_vccq2_s0: regulator-vcc1v8-ufs-vccq2-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v8_ufs_vccq2_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8_s3>;
+	};
+
+	vcc3v3_hubreset: vcc3v3-hubreset {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_hubreset";
+		regulator-boot-on;
+		regulator-always-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_hub_reset>;
+	};
+
+	vcc3v3_lcd_n: regulator-vcc3v3-lcd0-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd0_n";
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc_3v3_s0>;
+	};
+
+	vcc3v3_pcie1: regulator-vcc3v3-pcie1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_pcie1";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+		gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <5000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_rtc_s5";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc3v3_sata_pwren: vcc3v3-sata-pwren {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sata_pwren";
+		enable-active-high;
+		regulator-boot-on;
+		regulator-always-on;
+		gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&satapm_pwren>;
+	};
+
+	vcc5v0_device: regulator-vcc5v0-device {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_device";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_host: regulator-vcc5v0-host {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren>;
+	};
+
+	vcc_sys: regulator-vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc_1v8_s0: regulator-vcc-1v8-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v8_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8_s3>;
+	};
+
+	vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_2v0_pldo_s3";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <2000000>;
+		regulator-max-microvolt = <2000000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc_3v3_s0: regulator-vcc-3v3-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_3v3_s3>;
+	};
+
+	vcc_ufs_s0: regulator-vcc-ufs-s0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_ufs_s0";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy1_psu {
+	status = "okay";
+};
+
+&gmac0 {
+	clock_in_out = "output";
+	phy-mode = "rgmii-rxid";
+	phy-handle = <&rgmii_phy0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&eth0m1_miim
+		     &eth0m1_tx_bus2
+		     &eth0m1_rx_bus2
+		     &eth0m1_rgmii_clk
+		     &eth0m1_rgmii_bus>;
+	tx_delay = <0x1d>;
+	status = "okay";
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy1>;
+	phy-mode = "rgmii-rxid";
+	pinctrl-names = "default";
+	pinctrl-0 = <&eth1m0_miim
+		     &eth1m0_tx_bus2
+		     &eth1m0_rx_bus2
+		     &eth1m0_rgmii_clk
+		     &eth1m0_rgmii_bus>;
+	tx_delay = <0x1e>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu_s0>;
+	status = "okay";
+};
+
+&hdmi {
+	status = "okay";
+};
+
+&hdmi_in {
+	hdmi_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi>;
+	};
+};
+
+&hdmi_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <&hdmi_con_in>;
+	};
+};
+
+&hdmi_sound {
+	status = "okay";
+};
+
+&hdptxphy {
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+
+	rk806: pmic@23 {
+		compatible = "rockchip,rk806";
+		reg = <0x23>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		system-power-controller;
+
+		vcc1-supply = <&vcc_sys>;
+		vcc2-supply = <&vcc_sys>;
+		vcc3-supply = <&vcc_sys>;
+		vcc4-supply = <&vcc_sys>;
+		vcc5-supply = <&vcc_sys>;
+		vcc6-supply = <&vcc_sys>;
+		vcc7-supply = <&vcc_sys>;
+		vcc8-supply = <&vcc_sys>;
+		vcc9-supply = <&vcc_sys>;
+		vcc10-supply = <&vcc_sys>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc_sys>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc_sys>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs1_slp: dvs1-slp-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs1_pwrdn: dvs1-pwrdn-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs1_rst: dvs1-rst-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs2_slp: dvs2-slp-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs2_pwrdn: dvs2-pwrdn-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs2_rst: dvs2-rst-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs2_dvs: dvs2-dvs-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun4";
+		};
+
+		rk806_dvs2_gpio: dvs2-gpio-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun5";
+		};
+
+		rk806_dvs3_slp: dvs3-slp-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun1";
+		};
+
+		rk806_dvs3_pwrdn: dvs3-pwrdn-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun2";
+		};
+
+		rk806_dvs3_rst: dvs3-rst-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun3";
+		};
+
+		rk806_dvs3_dvs: dvs3-dvs-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun4";
+		};
+
+		rk806_dvs3_gpio: dvs3-gpio-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun5";
+		};
+
+		regulators {
+			vdd_cpu_big_s0: dcdc-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_big_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_npu_s0: dcdc-reg2 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_npu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: dcdc-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_cpu_lit_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vcc_3v3_s3: dcdc-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_3v3_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vdd_gpu_s0: dcdc-reg5 {
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+				regulator-name = "vdd_gpu_s0";
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vddq_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_logic_s0: dcdc-reg7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <800000>;
+				regulator-name = "vdd_logic_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vdd2_ddr_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg10 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "vdd_ddr_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_1v8_s0: pldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca_1v8_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pldo2_s0: pldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_pldo2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_1v2_s0: pldo-reg3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "vdda_1v2_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_3v3_s0: pldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcca_3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_sd_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pldo6_s3: pldo-reg6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_pldo6_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdd_0v75_s3";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_ddr_pll_s0: nldo-reg2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdda_ddr_pll_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v75_hdmi_s0: nldo-reg3 {
+				regulator-boot-on;
+				regulator-min-microvolt = <837500>;
+				regulator-max-microvolt = <837500>;
+				regulator-name = "vdda0v75_hdmi_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v85_s0: nldo-reg4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-name = "vdda_0v85_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v75_s0: nldo-reg5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+				regulator-name = "vdda_0v75_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	hym8563: rtc@51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		clock-output-names = "hym8563";
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA5 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int>;
+		wakeup-source;
+		#clock-cells = <0>;
+	};
+};
+
+&mdio0 {
+	rgmii_phy0: ethernet-phy@1 {
+		compatible = "ethernet-phy-id4f51.e91b";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rgmii_phy0_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PD3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&mdio1 {
+	rgmii_phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-id4f51.e91b";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rgmii_phy1_rst>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PD6 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pinctrl {
+	bluetooth {
+		bt_reg_on: bt-reg-on {
+			rockchip,pins = <1 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		bt_wake_host: bt-wake-host {
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		host_wake_bt: host-wake-bt {
+			rockchip,pins = <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	hym8563 {
+		rtc_int: rtc-int {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	network {
+		rgmii_phy0_rst: rgmii-phy0-rst {
+			rockchip,pins = <3 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		rgmii_phy1_rst: rgmii-phy1-rst {
+			rockchip,pins = <3 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie1 {
+		pcie1_rst: pcie1-rst {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sata {
+		satapm_pwren: satapm-pwren {
+			rockchip,pins = <4 RK_PC7 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+
+	usb {
+		usb_host_pwren: usb-host-pwren {
+			rockchip,pins = <0 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_hub_reset: usb-hub-reset {
+			rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_otg0_pwren: usb-otg0-pwren {
+			rockchip,pins = <0 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		wifi_host_wake: wifi-host-wake {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		wifi_pwren: wifi-pwren {
+			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
+&sai6 {
+	status = "okay";
+};
+
+&sata0 {
+	status = "okay";
+};
+
+&sdio {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	disable-wp;
+	keep-power-in-suspend;
+	max-frequency = <150000000>;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	no-sd;
+	no-mmc;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc1m0_bus4 &sdmmc1m0_clk &sdmmc1m0_cmd>;
+	sd-uhs-sdr104;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "host-wake";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_host_wake>;
+	};
+};
+
+&sdhci {
+	bus-width = <8>;
+	full-pwr-cycle-in-suspend;
+	max-frequency = <200000000>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	no-sdio;
+	no-sd;
+	non-removable;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <200000000>;
+	no-sdio;
+	no-mmc;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca_1v8_s0>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+};
+
+&u2phy0_otg {
+	phy-supply = <&vbus5v0_typec>;
+	status = "okay";
+};
+
+&u2phy1 {
+	status = "okay";
+};
+
+&u2phy1_otg {
+	phy-supply = <&vcc5v0_host>;
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-0 = <&uart4m1_xfer &uart4m1_ctsn &uart4m1_rtsn>;
+	pinctrl-names = "default";
+	uart-has-rtscts;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&hym8563>;
+		clock-names = "lpo";
+		device-wakeup-gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB1 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-0 = <&bt_reg_on &bt_wake_host &host_wake_bt>;
+		pinctrl-names = "default";
+		shutdown-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_HIGH>;
+		vbat-supply = <&vcc_3v3_s3>;
+		vddio-supply = <&vcc_1v8_s3>;
+	};
+};
+
+&ufshc {
+	vcc-supply = <&vcc_3v3_s0>;
+	vccq-supply = <&vcc1v2_ufs_vccq_s0>;
+	vccq2-supply = <&vcc1v8_ufs_vccq2_s0>;
+	status = "okay";
+};
+
+&usbdp_phy {
+	rockchip,dp-lane-mux = <2 3>;
+	status = "okay";
+};
+
+&usb_drd0_dwc3 {
+	dr_mode = "otg";
+	extcon = <&u2phy0>;
+	status = "okay";
+};
+
+&usb_drd1_dwc3 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&vop {
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
+&vp0 {
+	vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi_in_vp0>;
+	};
+};
Signature · 7 lines
2.51.1


_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
Signature · 2 lines
Best, 
Chaoyi