The Ethernet TX performance has been historically bad on Meson8b and
Meson8m2 SoCs because high packet loss was seen. I found out that this
was related (yet again) to the RGMII TX delay configuration.
In the process of discussing the big picture (and not just a single
patch) [0] with Andrew I discovered that the IP block behind the
dwmac-meson8b driver actually seems to support the configuration of the
RGMII RX delay (at least on the Meson8b SoC generation).
Since I sent the first RFC I got additional documentation from Jianxin
(many thanks!). Also I have discovered some more interesting details:
- Meson8b Odroid-C1 requires an RX delay (by either the PHY or the MAC)
Based on the vendor u-boot code (not upstream) I assume that it will
be the same for all Meson8b and Meson8m2 boards
- Khadas VIM2 seems to have the RX delay built into the PCB trace
length. When I enable the RX delay on the PHY or MAC I can't get any
data through. I expect that we will have the same situation on all
GXBB, GXM, AXG, G12A, G12B and SM1 boards. Further clarification is
needed here though (since I can't visually see these lengthened
traces on the PCB). This will be done before sending patches for
these boards.
Dependencies for this series:
There is a soft dependency for patch #2 on commit f22531438ff42c
"dt-bindings: net: dwmac: increase 'maxItems' for 'clocks',
'clock-names' properties" which is currently in Rob's -next tree.
That commit is needed to make the dt-bindings schema validation
pass for patch #2. That patch has been for ~4 weeks in Robs tree,
so I assume that is not going to be dropped.
Changes since RFC v2 at [2]:
- dropped $ref: /schemas/types.yaml#definitions/uint32 from the
"amlogic,rx-delay-ns" in patch #1 ("Don't need to define the
type when in standard units." says Rob - thanks, I learned
something new). Also use "default: 0" for for this property
instead of explaining it in the description text.
- added a note to the cover-letter about a hidden dependency for
dt-binding schema validation in patch #2
- Added Andrew's Reviewed-by to patches 1-7. Thank you again for
the quick and detailed reviews, I appreciate this!
- error out if the (optional) timing-adjustment clock is missing
but we're asked to enable the RGMII RX delay. The MAC won't
work in this specific case and either the RX delay has to be
provided by the PHY or the timing-adjustment clock has to be
added.
- dropped the dts patches (#9-11) which were only added to give
an overview how this is going to be used. those will be sent
separately
- dropped the RFC prefix
Changes since RFC v1 at [1]:
- add support for the timing adjustment clock input (dt-bindings and
in the driver) thanks to the input from the unnamed Ethernet engineer
at Amlogic. This is the missing link between the fclk_div2 clock and
the Ethernet controller on Meson8b (no traffic would flow if that
clock was disabled)
- add support fot the amlogic,rx-delay-ns property. The only supported
values so far are 0ns and 2ns. The registers seem to allow more
precise timing adjustments, but I could not make that work so far.
- add more register documentation (for the new RX delay bits) and
unified the placement of existing register documentation. Again,
thanks to Jianxin and the unnamed Ethernet engineer at Amlogic
- DO NOT MERGE: .dts patches to show the conversion of the Meson8b
and Meson8m2 boards to "rgmii-id". I didn't have time for all arm64
patches yet, but these will switch to phy-mode = "rgmii-txid" with
amlogic,rx-delay-ns = <0> (because the delay seems to be provided by
the PCB trace length).
[0] https://patchwork.kernel.org/patch/11309891/
[1] https://patchwork.kernel.org/cover/11310719/
[2] https://patchwork.kernel.org/cover/11518257/
Martin Blumenstingl (8):
dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
dt-bindings: net: dwmac-meson: Document the "timing-adjustment" clock
net: stmmac: dwmac-meson8b: use FIELD_PREP instead of open-coding it
net: stmmac: dwmac-meson8b: Move the documentation for the TX delay
net: stmmac: dwmac-meson8b: Add the PRG_ETH0_ADJ_* bits
net: stmmac: dwmac-meson8b: Fetch the "timing-adjustment" clock
net: stmmac: dwmac-meson8b: Make the clock enabling code re-usable
net: stmmac: dwmac-meson8b: add support for the RX delay configuration
.../bindings/net/amlogic,meson-dwmac.yaml | 23 ++-
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 146 ++++++++++++++----
2 files changed, 134 insertions(+), 35 deletions(-)
--
2.26.2
Move the documentation for the TX delay above the PRG_ETH0_TXDLY_MASK
definition. Future commits will add more registers also with
documentation above their register bit definitions. Move the existing
comment so it will be consistent with the upcoming changes.
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index c9ec0cb68082..1d7526ee09dd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -33,6 +33,10 @@
#define PRG_ETH0_CLK_M250_SEL_SHIFT 4
#define PRG_ETH0_CLK_M250_SEL_MASK GENMASK(4, 4)
+/* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where 8ns are exactly one
+ * cycle of the 125MHz RGMII TX clock):
+ * 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
+ */
#define PRG_ETH0_TXDLY_MASK GENMASK(6, 5)
/* divider for the result of m250_sel */
@@ -248,10 +252,6 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_RXID:
- /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where
- * 8ns are exactly one cycle of the 125MHz RGMII TX clock):
- * 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
- */
tx_dly_val = dwmac->tx_delay_ns >> 1;
/* fall through */
--
2.26.2
From: Martin Blumenstingl <[email protected]>
Date: Tue, 12 May 2020 23:10:55 +0200
> The Ethernet TX performance has been historically bad on Meson8b and
> Meson8m2 SoCs because high packet loss was seen. I found out that this
> was related (yet again) to the RGMII TX delay configuration.
> In the process of discussing the big picture (and not just a single
> patch) [0] with Andrew I discovered that the IP block behind the
> dwmac-meson8b driver actually seems to support the configuration of the
> RGMII RX delay (at least on the Meson8b SoC generation).
>
> Since I sent the first RFC I got additional documentation from Jianxin
> (many thanks!). Also I have discovered some more interesting details:
> - Meson8b Odroid-C1 requires an RX delay (by either the PHY or the MAC)
> Based on the vendor u-boot code (not upstream) I assume that it will
> be the same for all Meson8b and Meson8m2 boards
> - Khadas VIM2 seems to have the RX delay built into the PCB trace
> length. When I enable the RX delay on the PHY or MAC I can't get any
> data through. I expect that we will have the same situation on all
> GXBB, GXM, AXG, G12A, G12B and SM1 boards. Further clarification is
> needed here though (since I can't visually see these lengthened
> traces on the PCB). This will be done before sending patches for
> these boards.
...
Series applied to net-next, thanks Martin.