* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 7:03 ` [PATCH v2 2/2] arm64: dts: " Chaoyi Chen
@ 2026-01-07 7:56 ` Alexey Charkov
2026-01-07 8:21 ` Heiko Stübner
2026-01-07 9:50 ` Chaoyi Chen
2026-01-07 15:46 ` Quentin Schulz
` (2 subsequent siblings)
3 siblings, 2 replies; 26+ messages in thread
From: Alexey Charkov @ 2026-01-07 7:56 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz, Chaoyi Chen, Kever Yang, Jonas Karlman,
John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Hi Chaoyi,
On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@airkyi.com> wrote:
>
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> 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.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> ---
>
> 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
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index c7617e06e1c1..cff95657d406 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -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
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
> new file mode 100644
> index 000000000000..52788c514ec0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
> @@ -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>;
> + };
> +
> + 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?
> + 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;
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:
Reviewed-by: Alexey Charkov <alchark@gmail.com>
Best regards,
Alexey
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 7:56 ` Alexey Charkov
@ 2026-01-07 8:21 ` Heiko Stübner
2026-01-07 9:57 ` Chaoyi Chen
2026-01-07 9:50 ` Chaoyi Chen
1 sibling, 1 reply; 26+ messages in thread
From: Heiko Stübner @ 2026-01-07 8:21 UTC (permalink / raw)
To: Chaoyi Chen, Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Quentin Schulz,
Chaoyi Chen, Kever Yang, Jonas Karlman, John Clark, FUKAUMI Naoki,
Jimmy Hon, Dragan Simic, Michael Riesch, Peter Robinson,
Shawn Lin, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
> Hi Chaoyi,
>
> On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@airkyi.com> wrote:
> >
> > From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> >
> > 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.
> >
> > Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
[...]
> > + 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.
> > + 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;
>
> 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
Heiko
> [snip]
>
> Other than these, LGTM - thanks for addressing my comments from v1!
> Feel free to include my:
>
> Reviewed-by: Alexey Charkov <alchark@gmail.com>
>
> Best regards,
> Alexey
>
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 8:21 ` Heiko Stübner
@ 2026-01-07 9:57 ` Chaoyi Chen
2026-01-07 10:04 ` Chaoyi Chen
0 siblings, 1 reply; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-07 9:57 UTC (permalink / raw)
To: Heiko Stübner, Chaoyi Chen, Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Quentin Schulz,
Kever Yang, Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon,
Dragan Simic, Michael Riesch, Peter Robinson, Shawn Lin,
Sebastian Reichel, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
Hi Heiko,
On 1/7/2026 4:21 PM, Heiko Stübner wrote:
> Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
>> Hi Chaoyi,
>>
>> On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@airkyi.com> wrote:
>>>
>>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>>
>>> 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.
>>>
>>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> [...]
>
>>> + 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.
>
Thanks for the explanation. I will fix this in v3.
>
>>> + 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;
>>
>> 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
Thank you for the great example. BTW the hub used here is CH344. It
looks like we need to add a new binding :)
>
>
> Heiko
>
>
>> [snip]
>>
>> Other than these, LGTM - thanks for addressing my comments from v1!
>> Feel free to include my:
>>
>> Reviewed-by: Alexey Charkov <alchark@gmail.com>
>>
>> Best regards,
>> Alexey
>>
>
>
>
>
>
>
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 9:57 ` Chaoyi Chen
@ 2026-01-07 10:04 ` Chaoyi Chen
2026-01-07 14:54 ` Heiko Stübner
0 siblings, 1 reply; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-07 10:04 UTC (permalink / raw)
To: Heiko Stübner, Chaoyi Chen, Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Quentin Schulz,
Kever Yang, Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon,
Dragan Simic, Michael Riesch, Peter Robinson, Shawn Lin,
Sebastian Reichel, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
On 1/7/2026 5:57 PM, Chaoyi Chen wrote:
> Hi Heiko,
>
> On 1/7/2026 4:21 PM, Heiko Stübner wrote:
>> Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
>>> Hi Chaoyi,
>>>
>>> On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@airkyi.com> wrote:
>>>>
>>>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>>>
>>>> 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.
>>>>
>>>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> [...]
>>
>>>> + 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.
>>
>
> Thanks for the explanation. I will fix this in v3.
>
>>
>>>> + 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;
>>>
>>> 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
>
> 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.
>>
>>
>> Heiko
>>
>>
>>> [snip]
>>>
>>> Other than these, LGTM - thanks for addressing my comments from v1!
>>> Feel free to include my:
>>>
>>> Reviewed-by: Alexey Charkov <alchark@gmail.com>
>>>
>>> Best regards,
>>> Alexey
>>>
>>
>>
>>
>>
>>
>>
>
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 10:04 ` Chaoyi Chen
@ 2026-01-07 14:54 ` Heiko Stübner
2026-01-07 14:56 ` Heiko Stübner
0 siblings, 1 reply; 26+ messages in thread
From: Heiko Stübner @ 2026-01-07 14:54 UTC (permalink / raw)
To: Chaoyi Chen, Alexey Charkov, Chaoyi Chen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Quentin Schulz,
Kever Yang, Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon,
Dragan Simic, Michael Riesch, Peter Robinson, Shawn Lin,
Sebastian Reichel, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
Am Mittwoch, 7. Januar 2026, 11:04:42 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:
> On 1/7/2026 5:57 PM, Chaoyi Chen wrote:
> > On 1/7/2026 4:21 PM, Heiko Stübner wrote:
> >> Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
> >>> On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@airkyi.com> wrote:
[...]
> >>>> + 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
> >>
> >> 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.
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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 14:54 ` Heiko Stübner
@ 2026-01-07 14:56 ` Heiko Stübner
0 siblings, 0 replies; 26+ messages in thread
From: Heiko Stübner @ 2026-01-07 14:56 UTC (permalink / raw)
To: Chaoyi Chen, Alexey Charkov, Chaoyi Chen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Quentin Schulz,
Kever Yang, Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon,
Dragan Simic, Michael Riesch, Peter Robinson, Shawn Lin,
Sebastian Reichel, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
Am Mittwoch, 7. Januar 2026, 15:54:47 Mitteleuropäische Normalzeit schrieb Heiko Stübner:
> Am Mittwoch, 7. Januar 2026, 11:04:42 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:
> > On 1/7/2026 5:57 PM, Chaoyi Chen wrote:
> > > On 1/7/2026 4:21 PM, Heiko Stübner wrote:
> > >> Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
> > >>> On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@airkyi.com> wrote:
>
> [...]
>
> > >>>> + 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
> > >>
> > >> 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.
>
> 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
> 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
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 7:56 ` Alexey Charkov
2026-01-07 8:21 ` Heiko Stübner
@ 2026-01-07 9:50 ` Chaoyi Chen
1 sibling, 0 replies; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-07 9:50 UTC (permalink / raw)
To: Alexey Charkov, Chaoyi Chen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz, Kever Yang, Jonas Karlman, John Clark,
FUKAUMI Naoki, Jimmy Hon, Dragan Simic, Michael Riesch,
Peter Robinson, Shawn Lin, Sebastian Reichel, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
Hi Alexey,
On 1/7/2026 3:56 PM, Alexey Charkov wrote:
> Hi Chaoyi,
>
> On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@airkyi.com> wrote:
>>
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> 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.
>>
>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>> ---
>>
>> 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
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
>> index c7617e06e1c1..cff95657d406 100644
>> --- a/arch/arm64/boot/dts/rockchip/Makefile
>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
>> @@ -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
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>> new file mode 100644
>> index 000000000000..52788c514ec0
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>> @@ -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>;
>> + };
>> +
>> + 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.
>> + 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;
>
> 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
Yes. I will try to do this in v3. Thank you!
>
> [snip]
>
> Other than these, LGTM - thanks for addressing my comments from v1!
> Feel free to include my:
>
> Reviewed-by: Alexey Charkov <alchark@gmail.com>
>
> Best regards,
> Alexey
>
>
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 7:03 ` [PATCH v2 2/2] arm64: dts: " Chaoyi Chen
2026-01-07 7:56 ` Alexey Charkov
@ 2026-01-07 15:46 ` Quentin Schulz
2026-01-08 6:27 ` Chaoyi Chen
2026-01-07 18:17 ` Andrew Lunn
2026-01-08 6:50 ` Andy Yan
3 siblings, 1 reply; 26+ messages in thread
From: Quentin Schulz @ 2026-01-07 15:46 UTC (permalink / raw)
To: Chaoyi Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Chaoyi Chen, Kever Yang, Jonas Karlman,
John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Alexey Charkov, Shawn Lin,
Sebastian Reichel, Andy Yan
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
Hi Chaoyi,
On 1/7/26 8:03 AM, Chaoyi Chen wrote:
[...]
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
> new file mode 100644
> index 000000000000..52788c514ec0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
> @@ -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 {
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?
> + 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.
> + 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?
> + };
> +
> + 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?
> + 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>;
> + };
> +
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)?
[...]
> + 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?
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_ufs_s0";
> + regulator-boot-on;
> + regulator-always-on;
Why always on?
[...]
> +&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.
> + 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.
[...]
> +&sdhci {
> + bus-width = <8>;
> + full-pwr-cycle-in-suspend;
> + max-frequency = <200000000>;
Already that value in rk3576.dtsi.
> + 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.
> + 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.
[...]
> + 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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 15:46 ` Quentin Schulz
@ 2026-01-08 6:27 ` Chaoyi Chen
2026-01-08 10:07 ` Quentin Schulz
0 siblings, 1 reply; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-08 6:27 UTC (permalink / raw)
To: Quentin Schulz, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Kever Yang, Jonas Karlman, John Clark,
FUKAUMI Naoki, Jimmy Hon, Dragan Simic, Michael Riesch,
Peter Robinson, Alexey Charkov, Shawn Lin, Sebastian Reichel,
Andy Yan, Chaoyi Chen
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
Hi Quentin,
Thank you for your patient review.
On 1/7/2026 11:46 PM, Quentin Schulz wrote:
> Hi Chaoyi,
>
> On 1/7/26 8:03 AM, Chaoyi Chen wrote:
> [...]
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>> new file mode 100644
>> index 000000000000..52788c514ec0
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>> @@ -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 {
>
> 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?
>
Hmm, I will delete them in v3.
>> + 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.
>> + 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?
>> + };
>> +
>> + 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.
>> + 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>;
>> + };
>> +
>
> 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.
>
> Additionally, why is this always-on? I would assume the USB controller is capable of controlling its regulator(s)?
>
Oh, it should be remove.
> [...]
>
>> + 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!
>
>> + 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.
>> +&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.
>
No, c22 compatible also works. I will use it in v3.
>> + 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.
>
> [...]
>
>> +&sdhci {
>> + bus-width = <8>;
>> + full-pwr-cycle-in-suspend;
>> + max-frequency = <200000000>;
>
> Already that value in rk3576.dtsi.
>
I will drop them in v3.
>> + 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.
>
I will drop them in v3.
>> + 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.
>
> [...]
>
Oh, that's true. I will fix it in v3.
>> + 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.
No. BT and Wi-Fi functions are controlled by two separate sets of GPIOs.
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 6:27 ` Chaoyi Chen
@ 2026-01-08 10:07 ` Quentin Schulz
2026-01-08 10:41 ` Chaoyi Chen
0 siblings, 1 reply; 26+ messages in thread
From: Quentin Schulz @ 2026-01-08 10:07 UTC (permalink / raw)
To: Chaoyi Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Kever Yang, Jonas Karlman, John Clark,
FUKAUMI Naoki, Jimmy Hon, Dragan Simic, Michael Riesch,
Peter Robinson, Alexey Charkov, Shawn Lin, Sebastian Reichel,
Andy Yan, Chaoyi Chen
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
Hi Chaoyi,
On 1/8/26 7:27 AM, Chaoyi Chen wrote:
> Hi Quentin,
>
> Thank you for your patient review.
>
> On 1/7/2026 11:46 PM, Quentin Schulz wrote:
>> Hi Chaoyi,
>>
>> On 1/7/26 8:03 AM, Chaoyi Chen wrote:
[...]
>>> + 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.
>
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.
>>> + 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?
>
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 :) ).
>>> + };
>>> +
>>> + 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.
>
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.
>>> + 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>;
>>> + };
>>> +
>>
>> 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.
>
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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 10:07 ` Quentin Schulz
@ 2026-01-08 10:41 ` Chaoyi Chen
2026-01-08 10:51 ` Quentin Schulz
0 siblings, 1 reply; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-08 10:41 UTC (permalink / raw)
To: Quentin Schulz, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Kever Yang, Jonas Karlman, John Clark,
FUKAUMI Naoki, Jimmy Hon, Dragan Simic, Michael Riesch,
Peter Robinson, Alexey Charkov, Shawn Lin, Sebastian Reichel,
Andy Yan, Chaoyi Chen
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
Hi Quentin,
On 1/8/2026 6:07 PM, Quentin Schulz wrote:
> Hi Chaoyi,
>
> On 1/8/26 7:27 AM, Chaoyi Chen wrote:
>> Hi Quentin,
>>
>> Thank you for your patient review.
>>
>> On 1/7/2026 11:46 PM, Quentin Schulz wrote:
>>> Hi Chaoyi,
>>>
>>> On 1/7/26 8:03 AM, Chaoyi Chen wrote:
>
> [...]
>
>>>> + 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.
>>
>
> 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.
>>>> + 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?
>>
>
> 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.
>>>> + };
>>>> +
>>>> + 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.
>>
>
> 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.
> 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.
>>>> + 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>;
>>>> + };
>>>> +
>>>
>>> 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.
>>
>
> 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.
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 10:41 ` Chaoyi Chen
@ 2026-01-08 10:51 ` Quentin Schulz
0 siblings, 0 replies; 26+ messages in thread
From: Quentin Schulz @ 2026-01-08 10:51 UTC (permalink / raw)
To: Chaoyi Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Kever Yang, Jonas Karlman, John Clark,
FUKAUMI Naoki, Jimmy Hon, Dragan Simic, Michael Riesch,
Peter Robinson, Alexey Charkov, Shawn Lin, Sebastian Reichel,
Andy Yan, Chaoyi Chen
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
Hi Chaoyi,
On 1/8/26 11:41 AM, Chaoyi Chen wrote:
> Hi Quentin,
>
> On 1/8/2026 6:07 PM, Quentin Schulz wrote:
>> Hi Chaoyi,
>>
>> On 1/8/26 7:27 AM, Chaoyi Chen wrote:
>>> Hi Quentin,
>>>
>>> Thank you for your patient review.
>>>
>>> On 1/7/2026 11:46 PM, Quentin Schulz wrote:
>>>> Hi Chaoyi,
>>>>
>>>> On 1/7/26 8:03 AM, Chaoyi Chen wrote:
[...]
>>>>> + 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?
>>>
>>
>> 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.
[...]
>>>>> + 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>;
>>>>> + };
>>>>> +
>>>>
>>>> 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.
>>>
>>
>> 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.
>
Yes, that does make sense to me.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 7:03 ` [PATCH v2 2/2] arm64: dts: " Chaoyi Chen
2026-01-07 7:56 ` Alexey Charkov
2026-01-07 15:46 ` Quentin Schulz
@ 2026-01-07 18:17 ` Andrew Lunn
2026-01-08 6:53 ` Alexey Charkov
2026-01-08 6:50 ` Andy Yan
3 siblings, 1 reply; 26+ messages in thread
From: Andrew Lunn @ 2026-01-07 18:17 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz, Chaoyi Chen, Kever Yang, Jonas Karlman,
John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Alexey Charkov, Shawn Lin,
Sebastian Reichel, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
> +&gmac0 {
> + 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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 18:17 ` Andrew Lunn
@ 2026-01-08 6:53 ` Alexey Charkov
2026-01-08 7:42 ` Chaoyi Chen
0 siblings, 1 reply; 26+ messages in thread
From: Alexey Charkov @ 2026-01-08 6:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chaoyi Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Quentin Schulz, Chaoyi Chen, Kever Yang,
Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > +&gmac0 {
> > + 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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 6:53 ` Alexey Charkov
@ 2026-01-08 7:42 ` Chaoyi Chen
2026-01-08 8:01 ` Chaoyi Chen
0 siblings, 1 reply; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-08 7:42 UTC (permalink / raw)
To: Alexey Charkov, Andrew Lunn
Cc: Chaoyi Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Quentin Schulz, Kever Yang, Jonas Karlman,
John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Hello Alexey, Andrew,
On 1/8/2026 2:53 PM, Alexey Charkov wrote:
> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>
>>> +&gmac0 {
>>> + 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
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.
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 7:42 ` Chaoyi Chen
@ 2026-01-08 8:01 ` Chaoyi Chen
2026-01-08 8:11 ` Alexey Charkov
2026-01-08 13:53 ` Andrew Lunn
0 siblings, 2 replies; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-08 8:01 UTC (permalink / raw)
To: Chaoyi Chen, Alexey Charkov, Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz, Kever Yang, Jonas Karlman, John Clark,
FUKAUMI Naoki, Jimmy Hon, Dragan Simic, Michael Riesch,
Peter Robinson, Shawn Lin, Sebastian Reichel, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
On 1/8/2026 3:42 PM, Chaoyi Chen wrote:
> Hello Alexey, Andrew,
>
> On 1/8/2026 2:53 PM, Alexey Charkov wrote:
>> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>>
>>>> +&gmac0 {
>>>> + 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
>
> 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.
>
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?
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 8:01 ` Chaoyi Chen
@ 2026-01-08 8:11 ` Alexey Charkov
2026-01-08 8:38 ` Chaoyi Chen
2026-01-08 13:53 ` Andrew Lunn
1 sibling, 1 reply; 26+ messages in thread
From: Alexey Charkov @ 2026-01-08 8:11 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Chaoyi Chen, Andrew Lunn, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Quentin Schulz, Kever Yang,
Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
On Thu, Jan 8, 2026 at 12:02 PM Chaoyi Chen <kernel@airkyi.com> wrote:
>
> On 1/8/2026 3:42 PM, Chaoyi Chen wrote:
> > Hello Alexey, Andrew,
> >
> > On 1/8/2026 2:53 PM, Alexey Charkov wrote:
> >> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >>>
> >>>> +&gmac0 {
> >>>> + 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
> >
> > 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.
> >
>
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 8:11 ` Alexey Charkov
@ 2026-01-08 8:38 ` Chaoyi Chen
2026-01-08 8:49 ` Alexey Charkov
0 siblings, 1 reply; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-08 8:38 UTC (permalink / raw)
To: Alexey Charkov, Chaoyi Chen
Cc: Andrew Lunn, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Quentin Schulz, Kever Yang, Jonas Karlman,
John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
On 1/8/2026 4:11 PM, Alexey Charkov wrote:
> On Thu, Jan 8, 2026 at 12:02 PM Chaoyi Chen <kernel@airkyi.com> wrote:
>>
>> On 1/8/2026 3:42 PM, Chaoyi Chen wrote:
>>> Hello Alexey, Andrew,
>>>
>>> On 1/8/2026 2:53 PM, Alexey Charkov wrote:
>>>> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>>>>
>>>>>> +&gmac0 {
>>>>>> + 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
>>>
>>> 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.
>>>
>>
>> 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
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?
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 8:38 ` Chaoyi Chen
@ 2026-01-08 8:49 ` Alexey Charkov
2026-01-08 9:02 ` Chaoyi Chen
0 siblings, 1 reply; 26+ messages in thread
From: Alexey Charkov @ 2026-01-08 8:49 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Chaoyi Chen, Andrew Lunn, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Quentin Schulz, Kever Yang,
Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
On Thu, Jan 8, 2026 at 12:38 PM Chaoyi Chen <chaoyi.chen@rock-chips.com> wrote:
>
> On 1/8/2026 4:11 PM, Alexey Charkov wrote:
> > On Thu, Jan 8, 2026 at 12:02 PM Chaoyi Chen <kernel@airkyi.com> wrote:
> >>
> >> On 1/8/2026 3:42 PM, Chaoyi Chen wrote:
> >>> Hello Alexey, Andrew,
> >>>
> >>> On 1/8/2026 2:53 PM, Alexey Charkov wrote:
> >>>> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >>>>>
> >>>>>> +&gmac0 {
> >>>>>> + 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
> >>>
> >>> 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.
> >>>
> >>
> >> 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
>
> Ah, I thought it was something like this:
>
> &gmac0 {
> phy-mode = "rgmii";
phy-mode = "rgmii-id";
> 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
> };
>
> But what you actually said was this:
>
> &mdio1 {
&mdio0 I guess (but same applies to gmac1+mdio1)
> 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
> };
> };
>
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 8:49 ` Alexey Charkov
@ 2026-01-08 9:02 ` Chaoyi Chen
0 siblings, 0 replies; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-08 9:02 UTC (permalink / raw)
To: Alexey Charkov
Cc: Chaoyi Chen, Andrew Lunn, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Quentin Schulz, Kever Yang,
Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
On 1/8/2026 4:49 PM, Alexey Charkov wrote:
> On Thu, Jan 8, 2026 at 12:38 PM Chaoyi Chen <chaoyi.chen@rock-chips.com> wrote:
>>
>> On 1/8/2026 4:11 PM, Alexey Charkov wrote:
>>> On Thu, Jan 8, 2026 at 12:02 PM Chaoyi Chen <kernel@airkyi.com> wrote:
>>>>
>>>> On 1/8/2026 3:42 PM, Chaoyi Chen wrote:
>>>>> Hello Alexey, Andrew,
>>>>>
>>>>> On 1/8/2026 2:53 PM, Alexey Charkov wrote:
>>>>>> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>>>>>>
>>>>>>>> +&gmac0 {
>>>>>>>> + 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
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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
>>
>> Ah, I thought it was something like this:
>>
>> &gmac0 {
>> phy-mode = "rgmii";
>
> phy-mode = "rgmii-id";
>
>> 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
>
>> };
>>
>> But what you actually said was this:
>>
>> &mdio1 {
>
> &mdio0 I guess (but same applies to gmac1+mdio1)
>
>> 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
>
>> };
>> };
>>
>> 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 :)
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 8:01 ` Chaoyi Chen
2026-01-08 8:11 ` Alexey Charkov
@ 2026-01-08 13:53 ` Andrew Lunn
1 sibling, 0 replies; 26+ messages in thread
From: Andrew Lunn @ 2026-01-08 13:53 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Chaoyi Chen, Alexey Charkov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Quentin Schulz, Kever Yang,
Jonas Karlman, John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re:[PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-07 7:03 ` [PATCH v2 2/2] arm64: dts: " Chaoyi Chen
` (2 preceding siblings ...)
2026-01-07 18:17 ` Andrew Lunn
@ 2026-01-08 6:50 ` Andy Yan
2026-01-08 8:04 ` [PATCH " Chaoyi Chen
3 siblings, 1 reply; 26+ messages in thread
From: Andy Yan @ 2026-01-08 6:50 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz, Chaoyi Chen, Kever Yang, Jonas Karlman,
John Clark, FUKAUMI Naoki, Jimmy Hon, Dragan Simic,
Michael Riesch, Peter Robinson, Alexey Charkov, Shawn Lin,
Sebastian Reichel, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
Hello Chaoyi,
At 2026-01-07 15:03:22, "Chaoyi Chen" <kernel@airkyi.com> wrote:
>From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
>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.
>
>Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>---
>
>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
>
>diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
>index c7617e06e1c1..cff95657d406 100644
>--- a/arch/arm64/boot/dts/rockchip/Makefile
>+++ b/arch/arm64/boot/dts/rockchip/Makefile
>@@ -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
>diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>new file mode 100644
>index 000000000000..52788c514ec0
>--- /dev/null
>+++ b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>@@ -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;
>+ };
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.
>+
>+ 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 = <ð0m1_miim
>+ ð0m1_tx_bus2
>+ ð0m1_rx_bus2
>+ ð0m1_rgmii_clk
>+ ð0m1_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 = <ð1m0_miim
>+ ð1m0_tx_bus2
>+ ð1m0_rx_bus2
>+ ð1m0_rgmii_clk
>+ ð1m0_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>;
>+ };
>+};
>--
>2.51.1
>
>
>_______________________________________________
>Linux-rockchip mailing list
>Linux-rockchip@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
2026-01-08 6:50 ` Andy Yan
@ 2026-01-08 8:04 ` Chaoyi Chen
0 siblings, 0 replies; 26+ messages in thread
From: Chaoyi Chen @ 2026-01-08 8:04 UTC (permalink / raw)
To: Andy Yan
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz, Kever Yang, Jonas Karlman, John Clark,
FUKAUMI Naoki, Jimmy Hon, Dragan Simic, Michael Riesch,
Peter Robinson, Alexey Charkov, Shawn Lin, Sebastian Reichel,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Hello Andy,
On 1/8/2026 2:50 PM, Andy Yan wrote:
>
> Hello Chaoyi,
>
>
> At 2026-01-07 15:03:22, "Chaoyi Chen" <kernel@airkyi.com> wrote:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> 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.
>>
>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>> ---
>>
>> 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
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
>> index c7617e06e1c1..cff95657d406 100644
>> --- a/arch/arm64/boot/dts/rockchip/Makefile
>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
>> @@ -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
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>> new file mode 100644
>> index 000000000000..52788c514ec0
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts
>> @@ -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;
>> + };
>
> 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.
>> +
>> + 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 = <ð0m1_miim
>> + ð0m1_tx_bus2
>> + ð0m1_rx_bus2
>> + ð0m1_rgmii_clk
>> + ð0m1_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 = <ð1m0_miim
>> + ð1m0_tx_bus2
>> + ð1m0_rx_bus2
>> + ð1m0_rgmii_clk
>> + ð1m0_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>;
>> + };
>> +};
>> --
>> 2.51.1
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
Best,
Chaoyi
^ permalink raw reply [flat|nested] 26+ messages in thread