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

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

[Andre Przywara]

The Allwinner A523 uses the same GPIO voltage "withstand" programming
(setting the input level voltage thresholds) as the previous SoCs, but
for some odd reason inverts the encoding of 1.8V vs. 3.3V.

Add a new bias voltage type to note this difference, and select it for
the A523. At the same time also use the newer "CTL" version, which in
addition allows to turn off the withstand programming for I/O voltages
other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used for
Ethernet PHYs). The A523 has that enable register, but didn't use it
so far.

This fixes eMMC and reportedly Ethernet operation on some A523 boards.

Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner A523")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 2 +-
 drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c   | 2 +-
 drivers/pinctrl/sunxi/pinctrl-sunxi.c         | 6 ++++++
 drivers/pinctrl/sunxi/pinctrl-sunxi.h         | 2 ++
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
index dfdcfa740ecc9..cffc1e53eef14 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
@@ -26,7 +26,7 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
 static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
 	.irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
 	.irq_bank_map = a523_r_irq_bank_map,
-	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
+	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
 	.pin_base = PL_BASE,
 };
 
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
index 801f62abc93df..001bd42afa3ef 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
@@ -26,7 +26,7 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
 static struct sunxi_pinctrl_desc a523_pinctrl_data = {
 	.irq_banks = ARRAY_SIZE(a523_irq_bank_map),
 	.irq_bank_map = a523_irq_bank_map,
-	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
+	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
 };
 
 static int a523_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index cabcb8b6f38e5..634d9f1f23947 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -718,6 +718,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 {
 	unsigned short bank;
 	unsigned long flags;
+	bool inverted = false;
 	u32 val, reg;
 	int uV;
 
@@ -757,6 +758,9 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 		writel(reg | val, pctl->membase +
 		       sunxi_grp_config_reg(pctl, pin));
 		return 0;
+	case BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV:
+		inverted = true;
+		fallthrough;
 	case BIAS_VOLTAGE_PIO_POW_MODE_CTL:
 		val = uV > 1800000 && uV <= 2500000 ? BIT(bank) : 0;
 
@@ -771,6 +775,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 		fallthrough;
 	case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
 		val = uV <= 1800000 ? 1 : 0;
+		if (inverted)
+			val = !val;
 
 		raw_spin_lock_irqsave(&pctl->lock, flags);
 		reg = readl(pctl->membase + pctl->pow_mod_sel_offset);
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index d0936a32123ba..2c8648c3301b6 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -128,8 +128,10 @@ enum sunxi_desc_bias_voltage {
 	 * Bias voltage is set through PIO_POW_MOD_SEL_REG
 	 * and PIO_POW_MOD_CTL_REG register, as seen on
 	 * A100 and D1 SoC, for example.
+	 * Some SoCs invert the encoding for 1.8V vs. 3.3V.
 	 */
 	BIAS_VOLTAGE_PIO_POW_MODE_CTL,
+	BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
 };
 
 struct sunxi_desc_function {
-- 
2.46.4

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

[Per Larsson]

On Wed, 22 Jul 2026 00:39:56 +0200
Andre Przywara <andre.przywara@arm.com> wrote:

> The Allwinner A523 uses the same GPIO voltage "withstand" programming
> (setting the input level voltage thresholds) as the previous SoCs, but
> for some odd reason inverts the encoding of 1.8V vs. 3.3V.
> 
> Add a new bias voltage type to note this difference, and select it for
> the A523. At the same time also use the newer "CTL" version, which in
> addition allows to turn off the withstand programming for I/O voltages
> other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used
> for Ethernet PHYs). The A523 has that enable register, but didn't use
> it so far.
> 
> This fixes eMMC and reportedly Ethernet operation on some A523 boards.
> 
> Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner
> A523") Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---

I'd say this looks like the correct fix. With this (and removing
the incorrect voltage bump "fix") the eMMC on my X96QPro+ works.
Not seeing any regressions, so

Tested-by: Per Larsson <per@palvencia.se>

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

[Juan Manuel López Carrillo]

Hi Andre,

Tested-by: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>

I hit this exact bug on the Orange Pi 4A (T527) from the Ethernet side, so this
confirms the "reportedly Ethernet" with a concrete hardware data point.

Without the fix, GMAC1 (RGMII, YT8531 PHY) is RX-dead: the link comes up at
1Gbps but rx_packets stays 0, so DHCP never completes and the board is
unreachable. The PJ bank rail is 1.8V, but POW_MOD_SEL was left in 3.3V mode, so
the RGMII input thresholds were wrong and the MAC never saw RXC/RXD.

With your patch applied, RX comes back: the board gets a DHCP lease, and a 500 MB
transfer lands with ~365k rx_packets and rx_crc_errors = 0. So the CTL_INV
variant fixes it the right way, at the driver level.

For transparency on what I actually tested: I applied it on top of current
mainline (torvalds 248951ddc14d, v7.2-rc4 + a few). It didn't apply cleanly there
— it looks based on a newer pinctrl-sunxi tree — so I rebased one hunk (the
BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV case in sunxi_pinctrl_set_io_bias_cfg()) onto
that tree; the change itself is unchanged.

FWIW I'd independently reverse-engineered the same inverted encoding (bit=1 ->
3.3V mode on the A523, vs earlier SoCs; the BSP calls it "power_mode_reverse"),
so this matches what I saw on hardware, and I'm glad it's handled generically now
instead of my board-specific DT hack.

One note from poking at this, in case it's useful for edge cases: on this board a
few banks behave specially — PF is the SD UHS 1.8/3.3V switch (best left alone),
and PB/PH take their voltage from VCCIO rather than a per-bank bit. Happy to test
those paths on hardware if useful.

Thanks,
Juan Manuel

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

[Andre Przywara]

On Wed, 22 Jul 2026 19:23:56 +0200
Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com> wrote:

Hi Juan,

> Hi Andre,
> 
> Tested-by: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>
> 
> I hit this exact bug on the Orange Pi 4A (T527) from the Ethernet side, so this
> confirms the "reportedly Ethernet" with a concrete hardware data point.

Thanks, this odd patch of yours (poking POW_MOD_SEL in
pinctrl-sun55i-a523.c) actually made me connect the dots: I looked at
that patch last week, more randomly and out of curiosity, but dismissed
it initially. Then Sashiko commented on my "overvolting" patch pointing
out it changes the "withstand" programming, which reminded me of that
"reversed bits" situation, and I could confirm this with the manual and
an experiment.

> Without the fix, GMAC1 (RGMII, YT8531 PHY) is RX-dead: the link comes up at
> 1Gbps but rx_packets stays 0, so DHCP never completes and the board is
> unreachable. The PJ bank rail is 1.8V, but POW_MOD_SEL was left in 3.3V mode, so
> the RGMII input thresholds were wrong and the MAC never saw RXC/RXD.
> 
> With your patch applied, RX comes back: the board gets a DHCP lease, and a 500 MB
> transfer lands with ~365k rx_packets and rx_crc_errors = 0. So the CTL_INV
> variant fixes it the right way, at the driver level.

Great to hear that, and thanks for testing! There is more to enabling
Ethernet on the box, though, right? The EMAC25M pin needs to be
configured correctly - not even sure that works cleanly with mainline?
And what are the delay values that work for you?
The BSP install on my box is dead, so I cannot poke around there easily.
 
> For transparency on what I actually tested: I applied it on top of current
> mainline (torvalds 248951ddc14d, v7.2-rc4 + a few). It didn't apply cleanly there

Ah yeah, sorry, just saw that I made it in top of my WIP A733 pinctrl
series. I should apply rather cleanly to v7.2-rc1, no?

> — it looks based on a newer pinctrl-sunxi tree — so I rebased one hunk (the
> BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV case in sunxi_pinctrl_set_io_bias_cfg()) onto
> that tree; the change itself is unchanged.
> 
> FWIW I'd independently reverse-engineered the same inverted encoding (bit=1 ->
> 3.3V mode on the A523, vs earlier SoCs; the BSP calls it "power_mode_reverse"),
> so this matches what I saw on hardware, and I'm glad it's handled generically now
> instead of my board-specific DT hack.
> 
> One note from poking at this, in case it's useful for edge cases: on this board a
> few banks behave specially — PF is the SD UHS 1.8/3.3V switch (best left alone),
> and PB/PH take their voltage from VCCIO rather than a per-bank bit. Happy to test

But that is true for all Allwinner SoCs, basically: some ports are
powered by the same VCCIO power pin (typically at 3.3V), and there is
no per-bank supply pin. Look at the data sheet (not user manual), that
mentions that. Also we have a comment to that effect in the DT.

Cheers,
Andre

> those paths on hardware if useful.
> 
> Thanks,
> Juan Manuel
> 

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

[Juan Manuel]

Hi Andre,

> There is more to enabling Ethernet on the box, though, right? The
> EMAC25M pin needs to be configured correctly - not even sure that
> works cleanly with mainline? And what are the delay values that work
> for you?

Right, the withstand fix alone isn't enough. Three things were needed to
get GMAC1 up on the OPi 4A:

1) The PJ pinmux. Mainline's rgmii1 group was missing PJ10, which left
   one RX signal unmapped, so I got rx_packets=0. The BSP muxes the full
   PJ0..PJ15 (16 pins) as function "gmac1" (mux 5); with all 16 mapped,
   RX comes alive. I don't mux any separate/dedicated 25 MHz clock-out
   pin beyond that gmac1 group, and the link is rock solid, so on this
   board the PHY's 25 MHz reference isn't provided by an extra SoC pin.

2) RGMII clock delays. The board has a Motorcomm YT8531 PHY:
     - phy-mode          = "rgmii-rxid"
     - PHY node          : rx-internal-delay-ps = 1900  (YT8531
RXC_DLY_EN, ~1.9ns)
     - MAC syscon        : tx-internal-delay-ps = 100
                           rx-internal-delay-ps = 0
   That combo gives a stable 1 Gbps / full-duplex link, 0% packet loss.

3) Your withstand encoding fix. Before it, the PJ bank was driven at 1.8V
   while the receiver sat in 3.3V mode, so RX was effectively deaf. With
   your patch RX reads correctly.

All of the above is validated on my board (2026-07-08): link up at
1 Gbps/full, ping 0% loss over a sustained transfer.

Thanks again for the withstand fix - glad the POW_MOD_SEL patch helped
connect the dots.

Cheers,
Juan

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

[Andre Przywara]

Hi Juan,

On 7/30/26 19:40, Juan Manuel wrote:
> Hi Andre,
> 
>> There is more to enabling Ethernet on the box, though, right? The
>> EMAC25M pin needs to be configured correctly - not even sure that
>> works cleanly with mainline? And what are the delay values that work
>> for you?
> 
> Right, the withstand fix alone isn't enough. Three things were needed to
> get GMAC1 up on the OPi 4A:

Sorry, there might be some confusion here: I think Chen-Yu already 
mentioned that Ethernet works on his OPi 4A, with just the withstanding fix.
I think I was mixing this up with the X96QPro+ TV box when asking, which 
also uses the second MAC, but has a different setup.
So are you talking about the Orange Pi 4A? Because ...

> 1) The PJ pinmux. Mainline's rgmii1 group was missing PJ10, which left
>     one RX signal unmapped, so I got rx_packets=0. The BSP muxes the full
>     PJ0..PJ15 (16 pins) as function "gmac1" (mux 5); with all 16 mapped,
>     RX comes alive. I don't mux any separate/dedicated 25 MHz clock-out
>     pin beyond that gmac1 group, and the link is rock solid, so on this
>     board the PHY's 25 MHz reference isn't provided by an extra SoC pin.

I think there is some misunderstanding here, probably caused by 
Allwinner's naming of that pin. Pin PJ10 (and PH13, inside the GMAC0 
group) are mere clock fanouts, they connect internally to two gated 
divider clocks, with the main peripheral PLL as their parent. They 
produce a 25 MHz clock signal, which is simply routed out to those pins. 
They work independently of the MACs, and could be even used for 
something else.

On boards which do not use a crystal oscillator to clock the PHY (most 
boards, including the OPi 4A, have an oscillator!), the pin is not 
needed, hence we didn't include it in the pinmux. According to the 
schematic, PJ10 is not even connected on the OPi 4A, so whether you 
include it in the pinmux or not doesn't matter.

So can you please double check this? For PJ10 to have any effect, it 
also would need the associated clock enabled.

And for the records: I think I found now the proper solution to enable 
Ethernet on the X96QPro+: the pinmux for PJ10 gets added, either in the 
PHY, or the MAC DT node. The associated EPHY_25M clock must then be 
referenced by the PHY node. And the respective PHY driver needs to 
enable that clock (some do, others don't).
With those things in place, Ethernet works on the X96QPro+ board, which 
does not feature a crystal oscillator, hence relies on that 25 MHz clock 
output to step in.

> 2) RGMII clock delays. The board has a Motorcomm YT8531 PHY:
>       - phy-mode          = "rgmii-rxid"
>       - PHY node          : rx-internal-delay-ps = 1900  (YT8531
> RXC_DLY_EN, ~1.9ns)
>       - MAC syscon        : tx-internal-delay-ps = 100
>                             rx-internal-delay-ps = 0
>     That combo gives a stable 1 Gbps / full-duplex link, 0% packet loss.

Those settings differ from what's in mainline. What are the results with 
those delays? Does it work as well, and those are just other settings 
that happen to work, because the math works out the same?

Cheers,
Andre

> 3) Your withstand encoding fix. Before it, the PJ bank was driven at 1.8V
>     while the receiver sat in 3.3V mode, so RX was effectively deaf. With
>     your patch RX reads correctly.
> 
> All of the above is validated on my board (2026-07-08): link up at
> 1 Gbps/full, ping 0% loss over a sustained transfer.
> 
> Thanks again for the withstand fix - glad the POW_MOD_SEL patch helped
> connect the dots.
> 
> Cheers,
> Juan

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

[Chen-Yu Tsai]

On Fri, Jul 31, 2026 at 10:08 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> Hi Juan,
>
> On 7/30/26 19:40, Juan Manuel wrote:
> > Hi Andre,
> >
> >> There is more to enabling Ethernet on the box, though, right? The
> >> EMAC25M pin needs to be configured correctly - not even sure that
> >> works cleanly with mainline? And what are the delay values that work
> >> for you?
> >
> > Right, the withstand fix alone isn't enough. Three things were needed to
> > get GMAC1 up on the OPi 4A:
>
> Sorry, there might be some confusion here: I think Chen-Yu already
> mentioned that Ethernet works on his OPi 4A, with just the withstanding fix.
> I think I was mixing this up with the X96QPro+ TV box when asking, which
> also uses the second MAC, but has a different setup.
> So are you talking about the Orange Pi 4A? Because ...

I only said the patch fixes eMMC. Ethernet already worked before. Though
to be honest, ethernet on the A523 has other problems. The performance
is really bad (even RX), and there are errors or packet drops.

ChenYu

> > 1) The PJ pinmux. Mainline's rgmii1 group was missing PJ10, which left
> >     one RX signal unmapped, so I got rx_packets=0. The BSP muxes the full
> >     PJ0..PJ15 (16 pins) as function "gmac1" (mux 5); with all 16 mapped,
> >     RX comes alive. I don't mux any separate/dedicated 25 MHz clock-out
> >     pin beyond that gmac1 group, and the link is rock solid, so on this
> >     board the PHY's 25 MHz reference isn't provided by an extra SoC pin.
>
> I think there is some misunderstanding here, probably caused by
> Allwinner's naming of that pin. Pin PJ10 (and PH13, inside the GMAC0
> group) are mere clock fanouts, they connect internally to two gated
> divider clocks, with the main peripheral PLL as their parent. They
> produce a 25 MHz clock signal, which is simply routed out to those pins.
> They work independently of the MACs, and could be even used for
> something else.
>
> On boards which do not use a crystal oscillator to clock the PHY (most
> boards, including the OPi 4A, have an oscillator!), the pin is not
> needed, hence we didn't include it in the pinmux. According to the
> schematic, PJ10 is not even connected on the OPi 4A, so whether you
> include it in the pinmux or not doesn't matter.
>
> So can you please double check this? For PJ10 to have any effect, it
> also would need the associated clock enabled.
>
> And for the records: I think I found now the proper solution to enable
> Ethernet on the X96QPro+: the pinmux for PJ10 gets added, either in the
> PHY, or the MAC DT node. The associated EPHY_25M clock must then be
> referenced by the PHY node. And the respective PHY driver needs to
> enable that clock (some do, others don't).
> With those things in place, Ethernet works on the X96QPro+ board, which
> does not feature a crystal oscillator, hence relies on that 25 MHz clock
> output to step in.
>
> > 2) RGMII clock delays. The board has a Motorcomm YT8531 PHY:
> >       - phy-mode          = "rgmii-rxid"
> >       - PHY node          : rx-internal-delay-ps = 1900  (YT8531
> > RXC_DLY_EN, ~1.9ns)
> >       - MAC syscon        : tx-internal-delay-ps = 100
> >                             rx-internal-delay-ps = 0
> >     That combo gives a stable 1 Gbps / full-duplex link, 0% packet loss.
>
> Those settings differ from what's in mainline. What are the results with
> those delays? Does it work as well, and those are just other settings
> that happen to work, because the math works out the same?
>
> Cheers,
> Andre
>
> > 3) Your withstand encoding fix. Before it, the PJ bank was driven at 1.8V
> >     while the receiver sat in 3.3V mode, so RX was effectively deaf. With
> >     your patch RX reads correctly.
> >
> > All of the above is validated on my board (2026-07-08): link up at
> > 1 Gbps/full, ping 0% loss over a sustained transfer.
> >
> > Thanks again for the withstand fix - glad the POW_MOD_SEL patch helped
> > connect the dots.
> >
> > Cheers,
> > Juan
>

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

[Juan Manuel López Carrillo]

Hi Andre, Chen-Yu,

> So can you please double check this?

Checked on my Orange Pi 4A (T527, GMAC1, Motorcomm YT8531 PHY). You are right:
PJ10 is not needed on this board.

PJ10 function 5 is RGMII1-EPHY-25M, "25 MHz Output for GMAC PHY" in the A523
manual v1.4. The RGMII1 bus itself is the other 15 pins (PJ0-PJ9, PJ11-PJ15),
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 matches
sunxi/for-next. The Tested-by I sent on 22 July was already measured on plain
mainline without PJ10, so what revived RX here was your withstand fix alone.

> Those settings differ from what's in mainline. What are the results with
> 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 at 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 Ethernet
DT unmodified. I also checked the YT8531 auto-sleep: the first packet after 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 or
GMAC0, I can try to reproduce it here.

Cheers,
Juan

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

[Chen-Yu Tsai]

On Mon, Aug 3, 2026 at 11:37 PM Juan Manuel López Carrillo
<juanmanuellopezcarrillo@gmail.com> 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 right:
> PJ10 is not needed on this board.
>
> PJ10 function 5 is RGMII1-EPHY-25M, "25 MHz Output for GMAC PHY" in the A523
> manual v1.4. The RGMII1 bus itself is the other 15 pins (PJ0-PJ9, PJ11-PJ15),
> 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 matches
> sunxi/for-next. The Tested-by I sent on 22 July was already measured on plain
> mainline without PJ10, so what revived RX here was your withstand fix alone.
>
> > Those settings differ from what's in mainline. What are the results with
> > 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 at 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 Ethernet
> DT unmodified. I also checked the YT8531 auto-sleep: the first packet after 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 or
> 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 machine
on an AMD AI 370 Pro based NAS, I can saturate the link up close to 2.5 Gbps.

If I use a H618-based Orange Pi Zero 3 as the client and the Orange Pi 5 Plus
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

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

[Chen-Yu Tsai]

On Mon, Aug 3, 2026 at 11:51 PM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> On Mon, Aug 3, 2026 at 11:37 PM Juan Manuel López Carrillo
> <juanmanuellopezcarrillo@gmail.com> 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 right:
> > PJ10 is not needed on this board.
> >
> > PJ10 function 5 is RGMII1-EPHY-25M, "25 MHz Output for GMAC PHY" in the A523
> > manual v1.4. The RGMII1 bus itself is the other 15 pins (PJ0-PJ9, PJ11-PJ15),
> > 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 matches
> > sunxi/for-next. The Tested-by I sent on 22 July was already measured on plain
> > mainline without PJ10, so what revived RX here was your withstand fix alone.
> >
> > > Those settings differ from what's in mainline. What are the results with
> > > 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 at 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 Ethernet
> > DT unmodified. I also checked the YT8531 auto-sleep: the first packet after 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 or
> > 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:

Correction, the Orange Pi 5 Plus has Realtek 2.5G NICs, not Intel.

>
>   - 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 machine
> on an AMD AI 370 Pro based NAS, I can saturate the link up close to 2.5 Gbps.
>
> If I use a H618-based Orange Pi Zero 3 as the client and the Orange Pi 5 Plus
> 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

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

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

[Chen-Yu Tsai]

On Wed, Jul 22, 2026 at 6:43 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> The Allwinner A523 uses the same GPIO voltage "withstand" programming
> (setting the input level voltage thresholds) as the previous SoCs, but
> for some odd reason inverts the encoding of 1.8V vs. 3.3V.
>
> Add a new bias voltage type to note this difference, and select it for
> the A523. At the same time also use the newer "CTL" version, which in
> addition allows to turn off the withstand programming for I/O voltages
> other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used for
> Ethernet PHYs). The A523 has that enable register, but didn't use it
> so far.
>
> This fixes eMMC and reportedly Ethernet operation on some A523 boards.
>
> Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner A523")
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>


Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Tested-by: Chen-Yu Tsai <wens@kernel.org> # Fixes eMMC on Orange Pi 4A

> ---
>  drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c   | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c         | 6 ++++++
>  drivers/pinctrl/sunxi/pinctrl-sunxi.h         | 2 ++
>  4 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> index dfdcfa740ecc9..cffc1e53eef14 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> @@ -26,7 +26,7 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
>  static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
>         .irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
>         .irq_bank_map = a523_r_irq_bank_map,
> -       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> +       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
>         .pin_base = PL_BASE,
>  };
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> index 801f62abc93df..001bd42afa3ef 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> @@ -26,7 +26,7 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
>  static struct sunxi_pinctrl_desc a523_pinctrl_data = {
>         .irq_banks = ARRAY_SIZE(a523_irq_bank_map),
>         .irq_bank_map = a523_irq_bank_map,
> -       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> +       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
>  };
>
>  static int a523_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index cabcb8b6f38e5..634d9f1f23947 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -718,6 +718,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
>  {
>         unsigned short bank;
>         unsigned long flags;
> +       bool inverted = false;
>         u32 val, reg;
>         int uV;
>
> @@ -757,6 +758,9 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
>                 writel(reg | val, pctl->membase +
>                        sunxi_grp_config_reg(pctl, pin));
>                 return 0;
> +       case BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV:
> +               inverted = true;
> +               fallthrough;
>         case BIAS_VOLTAGE_PIO_POW_MODE_CTL:
>                 val = uV > 1800000 && uV <= 2500000 ? BIT(bank) : 0;
>
> @@ -771,6 +775,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
>                 fallthrough;
>         case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
>                 val = uV <= 1800000 ? 1 : 0;
> +               if (inverted)
> +                       val = !val;
>
>                 raw_spin_lock_irqsave(&pctl->lock, flags);
>                 reg = readl(pctl->membase + pctl->pow_mod_sel_offset);
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index d0936a32123ba..2c8648c3301b6 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -128,8 +128,10 @@ enum sunxi_desc_bias_voltage {
>          * Bias voltage is set through PIO_POW_MOD_SEL_REG
>          * and PIO_POW_MOD_CTL_REG register, as seen on
>          * A100 and D1 SoC, for example.
> +        * Some SoCs invert the encoding for 1.8V vs. 3.3V.
>          */
>         BIAS_VOLTAGE_PIO_POW_MODE_CTL,
> +       BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
>  };
>
>  struct sunxi_desc_function {
> --
> 2.46.4
>

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

[Andre Przywara]

On Thu, 23 Jul 2026 01:26:38 +0800
Chen-Yu Tsai <wens@kernel.org> wrote:

Hi,

> On Wed, Jul 22, 2026 at 6:43 AM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > The Allwinner A523 uses the same GPIO voltage "withstand" programming
> > (setting the input level voltage thresholds) as the previous SoCs, but
> > for some odd reason inverts the encoding of 1.8V vs. 3.3V.
> >
> > Add a new bias voltage type to note this difference, and select it for
> > the A523. At the same time also use the newer "CTL" version, which in
> > addition allows to turn off the withstand programming for I/O voltages
> > other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used for
> > Ethernet PHYs). The A523 has that enable register, but didn't use it
> > so far.
> >
> > This fixes eMMC and reportedly Ethernet operation on some A523 boards.
> >
> > Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner A523")
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> 
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
> Tested-by: Chen-Yu Tsai <wens@kernel.org> # Fixes eMMC on Orange Pi 4A

so what happens to this fix? Is it good to be merged? And who is going
to take this? Linus? Or does it go through sunxi?

Cheers,
Andre

> > ---
> >  drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 2 +-
> >  drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c   | 2 +-
> >  drivers/pinctrl/sunxi/pinctrl-sunxi.c         | 6 ++++++
> >  drivers/pinctrl/sunxi/pinctrl-sunxi.h         | 2 ++
> >  4 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> > index dfdcfa740ecc9..cffc1e53eef14 100644
> > --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> > @@ -26,7 +26,7 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> >  static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
> >         .irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
> >         .irq_bank_map = a523_r_irq_bank_map,
> > -       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> > +       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
> >         .pin_base = PL_BASE,
> >  };
> >
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> > index 801f62abc93df..001bd42afa3ef 100644
> > --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> > @@ -26,7 +26,7 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> >  static struct sunxi_pinctrl_desc a523_pinctrl_data = {
> >         .irq_banks = ARRAY_SIZE(a523_irq_bank_map),
> >         .irq_bank_map = a523_irq_bank_map,
> > -       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> > +       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
> >  };
> >
> >  static int a523_pinctrl_probe(struct platform_device *pdev)
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> > index cabcb8b6f38e5..634d9f1f23947 100644
> > --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> > @@ -718,6 +718,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
> >  {
> >         unsigned short bank;
> >         unsigned long flags;
> > +       bool inverted = false;
> >         u32 val, reg;
> >         int uV;
> >
> > @@ -757,6 +758,9 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
> >                 writel(reg | val, pctl->membase +
> >                        sunxi_grp_config_reg(pctl, pin));
> >                 return 0;
> > +       case BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV:
> > +               inverted = true;
> > +               fallthrough;
> >         case BIAS_VOLTAGE_PIO_POW_MODE_CTL:
> >                 val = uV > 1800000 && uV <= 2500000 ? BIT(bank) : 0;
> >
> > @@ -771,6 +775,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
> >                 fallthrough;
> >         case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
> >                 val = uV <= 1800000 ? 1 : 0;
> > +               if (inverted)
> > +                       val = !val;
> >
> >                 raw_spin_lock_irqsave(&pctl->lock, flags);
> >                 reg = readl(pctl->membase + pctl->pow_mod_sel_offset);
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> > index d0936a32123ba..2c8648c3301b6 100644
> > --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> > @@ -128,8 +128,10 @@ enum sunxi_desc_bias_voltage {
> >          * Bias voltage is set through PIO_POW_MOD_SEL_REG
> >          * and PIO_POW_MOD_CTL_REG register, as seen on
> >          * A100 and D1 SoC, for example.
> > +        * Some SoCs invert the encoding for 1.8V vs. 3.3V.
> >          */
> >         BIAS_VOLTAGE_PIO_POW_MODE_CTL,
> > +       BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
> >  };
> >
> >  struct sunxi_desc_function {
> > --
> > 2.46.4
> >
>