Message-ID:
 <SEYPR06MB5134BC17E80DB66DD385024D9DD1A@SEYPR06MB5134.apcprd06.prod.outlook.com>
Date: Tue, 25 Nov 2025 02:58:33 +0000
From: Jacky Chou <jacky_chou@...eedtech.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
	<conor+dt@...nel.org>, Po-Yu Chuang <ratbert@...aday-tech.com>, Joel Stanley
	<joel@....id.au>, Andrew Jeffery <andrew@...econstruct.com.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "taoren@...a.com" <taoren@...a.com>
Subject: [PATCH net-next v4 4/4] net: ftgmac100: Add RGMII delay support for
 AST2600

> > Based on the above information, I have attempted to outline my
> understanding.
> > 1. 'rgmii' + MAC delay:
> > Add warming, keep MAC delay and pass "rgmii-id" to PHY driver.
> 
> Think about that. What delays do you get as a result?
> 
> > 2. 'rgmii-id' + MAC delay:
> > disable MAC delay and pass "rgmii-id" to PHY driver
> >
> > 3. 'rgmii-id' + no MAC delay:
> > Keep disabling MAC delay and pass "rgmii-id" to PHY driver
> >
> > 4. 'rgmii-txid' or 'rgmii-rxid':
> > Keep original setting
> 
> > I have some idea to discuss with you.
> > 1. On 'rgmii', I want to add warming and directly disable MAC delay and pass
> 'rgmii-id'
> > to PHY driver.
> 
> Yep.
> 
> >
> > 2. On 'rgmii-id', ignore if enabling MAC delay, all disable MAC delay and pass
> ' rgmii-id'
> > to PHY driver.
> >
> > 3. On 'rgmii-txid' or 'rgmii-rxid', keep the above item 4.
> >
> > Actually, it's difficult for the driver to determine whether the MAC delay is
> enabled or not.
> > Our design doesn't use a single bit to indicate the delay state.
> > Instead, the delay setting is derived from the user's configured delay value.
> 
> But you can turn it back to ps. I would say, if it is > 1000, the intention is it
> provides the 2ns delay. If it is < 1000 it is just a minor tuning value because of
> bad board design.
> 
> Do you have experience from the field, what do real boards use? Are they all
> inserting the same 2ns? Or is each customer tuning their bootloader to
> configure the hardware differently per board design?
> 
> You might even need a more complex solution. If the bootloader is adding a
> delay between say 200ps and 1600ps, it suggests a poorly designed board, and
> the PHY adding 2ns is not going to work. There is a need for
> rx-internal-delay-ps or tx-internal-delay-ps in DT. You can give a warning, and
> indicate what values are needed, but leave the hardware alone. If the
> bootloader is setting the delay > 1600, passing _RGMII_ID to the PHY, and
> disabling MAC delays is likely to work, so you just need to warn about
> phy-mode being wrong. If the bootloader is inserting < 200ps, and phy-mode is
> rgmii-id, that is just fine tuning. Maybe suggest rx-internal-delay-ps or
> tx-internal-delay-ps be added in DT, but leave it alone.
> 
> Whatever you do, you need a lot of comments in the code and the commit
> message to help developers understand why they are seeing warnings and
> what they need to do.
> 

I try to summary in the following informations that I understand.

1. with rx-internal-delay-ps OR tx-internal-delay-ps OR both

  Use "rx/tx-internal-delay-ps" property to configure RGMII delay at MAC side
  Pass "phy-mode" to PHY driver by calling of_phy_get_and_connect()

2. withour rx-internal-delay-ps AND tx-internal-delay-ps

  If "phy-mode" is 'rgmii-rxid' or 'rgmii-txid':
	Keep original delay
	Print Warning message
	  "Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"

There are FOUR conditions in delay configuration:
'X' means RGMII delay setting from bootloader
A: 7500 <= X <= 8000, 0 <= X <= 500
	Mean "Disable RGMII delay" at MAC side
B: 500 < X < 1500
C: 1500 <= X <= 2500
	Mean "Enable RGMII delay" at MAC side
D: 2500 < X < 7500

  If "phy-mode" is 'rgmii':
	Condition A:
		Keep original delay
		Update "phy-mode" to 'rgmii-id'
		Print Information message
			"Forced 'phy-mode' to rgmii-id"
	Condition B and D
		Keep original delay
		Print Warning message
	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"
	Condition C:
		Disable RGMII delay at MAC side
		Update "phy-mode" to 'rgmii-id'
		Print Warning message
	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"

  If "phy-mode" is 'rgmii-id':
	Condition A:
		Keep original delay
		Keep "phy-mode" to 'rgmii-id'
	Condition B and D
		Keep original delay
		Print Warning message
	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"
	Condition C:
		Disable RGMII delay at MAC side
		Update "phy-mode" to 'rgmii-id'
		Print Warning message
	  		"Update 'phy-mode' to rgmii-id and add 'rx/tx-internal-delay-ps'"

On 'rgmii' and 'rgmii-id', just condition A is different.



Because the driver may need to update the "phy-mode" of dts, it need to add
CONFIG_OF_DYNAMIC in ftgma100 of Kconfig.

I list the flow in probe() in ftgmac100 driver.
-> probe()
  -> Check and configure the RGMII delay of AST2600
    -> Call of_phy_get_and_connect()

Because of_phy_get_and_connect() will get the "phy-mode" from dts,
The driver needs to update the "phy-mode" before calling this API to
Connect PHY driver.

I consider these adjustments can cover older board designs and remind user to update
their DTS and can also introduce new board designs with 'rx/tx-internal-delay-ps'.

Thanks,
Jacky

Powered by blists - more mailing lists