From: Zhi Li <lizhi2@eswincomputing.com>
The second Ethernet controller (eth1) on the EIC7700 SoC may experience
RX data sampling issues at high speed due to EIC7700-specific receive
clock to data skew at the MAC input.
On the EIC7700 SoC, the second Ethernet controller (eth1) requires
inversion of the internal RGMII receive clock in order to meet RX data
sampling timing at high speed.
Describe this SoC-specific difference by introducing a distinct compatible
string for MAC instances that require internal clock inversion, allowing the
driver to select the appropriate configuration without relying on per-board
vendor-specific properties.
The rx-internal-delay-ps and tx-internal-delay-ps properties now use
minimum and maximum constraints to reflect the actual hardware delay
range (0-2400 ps) applied in 20 ps steps. This relaxes the binding
validation compared to the previous enum-based definition and avoids
regressions for existing DTBs while keeping the same hardware limits.
In addition, the binding now includes additional background information
about the HSP CSR registers accessed by the MAC. The TXD and RXD delay
control registers are included so the driver can explicitly clear any
residual configuration left by the bootloader. Background reference for
the High-Speed Subsystem and HSP CSR block is available in Chapter 10
("High-Speed Interface") of the EIC7700X SoC Technical Reference Manual,
Part 4 (EIC7700X_SoC_Technical_Reference_Manual_Part4.pdf):
https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
There are currently no in-tree users of the EIC7700 Ethernet driver, so
these changes are safe.
Fixes: 888bd0eca93c ("dt-bindings: ethernet: eswin: Document for EIC7700 SoC")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
---
.../bindings/net/eswin,eic7700-eth.yaml | 63 ++++++++++++++++---
1 file changed, 54 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
index 91e8cd1db67b..8a7035dfd4a2 100644
--- a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
+++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
@@ -20,6 +20,7 @@ select:
contains:
enum:
- eswin,eic7700-qos-eth
+ - eswin,eic7700-qos-eth-clk-inversion
required:
- compatible
@@ -28,9 +29,13 @@ allOf:
properties:
compatible:
- items:
- - const: eswin,eic7700-qos-eth
- - const: snps,dwmac-5.20
+ oneOf:
+ - items:
+ - const: eswin,eic7700-qos-eth
+ - const: snps,dwmac-5.20
+ - items:
+ - const: eswin,eic7700-qos-eth-clk-inversion
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -63,16 +68,27 @@ properties:
- const: stmmaceth
rx-internal-delay-ps:
- enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+ minimum: 0
+ maximum: 2400
tx-internal-delay-ps:
- enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+ minimum: 0
+ maximum: 2400
eswin,hsp-sp-csr:
description:
HSP CSR is to control and get status of different high-speed peripherals
(such as Ethernet, USB, SATA, etc.) via register, which can tune
board-level's parameters of PHY, etc.
+
+ Additional background information about the High-Speed Subsystem
+ and the HSP CSR block is available in Chapter 10 ("High-Speed Interface")
+ of the EIC7700X SoC Technical Reference Manual, Part 4
+ (EIC7700X_SoC_Technical_Reference_Manual_Part4.pdf). The manual is
+ publicly available at
+ https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
+
+ This reference is provided for background information only.
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
@@ -81,7 +97,9 @@ properties:
or external clock selection
- description: Offset of AXI clock controller Low-Power request
register
+ - description: Offset of register controlling TXD delay
- description: Offset of register controlling TX/RX clock delay
+ - description: Offset of register controlling RXD delay
required:
- compatible
@@ -111,17 +129,44 @@ examples:
interrupts = <61>;
interrupt-names = "macirq";
phy-mode = "rgmii-id";
- phy-handle = <&phy0>;
+ phy-handle = <&gmac0_phy0>;
resets = <&reset 95>;
reset-names = "stmmaceth";
+ rx-internal-delay-ps = <20>;
+ tx-internal-delay-ps = <100>;
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x114 0x118 0x11c>;
+ snps,axi-config = <&stmmac_axi_setup_gmac0>;
+ snps,aal;
+ snps,fixed-burst;
+ snps,tso;
+ stmmac_axi_setup_gmac0: stmmac-axi-config {
+ snps,blen = <0 0 0 0 16 8 4>;
+ snps,rd_osr_lmt = <2>;
+ snps,wr_osr_lmt = <2>;
+ };
+ };
+
+ ethernet@50410000 {
+ compatible = "eswin,eic7700-qos-eth-clk-inversion", "snps,dwmac-5.20";
+ reg = <0x50410000 0x10000>;
+ clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
+ <&d0_clock 194>;
+ clock-names = "axi", "cfg", "stmmaceth", "tx";
+ interrupt-parent = <&plic>;
+ interrupts = <70>;
+ interrupt-names = "macirq";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&gmac1_phy0>;
+ resets = <&reset 94>;
+ reset-names = "stmmaceth";
rx-internal-delay-ps = <200>;
tx-internal-delay-ps = <200>;
- eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118>;
- snps,axi-config = <&stmmac_axi_setup>;
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x200 0x208 0x214 0x218 0x21c>;
+ snps,axi-config = <&stmmac_axi_setup_gmac1>;
snps,aal;
snps,fixed-burst;
snps,tso;
- stmmac_axi_setup: stmmac-axi-config {
+ stmmac_axi_setup_gmac1: stmmac-axi-config {
snps,blen = <0 0 0 0 16 8 4>;
snps,rd_osr_lmt = <2>;
snps,wr_osr_lmt = <2>;
--
2.25.1
> The rx-internal-delay-ps and tx-internal-delay-ps properties now use
> minimum and maximum constraints to reflect the actual hardware delay
> range (0-2400 ps) applied in 20 ps steps.
> rx-internal-delay-ps:
> - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> + minimum: 0
> + maximum: 2400
multipleOf: 20
Also, 2400 / 20 = 120. Is the real maximum 127 * 20 = 2540?
> @@ -111,17 +129,44 @@ examples:
> interrupts = <61>;
> interrupt-names = "macirq";
> phy-mode = "rgmii-id";
> - phy-handle = <&phy0>;
> + phy-handle = <&gmac0_phy0>;
> resets = <&reset 95>;
> reset-names = "stmmaceth";
> + rx-internal-delay-ps = <20>;
> + tx-internal-delay-ps = <100>;
I would not include them in the example. You are going to get
developers blindly copying this into real DT. A well designed board
should not need delays.
Andrew
© 2016 - 2026 Red Hat, Inc.