[linux-next-v2 1/5] arm64: dts: rockchip: Fix gmac phy mode to rgmii on Rock 3A SBC.

Anand Moon linux.amoon at gmail.com
Tue Nov 22 06:19:42 PST 2022


Hi Peter / Michael

On Fri, 18 Nov 2022 at 23:43, Peter Geis <pgwipeout at gmail.com> wrote:
>
> On Fri, Nov 18, 2022 at 4:35 AM Anand Moon <linux.amoon at gmail.com> wrote:
> >
> > Hi Michael,
> >
> > On Fri, 18 Nov 2022 at 12:33, Michael Riesch
> > <michael.riesch at wolfvision.net> wrote:
> > >
> > > Hi Anand,
> > >
> > > On 11/16/22 21:01, Anand Moon wrote:
> > > > On rk356x ethernet phy support reduced media independent interface (RMII)
> > > > and reduced gigabit media independent interface (RGMII).
> > > > So set the phy mode to rgmii to support clock delay, also
> > > > add TX and RX delay for phy-mode.
> > >
> > > Based on this commit message I still don't understand what you are
> > > actually trying to fix here. If you encounter network problems/stability
> > > issues, please let me know what test triggers the faulty behavior.
> > > Please describe the problem you are facing in detail here or in the
> > > cover letter.
> > >
> >
> > Ok, Ethernet does not work on my Radxa 3A see boot logs.
> >
> > [0] https://gist.github.com/moonlinux/bb56c787031226fbb9f69121564e76a2
> >
> > Please find this updated commit message.
> >
> > As per the schematic and datasheet PHY mode is RGMII
> > Use 2ns clock delay to RXC for RXD and TXC for TXD latching.
>
> rgmii-id mode does exactly this in the phy (your realtek chip). By
> setting the mode to rgmii, you're telling the phy that delays are set
> elsewhere, either in hardware or in the controller. You're then
> handling them in the controller. While the delays aren't documented in
> the TRM, I've long suspected that the defaults of 0x30 and 0x10 equate
> to the standard 2ns delay. So you're setting the delays much higher
> than the default means you need to add *more* than the standard 2ns
> delay for your device to work.
>

TX and RX clock delay might have been updated for
     ID: 0x30, Synopsys ID: 0x51  DWMAC4/5

As per the schematic [0]
https://dl.radxa.com/rock3/docs/hw/3a/rock3a_v1.3_sch.pdf
   Pull-up for additional 2ns delay to RXC for data latching
   Pull-up for additional 2ns delay to TXC for data latching

As per the datasheet [1]
https://dl.radxa.com/rock3/docs/hw/datasheet/RTL8211F-CG-Datasheet.pdf
TXDLY   RGMII            Transmit Clock Timing Control.
    1: Add 2ns delay to RXC for RXD latching (via 4.7k-ohm to DVDD_RG)
    0: No delay (via 4.7k-ohm to GND)
RXDLY RGMII Receive Clock Timing Control.
    1: Add 2ns delay to RXC for RXD latching (via 4.7k-ohm to DVDD_RG)
    0: No delay (via 4.7k-ohm to GND)

tx_delay and rx_delay might be suitable for old DWMAC
hence it does not apply to this new Ethernet controller.
I have tested with remove these from the dts and
adding the following as this is required for rgmii mode.
       rx-internal-delay-ps = <2000>;
       tx-internal-delay-ps = <2000>;

I don't mind setting the defaults of 0x30 and 0x10 to equate
to the standard 2ns delay. but it does not have any effect
on the current ethernet controller.

> This is why I've been asking if you have tested these. You need to set
> each value and find the lowest and highest possible values that work,
> then take the median value between those two.
>

Yes, I have tested with and without those values.

Thanks
-Anand
> >
> > > > Fix the following warning
> > > >
> > > > [    7.365215] rk_gmac-dwmac fe010000.ethernet: Can not read property: tx_delay.
> > > > [    7.365219] rk_gmac-dwmac fe010000.ethernet: set tx_delay to 0x30
> > > > [    7.365224] rk_gmac-dwmac fe010000.ethernet: Can not read property: rx_delay.
> > > > [    7.365228] rk_gmac-dwmac fe010000.ethernet: set rx_delay to 0x10
> > >
> > > If the only purpose of this patch is to get rid of this warnings, it may
> >
> > No, the intent is to fix the PHY mode to RGMII and fix the delay.
> > [ 7.066357] rk_gmac-dwmac fe010000.ethernet: init for RGMII_ID
> >
> > > make sense to set them to dev_dbg as Peter pointed out.
> > >
> > Ok, will update this in the next version.
> >
> > > Best regards,
> > > Michael
> > >
> > Thanks
> > -Anand



More information about the Linux-rockchip mailing list