Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit bf8f6952 authored by Florian Fainelli's avatar Florian Fainelli Committed by David S. Miller
Browse files

Documentation: net: phy: Add blurb about RGMII



RGMII is a recurring source of pain for people with Gigabit Ethernet
hardware since it may require PHY driver and MAC driver level
configuration hints. Document what are the expectations from PHYLIB and
what options exist.

Reviewed-by: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 2fa3e25b
Loading
Loading
Loading
Loading
+77 −0
Original line number Diff line number Diff line
@@ -65,6 +65,83 @@ The MDIO bus
 drivers/net/ethernet/freescale/fsl_pq_mdio.c and an associated DTS file
 for one of the users. (e.g. "git grep fsl,.*-mdio arch/powerpc/boot/dts/")

(RG)MII/electrical interface considerations

 The Reduced Gigabit Medium Independent Interface (RGMII) is a 12-pin
 electrical signal interface using a synchronous 125Mhz clock signal and several
 data lines. Due to this design decision, a 1.5ns to 2ns delay must be added
 between the clock line (RXC or TXC) and the data lines to let the PHY (clock
 sink) have enough setup and hold times to sample the data lines correctly. The
 PHY library offers different types of PHY_INTERFACE_MODE_RGMII* values to let
 the PHY driver and optionally the MAC driver, implement the required delay. The
 values of phy_interface_t must be understood from the perspective of the PHY
 device itself, leading to the following:

 * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
   internal delay by itself, it assumes that either the Ethernet MAC (if capable
   or the PCB traces) insert the correct 1.5-2ns delay

 * PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay
   for the transmit data lines (TXD[3:0]) processed by the PHY device

 * PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay
   for the receive data lines (RXD[3:0]) processed by the PHY device

 * PHY_INTERFACE_MODE_RGMII_ID: the PHY should insert internal delays for
   both transmit AND receive data lines from/to the PHY device

 Whenever possible, use the PHY side RGMII delay for these reasons:

 * PHY devices may offer sub-nanosecond granularity in how they allow a
   receiver/transmitter side delay (e.g: 0.5, 1.0, 1.5ns) to be specified. Such
   precision may be required to account for differences in PCB trace lengths

 * PHY devices are typically qualified for a large range of applications
   (industrial, medical, automotive...), and they provide a constant and
   reliable delay across temperature/pressure/voltage ranges

 * PHY device drivers in PHYLIB being reusable by nature, being able to
   configure correctly a specified delay enables more designs with similar delay
   requirements to be operate correctly

 For cases where the PHY is not capable of providing this delay, but the
 Ethernet MAC driver is capable of doing so, the correct phy_interface_t value
 should be PHY_INTERFACE_MODE_RGMII, and the Ethernet MAC driver should be
 configured correctly in order to provide the required transmit and/or receive
 side delay from the perspective of the PHY device. Conversely, if the Ethernet
 MAC driver looks at the phy_interface_t value, for any other mode but
 PHY_INTERFACE_MODE_RGMII, it should make sure that the MAC-level delays are
 disabled.

 In case neither the Ethernet MAC, nor the PHY are capable of providing the
 required delays, as defined per the RGMII standard, several options may be
 available:

 * Some SoCs may offer a pin pad/mux/controller capable of configuring a given
   set of pins'strength, delays, and voltage; and it may be a suitable
   option to insert the expected 2ns RGMII delay.

 * Modifying the PCB design to include a fixed delay (e.g: using a specifically
   designed serpentine), which may not require software configuration at all.

Common problems with RGMII delay mismatch

 When there is a RGMII delay mismatch between the Ethernet MAC and the PHY, this
 will most likely result in the clock and data line signals to be unstable when
 the PHY or MAC take a snapshot of these signals to translate them into logical
 1 or 0 states and reconstruct the data being transmitted/received. Typical
 symptoms include:

 * Transmission/reception partially works, and there is frequent or occasional
   packet loss observed

 * Ethernet MAC may report some or all packets ingressing with a FCS/CRC error,
   or just discard them all

 * Switching to lower speeds such as 10/100Mbits/sec makes the problem go away
   (since there is enough setup/hold time in that case)


Connecting to a PHY

 Sometime during startup, the network driver needs to establish a connection