LinkEase EasePi R1 [1] is a high-performance mini router.
Specification:
- Rockchip RK3568
- 2GB/4GB LPDDR4 RAM
- 16GB on-board eMMC
- 1x M.2 key for 2280 NVMe (PCIe 3.0)
- 1x USB 3.0 Type-A
- 1x USB 2.0 Type-C (for USB flashing)
- 2x 1000 Base-T (native, RTL8211F)
- 2x 2500 Base-T (PCIe, RTL8125B)
- 1x HDMI 2.0 Output
- 12v DC Jack
- 1x Power key connected to PMIC
- 2x LEDs (one static power supplied, one GPIO controlled)
[1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html
Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3568-easepi-r1.dts | 692 ++++++++++++++++++
2 files changed, 693 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 099520962ffb..7646ffd7f309 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -127,6 +127,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-nanopi-r3s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-bigtreetech-cb2-manta.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-bigtreetech-pi2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-easepi-r1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r68s.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts b/arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
new file mode 100644
index 000000000000..2bc8675efa12
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
@@ -0,0 +1,692 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3568.dtsi"
+
+/ {
+ model = "LinkEase EasePi R1";
+ compatible = "linkease,easepi-r1", "rockchip,rk3568";
+
+ aliases {
+ mmc0 = &sdmmc0;
+ mmc1 = &sdhci;
+ mmc2 = &sdmmc2;
+
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ press-threshold-microvolt = <1750>;
+ };
+ };
+
+ dc_12v: regulator-dc-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc3v3_sys: regulator-vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ pcie30_avdd0v9: regulator-pcie30-avdd0v9 {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ pcie30_avdd1v8: regulator-pcie30-avdd1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ regulator-vdd0v95-25glan {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_25g_pin>;
+ enable-active-high;
+ gpio = <&gpio3 RK_PB1 GPIO_ACTIVE_HIGH>;
+ regulator-name = "vdd0v95_25glan";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_nvme: regulator-vcc3v3-nvme {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_nvme";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&dc_12v>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v3_nvme_en>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk809 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ post-power-on-delay-ms = <200>;
+ reset-gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_LOW>;
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&status_led_pin>;
+
+ status_led: led-status {
+ gpios = <&gpio2 RK_PD7 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ label = "green:status";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+};
+
+&gmac0 {
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+
+ assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
+ assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ phy-handle = <&rgmii_phy0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac0_miim
+ &gmac0_tx_bus2
+ &gmac0_rx_bus2
+ &gmac0_rgmii_clk
+ &gmac0_rgmii_bus>;
+
+ tx_delay = <0x3c>;
+ rx_delay = <0x2f>;
+
+ status = "okay";
+};
+
+&gmac1 {
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+
+ assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
+ assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ phy-handle = <&rgmii_phy1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1m1_miim
+ &gmac1m1_tx_bus2
+ &gmac1m1_rx_bus2
+ &gmac1m1_rgmii_clk
+ &gmac1m1_rgmii_bus>;
+
+ tx_delay = <0x4f>;
+ rx_delay = <0x26>;
+
+ status = "okay";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ pinctrl-0 = <ð_phy0_reset_pin>;
+ pinctrl-names = "default";
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&mdio1 {
+ rgmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ pinctrl-0 = <ð_phy1_reset_pin>;
+ pinctrl-names = "default";
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&combphy0 {
+ status = "okay";
+};
+
+&combphy1 {
+ status = "okay";
+};
+
+&combphy2 {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ avdd-0v9-supply = <&vdda0v9_image>;
+ avdd-1v8-supply = <&vcca1v8_image>;
+ 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";
+};
+
+&i2c0 {
+ status = "okay";
+
+ vdd_cpu: regulator@1c {
+ compatible = "tcs,tcs4525";
+ reg = <0x1c>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int>;
+ system-power-controller;
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc5-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ wakeup-source;
+
+ regulators {
+ vdd_logic: DCDC_REG1 {
+ regulator-name = "vdd_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-name = "vdd_gpu";
+ regulator-always-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_npu: DCDC_REG4 {
+ regulator-name = "vdd_npu";
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG5 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_image: LDO_REG1 {
+ regulator-name = "vdda0v9_image";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <950000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v9: LDO_REG2 {
+ regulator-name = "vdda_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_pmu: LDO_REG3 {
+ regulator-name = "vdda0v9_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vccio_acodec: LDO_REG4 {
+ regulator-name = "vccio_acodec";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-name = "vccio_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_pmu: LDO_REG6 {
+ regulator-name = "vcc3v3_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcca_1v8: LDO_REG7 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pmu: LDO_REG8 {
+ regulator-name = "vcca1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_image: LDO_REG9 {
+ regulator-name = "vcca1v8_image";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3: SWITCH_REG1 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: SWITCH_REG2 {
+ regulator-name = "vcc3v3_sd";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+
+ };
+};
+
+&i2s0_8ch {
+ status = "okay";
+};
+
+/* ETH3 */
+&pcie2x1 {
+ reset-gpios = <&gpio3 RK_PA4 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&pcie30phy {
+ data-lanes = <1 2>;
+ status = "okay";
+};
+
+/* ETH2 */
+&pcie3x1 {
+ num-lanes = <1>;
+ reset-gpios = <&gpio3 RK_PA3 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+/* M.2 Key for 2280 NVMe */
+&pcie3x2 {
+ num-lanes = <1>;
+ reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_nvme>;
+ status = "okay";
+};
+
+&pinctrl {
+ gmac0 {
+ eth_phy0_reset_pin: eth-phy0-reset-pin {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+ gmac1 {
+ eth_phy1_reset_pin: eth-phy1-reset-pin {
+ rockchip,pins = <2 RK_PD1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ gpio-leds {
+ status_led_pin: status-led-pin {
+ rockchip,pins =
+ <2 RK_PD7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic-int {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ pcie-nic {
+ pwr_25g_pin: pwr-25g-pin {
+ rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ nvme {
+ vcc3v3_nvme_en: vcc3v3-nvme-en {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+};
+
+&pmu_io_domains {
+ pmuio1-supply = <&vcc3v3_pmu>;
+ pmuio2-supply = <&vcc3v3_pmu>;
+ vccio1-supply = <&vccio_acodec>;
+ vccio3-supply = <&vccio_sd>;
+ vccio4-supply = <&vcc_1v8>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_1v8>;
+ vccio7-supply = <&vcc_3v3>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcca_1v8>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+ status = "okay";
+};
+
+/* Micro SD card slot is not mounted */
+&sdmmc0 {
+ max-frequency = <150000000>;
+ no-sdio;
+ no-mmc;
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ disable-wp;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "disabled";
+};
+
+/* Wifi module is not mounted */
+&sdmmc2 {
+ max-frequency = <150000000>;
+ bus-width = <4>;
+ disable-wp;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc2m0_bus4 &sdmmc2m0_cmd &sdmmc2m0_clk>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sys>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "disabled";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>;
+ rockchip,hw-tshut-polarity = <0>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+/* OTG Only USB2.0, Only device mode */
+&usb_host0_xhci {
+ phys = <&usb2phy0_otg>;
+ phy-names = "usb2-phy";
+ extcon = <&usb2phy0>;
+ maximum-speed = "high-speed";
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usb_host1_xhci {
+ status = "okay";
+};
+
+&usb2phy0 {
+ status = "okay";
+};
+
+&usb2phy0_host {
+ phy-supply = <&vcc5v0_sys>;
+ status = "okay";
+};
+
+&usb2phy0_otg {
+ status = "okay";
+};
+
+&vop {
+ assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+ assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+ 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.0> +&gmac0 {
> + phy-mode = "rgmii";
Did i really miss this patch series in its earlier version, or did you
ignore me?
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
> + tx_delay = <0x3c>;
> + rx_delay = <0x2f>;
Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
us the schematics which clearly show extra long clock lines.
> +/* Micro SD card slot is not mounted */
> +&sdmmc0 {
> + max-frequency = <150000000>;
> + no-sdio;
> + no-mmc;
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + disable-wp;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> + vmmc-supply = <&vcc3v3_sd>;
> + vqmmc-supply = <&vccio_sd>;
> + status = "disabled";
> +};
> +
> +/* Wifi module is not mounted */
> +&sdmmc2 {
What do you mean by "not mounted"?
Often you would say "not populated", to indicate the PCB has all the
tracks in place, but the chip has simply not been soldered in place.
Or is there a connector here, and nothing plugged into the connector?
Andrew
Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
>
> > +&gmac0 {
> > + phy-mode = "rgmii";
>
> Did i really miss this patch series in its earlier version, or did you
> ignore me?
>
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
>
> > + tx_delay = <0x3c>;
> > + rx_delay = <0x2f>;
>
> Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> us the schematics which clearly show extra long clock lines.
>
> > +/* Micro SD card slot is not mounted */
> > +&sdmmc0 {
> > + max-frequency = <150000000>;
> > + no-sdio;
> > + no-mmc;
> > + bus-width = <4>;
> > + cap-mmc-highspeed;
> > + cap-sd-highspeed;
> > + disable-wp;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> > + vmmc-supply = <&vcc3v3_sd>;
> > + vqmmc-supply = <&vccio_sd>;
> > + status = "disabled";
> > +};
> > +
> > +/* Wifi module is not mounted */
> > +&sdmmc2 {
>
> What do you mean by "not mounted"?
>
> Often you would say "not populated", to indicate the PCB has all the
> tracks in place, but the chip has simply not been soldered in place.
>
> Or is there a connector here, and nothing plugged into the connector?
>
> Andrew
Andrew:
Hello! I ran `./scripts/get_maintainer.pl
patches-v4/v4-0003-arm64-dts-rockchip-add-LinkEase-EasePi-R1.patch`
to get maintainer list, and got:
```
Rob Herring <robh@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS)
Krzysztof Kozlowski <krzk+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS,commit_signer:3/41=7%)
Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS)
Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC
support,commit_signer:43/41=100%,authored:4/41=10%,added_lines:12/117=10%,commit_signer:5/6=83%)
Quentin Schulz <quentin.schulz@cherry.de>
(commit_signer:10/41=24%,authored:8/41=20%,added_lines:63/117=54%)
Dragan Simic <dsimic@manjaro.org> (commit_signer:5/41=12%,commit_signer:1/6=17%)
FUKAUMI Naoki <naoki@radxa.com>
(commit_signer:3/41=7%,authored:3/41=7%,removed_lines:1/1=100%)
Peter Robinson <pbrobinson@gmail.com>
(added_lines:9/117=8%,commit_signer:1/6=17%,authored:1/6=17%)
Alexey Charkov <alchark@gmail.com> (added_lines:6/117=5%)
Diederik de Haas <didi.debian@cknow.org>
(commit_signer:4/6=67%,authored:3/6=50%)
Liangbin Lian <jjm2473@gmail.com> (commit_signer:1/6=17%,authored:1/6=17%)
Johan Jonker <jbx6244@gmail.com> (authored:1/6=17%)
devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS)
linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support)
linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support)
linux-kernel@vger.kernel.org (open list)
```
your email address is not listed above.
And I did not receive your comment on the previou versions.
The latest v4 version is here
https://lore.kernel.org/all/20250930055017.67610-1-jjm2473@gmail.com/
.
> What do you mean by "not mounted"?
>
> Often you would say "not populated", to indicate the PCB has all the
> tracks in place, but the chip has simply not been soldered in place.
>
> Or is there a connector here, and nothing plugged into the connector?
The chip/slot has not been soldered. So here should be "not
populated", forgive my poor English.
> Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> us the schematics which clearly show extra long clock lines.
In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
The tx_delay and rx_delay values were obtained using Rockchip's
automatic scanning tool:
https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
I will try changing phy-mode = "rgmii-id" later to see if gmac
continues to work properly.
Liangbin Lian
On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
> Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
> >
> > > +&gmac0 {
> > > + phy-mode = "rgmii";
> >
> > Did i really miss this patch series in its earlier version, or did you
> > ignore me?
> >
> > https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
> >
> > > + tx_delay = <0x3c>;
> > > + rx_delay = <0x2f>;
> >
> > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > us the schematics which clearly show extra long clock lines.
> >
> > > +/* Micro SD card slot is not mounted */
> > > +&sdmmc0 {
> > > + max-frequency = <150000000>;
> > > + no-sdio;
> > > + no-mmc;
> > > + bus-width = <4>;
> > > + cap-mmc-highspeed;
> > > + cap-sd-highspeed;
> > > + disable-wp;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> > > + vmmc-supply = <&vcc3v3_sd>;
> > > + vqmmc-supply = <&vccio_sd>;
> > > + status = "disabled";
> > > +};
> > > +
> > > +/* Wifi module is not mounted */
> > > +&sdmmc2 {
> >
> > What do you mean by "not mounted"?
> >
> > Often you would say "not populated", to indicate the PCB has all the
> > tracks in place, but the chip has simply not been soldered in place.
> >
> > Or is there a connector here, and nothing plugged into the connector?
> >
> > Andrew
>
> Andrew:
> Hello! I ran `./scripts/get_maintainer.pl
> patches-v4/v4-0003-arm64-dts-rockchip-add-LinkEase-EasePi-R1.patch`
> to get maintainer list, and got:
> ```
> Rob Herring <robh@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS)
> Krzysztof Kozlowski <krzk+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS,commit_signer:3/41=7%)
> Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS)
> Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC
> support,commit_signer:43/41=100%,authored:4/41=10%,added_lines:12/117=10%,commit_signer:5/6=83%)
> Quentin Schulz <quentin.schulz@cherry.de>
> (commit_signer:10/41=24%,authored:8/41=20%,added_lines:63/117=54%)
> Dragan Simic <dsimic@manjaro.org> (commit_signer:5/41=12%,commit_signer:1/6=17%)
> FUKAUMI Naoki <naoki@radxa.com>
> (commit_signer:3/41=7%,authored:3/41=7%,removed_lines:1/1=100%)
> Peter Robinson <pbrobinson@gmail.com>
> (added_lines:9/117=8%,commit_signer:1/6=17%,authored:1/6=17%)
> Alexey Charkov <alchark@gmail.com> (added_lines:6/117=5%)
> Diederik de Haas <didi.debian@cknow.org>
> (commit_signer:4/6=67%,authored:3/6=50%)
> Liangbin Lian <jjm2473@gmail.com> (commit_signer:1/6=17%,authored:1/6=17%)
> Johan Jonker <jbx6244@gmail.com> (authored:1/6=17%)
> devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS)
> linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support)
> linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support)
> linux-kernel@vger.kernel.org (open list)
> ```
> your email address is not listed above.
What i eventually found is that you posted v3 separately, and then
threaded v4 to v2, which makes no sense.
Please always start a new thread for each patchset.
> > What do you mean by "not mounted"?
> >
> > Often you would say "not populated", to indicate the PCB has all the
> > tracks in place, but the chip has simply not been soldered in place.
> >
> > Or is there a connector here, and nothing plugged into the connector?
>
> The chip/slot has not been soldered. So here should be "not
> populated", forgive my poor English.
Thanks for the clarification. I'm not sure it is worth adding these DT
properties. When a new board is produced which does populate these
devices, you are going to need a new .dts file. So you can put the
properties into that new file.
>
> > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > us the schematics which clearly show extra long clock lines.
>
> In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
> just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
> https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
Pull low makes no difference to the 2ns RGMII delays.
> The tx_delay and rx_delay values were obtained using Rockchip's
> automatic scanning tool:
> https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
> https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
Vendors get things wrong, including this. 'rgmii' means the PCB adds
the 2ns delay. Nearly every Rockchip board follows Rockchip broken
vendor recommendations, and then i come along, point out how it is
wrong, and ask for it to be fixed, before being merged to Mainline.
Andrew
Andrew Lunn <andrew@lunn.ch> 于2025年10月7日周二 22:57写道：
>
> On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
> > Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
> > >
> > > > +&gmac0 {
> > > > + phy-mode = "rgmii";
> > >
> > > Did i really miss this patch series in its earlier version, or did you
> > > ignore me?
> > >
> > > https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
> > >
> > > > + tx_delay = <0x3c>;
> > > > + rx_delay = <0x2f>;
> > >
> > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > > us the schematics which clearly show extra long clock lines.
> > >
> > > > +/* Micro SD card slot is not mounted */
> > > > +&sdmmc0 {
> > > > + max-frequency = <150000000>;
> > > > + no-sdio;
> > > > + no-mmc;
> > > > + bus-width = <4>;
> > > > + cap-mmc-highspeed;
> > > > + cap-sd-highspeed;
> > > > + disable-wp;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> > > > + vmmc-supply = <&vcc3v3_sd>;
> > > > + vqmmc-supply = <&vccio_sd>;
> > > > + status = "disabled";
> > > > +};
> > > > +
> > > > +/* Wifi module is not mounted */
> > > > +&sdmmc2 {
> > >
> > > What do you mean by "not mounted"?
> > >
> > > Often you would say "not populated", to indicate the PCB has all the
> > > tracks in place, but the chip has simply not been soldered in place.
> > >
> > > Or is there a connector here, and nothing plugged into the connector?
> > >
> > > Andrew
> >
> > Andrew:
> > Hello! I ran `./scripts/get_maintainer.pl
> > patches-v4/v4-0003-arm64-dts-rockchip-add-LinkEase-EasePi-R1.patch`
> > to get maintainer list, and got:
> > ```
> > Rob Herring <robh@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
> > DEVICE TREE BINDINGS)
> > Krzysztof Kozlowski <krzk+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS,commit_signer:3/41=7%)
> > Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS)
> > Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC
> > support,commit_signer:43/41=100%,authored:4/41=10%,added_lines:12/117=10%,commit_signer:5/6=83%)
> > Quentin Schulz <quentin.schulz@cherry.de>
> > (commit_signer:10/41=24%,authored:8/41=20%,added_lines:63/117=54%)
> > Dragan Simic <dsimic@manjaro.org> (commit_signer:5/41=12%,commit_signer:1/6=17%)
> > FUKAUMI Naoki <naoki@radxa.com>
> > (commit_signer:3/41=7%,authored:3/41=7%,removed_lines:1/1=100%)
> > Peter Robinson <pbrobinson@gmail.com>
> > (added_lines:9/117=8%,commit_signer:1/6=17%,authored:1/6=17%)
> > Alexey Charkov <alchark@gmail.com> (added_lines:6/117=5%)
> > Diederik de Haas <didi.debian@cknow.org>
> > (commit_signer:4/6=67%,authored:3/6=50%)
> > Liangbin Lian <jjm2473@gmail.com> (commit_signer:1/6=17%,authored:1/6=17%)
> > Johan Jonker <jbx6244@gmail.com> (authored:1/6=17%)
> > devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
> > DEVICE TREE BINDINGS)
> > linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support)
> > linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support)
> > linux-kernel@vger.kernel.org (open list)
> > ```
> > your email address is not listed above.
>
> What i eventually found is that you posted v3 separately, and then
> threaded v4 to v2, which makes no sense.
>
> Please always start a new thread for each patchset.
>
> > > What do you mean by "not mounted"?
> > >
> > > Often you would say "not populated", to indicate the PCB has all the
> > > tracks in place, but the chip has simply not been soldered in place.
> > >
> > > Or is there a connector here, and nothing plugged into the connector?
> >
> > The chip/slot has not been soldered. So here should be "not
> > populated", forgive my poor English.
>
> Thanks for the clarification. I'm not sure it is worth adding these DT
> properties. When a new board is produced which does populate these
> devices, you are going to need a new .dts file. So you can put the
> properties into that new file.
>
> >
> > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > > us the schematics which clearly show extra long clock lines.
> >
> > In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
> > just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
> > https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
>
> Pull low makes no difference to the 2ns RGMII delays.
>
> > The tx_delay and rx_delay values were obtained using Rockchip's
> > automatic scanning tool:
> > https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
> > https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> > https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
>
> Vendors get things wrong, including this. 'rgmii' means the PCB adds
> the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> vendor recommendations, and then i come along, point out how it is
> wrong, and ask for it to be fixed, before being merged to Mainline.
>
> Andrew
Andrew:
Hello!
>
> What i eventually found is that you posted v3 separately, and then
> threaded v4 to v2, which makes no sense.
>
This is v2 link
https://lore.kernel.org/all/20250925092037.13582-1-jjm2473@gmail.com/
.
I don't see 'v4' in there. I have no idea why you see 'v4', can you
please share a link?
This is v3 link
https://lore.kernel.org/all/20250929065714.27741-1-jjm2473@gmail.com/
.
I don't see threading issue.
I use `git send-email --to '***' --cc '***' patches-v3` to send email,
should be OK.
(`patches-v3` is a folder contains patches generaterated by `git
format-patch --base=master --cover-letter -v3 HEAD -3 -o patches-v3`).
> When a new board is produced which does populate these
> devices, you are going to need a new .dts file. So you can put the
> properties into that new file.
These two nodes just describe the gpio and regulator found in the schematic.
If some users solder these connectors or modules themselves,
they only need to change the status to ok and they can use them.
If this will cause confusion, I can delete these two nodes.
> Vendors get things wrong, including this. 'rgmii' means the PCB adds
> the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> vendor recommendations, and then i come along, point out how it is
> wrong, and ask for it to be fixed, before being merged to Mainline.
I will try `rgmii-id` and rescan {tx|rx}_delay, just like
https://lore.kernel.org/all/20250925092923.2184187-3-heiko@sntech.de/
I also notice that you suggest use {tx|rx}-internal-delay-ps instead
of {tx|rx}_delay in
https://lore.kernel.org/all/e4d3127b-c879-4931-9ea0-de7449bc508c@lunn.ch/ ,
but I think this depends on stmmac driver.
Liangbin Lian
On Wed, Oct 08, 2025 at 01:29:57AM +0800, jjm2473 wrote:
> > Vendors get things wrong, including this. 'rgmii' means the PCB adds
> > the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> > vendor recommendations, and then i come along, point out how it is
> > wrong, and ask for it to be fixed, before being merged to Mainline.
>
> I will try `rgmii-id` and rescan {tx|rx}_delay, just like
> https://lore.kernel.org/all/20250925092923.2184187-3-heiko@sntech.de/
The current situation is...
https://lore.kernel.org/r/20240304084612.711678-2-ukleinek@debian.org
Notice that the tx_delay and rx_delay are removed - because with
"rgmii-id" the stmmac glue driver ignores the delay values.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Russell King (Oracle) <linux@armlinux.org.uk> 于2025年10月8日周三 02:48写道：
>
> On Wed, Oct 08, 2025 at 01:29:57AM +0800, jjm2473 wrote:
> > > Vendors get things wrong, including this. 'rgmii' means the PCB adds
> > > the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> > > vendor recommendations, and then i come along, point out how it is
> > > wrong, and ask for it to be fixed, before being merged to Mainline.
> >
> > I will try `rgmii-id` and rescan {tx|rx}_delay, just like
> > https://lore.kernel.org/all/20250925092923.2184187-3-heiko@sntech.de/
>
> The current situation is...
>
> https://lore.kernel.org/r/20240304084612.711678-2-ukleinek@debian.org
>
> Notice that the tx_delay and rx_delay are removed - because with
> "rgmii-id" the stmmac glue driver ignores the delay values.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
I change phy-mode to "rgmii-id", and remove {tx|rx}_delay, it works fine!
Will apply that to the next version.
Thanks!
Liangbin Lian
> I also notice that you suggest use {tx|rx}-internal-delay-ps instead
> of {tx|rx}_delay in
> https://lore.kernel.org/all/e4d3127b-c879-4931-9ea0-de7449bc508c@lunn.ch/ ,
> but I think this depends on stmmac driver.
It depends on the driver implementing those standard properties. But
as pointed out elsewhere, tx|rx-delay are magic, nobody knows what
they do, so it is hard to implement the standard properties to replace
them.
Andrew
On Tue, Oct 7, 2025 at 10:32 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > I also notice that you suggest use {tx|rx}-internal-delay-ps instead
> > of {tx|rx}_delay in
> > https://lore.kernel.org/all/e4d3127b-c879-4931-9ea0-de7449bc508c@lunn.ch/ ,
> > but I think this depends on stmmac driver.
>
> It depends on the driver implementing those standard properties. But
> as pointed out elsewhere, tx|rx-delay are magic, nobody knows what
> they do, so it is hard to implement the standard properties to replace
> them.
FWIW, the TRM for Rockchip RK3576 specifies that the values in
tx|rx-delay control the number of delay elements in the internal
delayline on the transmit and receive clocks, respectively (up to 200
each). There is no mention of the actual delay each delay element
introduces, though, so that doesn't get us much closer.
Best regards,
Alexey
> FWIW, the TRM for Rockchip RK3576 specifies that the values in
> tx|rx-delay control the number of delay elements in the internal
> delayline on the transmit and receive clocks, respectively (up to 200
> each).
200 is interesting:
tx_delay:
description: Delay value for TXD timing.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7F
200 != 0x7f
But i don't think the driver does any validation, so its not too
important.
Andrew
On Tue, Oct 07, 2025 at 04:57:32PM +0200, Andrew Lunn wrote: > On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote: > > Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道： > > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show > > > us the schematics which clearly show extra long clock lines. > > > > In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low, > > just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced: > > https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237 > > Pull low makes no difference to the 2ns RGMII delays. To be clear, while the RXDLY and TXDLY are hardware strapping controls the hardware configuration of the 2ns RGMII clock delays, the realtek driver can (and does) override this according to the phy-mode property. Thus hardware strapping makes no difference to Linux. So, what we get at the RTL8211F PHY is: phy-mode receive clock delay transmit clock delay "rgmii" 0ns 0ns "rgmii-rxid" 2ns 0ns "rgmii-txid" 0ns 2ns "rgmii-id" 2ns 2ns irrespective of RXDLY / TXDLY hardware strapping. > > The tx_delay and rx_delay values were obtained using Rockchip's > > automatic scanning tool: > > https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c > > https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf > > https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf > > Vendors get things wrong, including this. 'rgmii' means the PCB adds > the 2ns delay. Nearly every Rockchip board follows Rockchip broken > vendor recommendations, and then i come along, point out how it is > wrong, and ask for it to be fixed, before being merged to Mainline. Can we at least get the "tx_delay" and "rx_delay" DT properties (which are register values) properly documented in the DT binding document? I know from the driver code that a value of 0 means "no delay". Other values add an unspecified delay - it is not obvious what any non-zero value means, or what the default means. This would help us understand what values such as: tx_delay = 0x3c or 0x4f and rx_delay = 0x2f or 0x26 actually mean in terms of the resulting delay at the MAC. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Russel, On 10/7/25 6:25 PM, Russell King (Oracle) wrote: > On Tue, Oct 07, 2025 at 04:57:32PM +0200, Andrew Lunn wrote: >> On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote: >>> Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道： >>>> Please change it to rgmii-id, and smaller tx/rx_delay values. Or show >>>> us the schematics which clearly show extra long clock lines. >>> >>> In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low, >>> just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced: >>> https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237 >> >> Pull low makes no difference to the 2ns RGMII delays. > > To be clear, while the RXDLY and TXDLY are hardware strapping controls > the hardware configuration of the 2ns RGMII clock delays, the realtek > driver can (and does) override this according to the phy-mode property. > Thus hardware strapping makes no difference to Linux. > > So, what we get at the RTL8211F PHY is: > > phy-mode receive clock delay transmit clock delay > "rgmii" 0ns 0ns > "rgmii-rxid" 2ns 0ns > "rgmii-txid" 0ns 2ns > "rgmii-id" 2ns 2ns > > irrespective of RXDLY / TXDLY hardware strapping. > >>> The tx_delay and rx_delay values were obtained using Rockchip's >>> automatic scanning tool: >>> https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c >>> https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf >>> https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf >> >> Vendors get things wrong, including this. 'rgmii' means the PCB adds >> the 2ns delay. Nearly every Rockchip board follows Rockchip broken >> vendor recommendations, and then i come along, point out how it is >> wrong, and ask for it to be fixed, before being merged to Mainline. > > Can we at least get the "tx_delay" and "rx_delay" DT properties (which > are register values) properly documented in the DT binding document? > I know from the driver code that a value of 0 means "no delay". Other > values add an unspecified delay - it is not obvious what any non-zero > value means, or what the default means. > > This would help us understand what values such as: > > tx_delay = 0x3c or 0x4f > > and > > rx_delay = 0x2f or 0x26 > > actually mean in terms of the resulting delay at the MAC. > I couldn't figure out what they actually mean empirically, see https://lore.kernel.org/linux-rockchip/96d32ce8-394b-4454-8910-a66be2813588@cherry.de/ Without Rockchip's explanation on what this actually does, I'm not sure there's something we can do on this side. Cheers, Quentin
© 2016 - 2026 Red Hat, Inc.