Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Juan Manuel <juanmanuellopezcarrillo@gmail.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Chen-Yu Tsai <wens@kernel.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding
Date: Fri, 31 Jul 2026 15:08:31 +0200	[thread overview]
Message-ID: <c539e5c4-f21e-49a1-b0e3-d35f42893fc4@arm.com> (raw)
In-Reply-To: <CA+c=wxVB-cEncgBE12S2YgXhL7DVgRyg12_4jJ-CjxzBjK62kw@mail.gmail.com>

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



  reply	other threads:[~2026-07-31 13:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 22:39 [PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding Andre Przywara
2026-07-22 12:17 ` Per Larsson
2026-07-22 17:23 ` Juan Manuel López Carrillo
2026-07-22 22:23   ` Andre Przywara
2026-07-30 17:40     ` Juan Manuel
2026-07-31 13:08       ` Andre Przywara [this message]
2026-07-31 13:20         ` Chen-Yu Tsai
2026-08-03 15:35           ` Juan Manuel López Carrillo
2026-08-03 15:51             ` Chen-Yu Tsai
2026-08-04 18:11               ` Chen-Yu Tsai
2026-08-10 17:22                 ` Juan Manuel López Carrillo
2026-07-22 17:26 ` Chen-Yu Tsai
2026-09-10 20:13   ` Andre Przywara
2026-09-13 15:34     ` Chen-Yu Tsai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c539e5c4-f21e-49a1-b0e3-d35f42893fc4@arm.com \
    --to=andre.przywara@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=juanmanuellopezcarrillo@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=samuel@sholland.org \
    --cc=wens@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox