Re: [PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding

On Mon, Aug 3, 2026 at 11:37=E2=80=AFPM Juan Manuel L=C3=B3pez Carrillo
<[email protected]> wrote:
>
> Hi Andre, Chen-Yu,
>
> > So can you please double check this?
>
> Checked on my Orange Pi 4A (T527, GMAC1, Motorcomm YT8531 PHY). You are r=
ight:
> PJ10 is not needed on this board.
>
> PJ10 function 5 is RGMII1-EPHY-25M, "25 MHz Output for GMAC PHY" in the A=
523
> manual v1.4. The RGMII1 bus itself is the other 15 pins (PJ0-PJ9, PJ11-PJ=
15),
> which mainline already has. My claim came from a stale comment in my tree=
, from
> when I was chasing the dead RX. It is gone now and my rgmii1 group matche=
s
> sunxi/for-next. The Tested-by I sent on 22 July was already measured on p=
lain
> mainline without PJ10, so what revived RX here was your withstand fix alo=
ne.
>
> > Those settings differ from what's in mainline. What are the results wit=
h
> > those delays?
>
> Measured on the same board, DTB-only changes, TCP for 10 s per direction:
>
>   A  mine (rgmii-rxid, MAC tx 100 / rx 0, PHY rx 1900 ps)
>         TX 0.938-0.940   RX 0.929-0.930 Gbit/s
>   B  mainline delays (rgmii-id, MAC tx 0 / rx 300, none on the PHY)
>         TX 0.941   RX 0.929 Gbit/s
>   C  the Ethernet path exactly as mainline has it
>      (B, minus motorcomm,auto-sleep-disabled, minus PJ10)
>         TX 0.941   RX 0.929 Gbit/s
>
> All three saturate the link, with rx_errs, rx_drop, tx_errs and tx_drop a=
t 0
> over roughly 1.6 million packets each. So mine are just other values that
> work, and I am dropping them in favour of mainline's.
>
> > ethernet on the A523 has other problems. The performance is really bad
> > (even RX), and there are errors or packet drops.
>
> I do not see that on this board, not even with C, which is mainline's Eth=
ernet
> DT unmodified. I also checked the YT8531 auto-sleep: the first packet aft=
er 5,
> 10, 20, 30 and 45 s of silence came back in 0.21-0.24 ms, no losses.
>
> The kernel is my own 6.18-based tree, although stmmac and motorcomm.c are
> stock, and this is one board with one PHY. Chen-Yu, which board and which=
 MAC
> are you seeing it on, and how do you measure it? If it is another board o=
r
> GMAC0, I can try to reproduce it here.

On my Orange Pi 4A, running iperf3 between it and another Orange Pi 5 Plus
(which has Intel PCIe NICs) as the server:

  - 4A as client: ~180 Mbps
  - 4A as client but with reverse transfer (-R): ~520 Mbps

Now if I do the same test between the Orange Pi 5 Plus and my virtual machi=
ne
on an AMD AI 370 Pro based NAS, I can saturate the link up close to 2.5 Gbp=
s.

If I use a H618-based Orange Pi Zero 3 as the client and the Orange Pi 5 Pl=
us
as the server:

  - Zero 3: ~920 Mbps
  - Zero 3 with reverse: ~280 Mbps

And I think my Cubie A5E and Avaota A1 fared even worse.


Something is definitely off. I don't know what though.


ChenYu