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

[Juan Manuel López Carrillo]

Hi Chen-Yu,

Sorry for the slow reply, and thanks for taking the time to measure this.

> On my Orange Pi 4A, running iperf3 [...] 4A as client: ~180 Mbps
> 4A as client but with reverse transfer (-R): ~520 Mbps
> Something is definitely off. I don't know what though.

I cannot reproduce that here. Since you asked with iperf3, here are iperf3
numbers from my Orange Pi 4A, and one measurement that I think is more
useful than the throughput itself.

Bench: direct Cat 5e cable between the board and my PC, no switch in
between, link negotiated at 1000/full. iperf3 3.18 and Debian 13 on both,
board at 10.42.0.52, PC at 10.42.0.1. Kernel is my own 6.18.40 tree.

  board -> PC   (iperf3 -c 10.42.0.1 -t 10)        943 / 941 Mbits/s
  PC -> board   (iperf3 -c 10.42.0.1 -t 10 -R)     930 / 928 Mbits/s

Retr 0 in both directions, and rx_errors, rx_dropped, tx_errors,
tx_dropped and rx_crc_errors all still 0 afterwards.

The number I would look at is the cost: sustaining 943 Mbits/s takes
about 3% of the eight cores here, which is roughly a quarter of one A55,
with ~8500 eth0 interrupts per second. The little cluster was pinned at
1416 MHz for that run.

So on this board the link is not expensive to saturate, and that is the
part worth comparing with yours. If one core on your 4A is at 100% si/sy
during the run, we are looking at a CPU-side limit; if no core is busy,
the CPU is not the story at all and it is somewhere in the MAC, the PHY
link or the path. That single observation would split the problem in two,
and it costs you one `top` next to the iperf3 run.

There is one difference between our setups that I can name precisely. On
plain v7.2-rc7 there is nothing for cpufreq to attach to on this SoC:

  - drivers/clk/sunxi-ng only builds the main, MCU and R CCUs for the
    A523, so there is no CPU clock controller;
  - the cpu@N nodes in sun55i-a523.dtsi are bare "arm,cortex-a55" plus
    psci, with no operating-points-v2, no clocks and no cpu-map;
  - sun50i-cpufreq-nvmem matches h6, a100, h616, h618 and h700, not the
    A523.

My tree carries all three out of tree, so the cores scale here and on
plain mainline they stay wherever the bootloader left them: mainline
U-Boot 2026.07 hands mine off at 768 MHz.

I want to argue against my own suggestion, though, because the numbers
above do not fully support it. If saturating the link costs a quarter of
one A55 at 1416 MHz, the same work at 768 MHz should cost roughly 44% of
one core, which still leaves headroom. Falling to 180 Mbits/s would need
about five times the per-byte cost, and the clock ratio only accounts for
1.8x of that. So the missing cpufreq support may well be a contributing
factor, but on its own it does not explain your number.

What I can do, if it is useful to you: rerun exactly the above on the
same board and cable on top of v7.2-rc7, twice. Once with just your
withstand fix, which is the smallest thing that gives me a working link
there, and once with that plus only the CPU clock controller and the OPP
tables. Same base, same config, one variable. I would report throughput
per direction, scaling_cur_freq during the run and per-core softirq,
which should at least tell us how much of the gap the clock can account
for.

To match your setup as closely as I can: which kernel and defconfig are
you running on the 4A, what MTU, which governor, and is the 5 Plus the
iperf3 server in both directions?

Cheers,
Juan