Re: [PATCH net-next v3 0/5] net: stmmac: Add support for Allwinner A733 GMAC210

[Jerome Brunet]

On ven. 25 sept. 2026 at 21:45, Andrew Lunn <andrew@xxxxxxx> wrote:

>> > You need to differentiate between small fine tuning delays, and the
>> > 2ns delay required by the RGMII standard. If the MAC is just doing
>> > fine tuning, you need to still pass PHY_INTERFACE_MODE_RGMII_ID so the
>> > PHY adds the 2ns delay. If the MAC is adding a big delay, you need to
>> > pass PHY_INTERFACE_MODE_RGMII to the PHY.
>> 
>> The PHY is one concern but the series here does not really address this
>> topic. DTS and board specific concerns will come later.
>
> They are all interconnected. When phy-mode says 'rgmii-id', it is the
> MAC/PHY pair which needs to decide who adds the delay. If the phy-mode
> is 'na', how does the MAC know it needs to use RGMII, not MII, as you
> said.
>
> We need to keep the big picture in mind, otherwise you could go down a
> dead end, and a dead end which makes backwards compatibility really
> messy.

I agree with you with on all this. I understand this particular MAC/PHY
combo is sparking this discussion, Let's sort this out properly, no
rush.

I'm merely pointing out that the problem is not introduced by the code
submited here. Other MAC can set delays, Other MACs would need to handle
mis-behaving PHY too.

>
>> It is really just the MAC. So, how does the MAC is supposed to
>> make the decision to amend the PHY mode ? is there a threshold you'd
>> like to recommend for this differentiation ? 
>
> This is the first time we have had this condition. So it has not
> really been thought about too much. Maybe 1ns. That is the middle of
> the 2ns required by RGMII.
>
>> I'll try to reach out, just in case. I have the schematics but without
>> the PHY doc, it does not help much.
>
> From that i assume you missed the other emails. Somebody from ARM give
> a link to the data sheet. It documents the strapping. Search for the
> patch adding the PHY driver, it is in that thread.
>

Thanks for the heads up. So if I'm reading the doc correctly the PHY
adds 2ns
 * on RX if there a 4.7k pull-up on RXD0
 * on TX if there a 4.7k pull-up on RXD1

The schematics for the board are available here [1]

* 4.7k pull-up on RXD0: so we should have 2ns Rx from the PHY
* 4.7k pull-down on RXD1: no idea what this does. Presumably no delay ?

I've cross-checked the HW, the resistors are actually fitted as the
schematic says they are.

With the HW setup, the MAC setup that works for me remains

	tx-internal-delay-ps = <1620>;
	rx-internal-delay-ps = <1800>;

I know it is not aligned with what it expected but still.

I've tried with
 * rx-internal-delay-ps = <0>. No Rx.
 * tx-internal-delay-ps at 1800ps, it still works with some TCP retries here and
   there on iperf3. 1980ps stalls after just a few packets.

[1]: https://dl.radxa.com/cubie/a7a/docs/hw/radxa_cubie_a7a_v1.10_schematic.pdf

> 	Andrew

-- 
Jerome