> > I would actually say it shows we don't understand what is going on
> > with delays. "rgmii" is not every often the correct value. The fact it
> > works suggests the MAC is adding delays.
> >
> > What value are you using for starfive,gtxclk-dlychain ?
>
> This is set to '4' in patch 12/12.
>
> > Try 0 and then "rgmii-id"
>
> I made some more tests and it seems the only stable configuration is "rgmii"
> with "starfive,gtxclk-dlychain" set to 4:
>
> phy-mode | dlychain | status
> ---------+----------+--------------------------------------------
> rgmii | 4 | OK (no issues observed)
> rgmii-id | 4 | BROKEN (errors reported [1])
> rgmii | 0 | UNRELIABLE (no errors, but frequent stalls)
> rgmii-id | 0 | BROKEN (errors reported)
>
> [1] Reported errors in case of BROKEN status:
> $ grep '' /sys/class/net/eth0/statistics/* | grep -v ':0$'
Thanks for the testing.
So it seems like something is adding delays when it probably should
not. Ideally we want to know what.
There is a danger here, something which has happened in the past. A
PHY which ignored "rgmii" and actually did power on defaults which was
"rgmii-id". As a result, lots of boards put "rmgii" in there DT blob,
which 'worked'. Until a board came along which really did need
"rgmii". The developer bringing that board up debugged the PHY, found
the problem and made it respect "rgmii" so their board worked. And the
fix broke a number of 'working' boards which had the wrong "rgmii"
instead of "rgmii-id".
So you have a choice. Go with 4 and "rgmii", but put in a big fat
warning, "Works somehow but is technically wrong and will probably
break sometime in the future". Or try to understand what is really
going on here, were are the delays coming from, and fix the issue.
Andrew
