arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++---- arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 5 ++--- arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 5 ++--- 3 files changed, 8 insertions(+), 10 deletions(-)
From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
According to the description in the net documentation, PHY modes
"rgmii", "rgmii-rxid" and "rgmii-txid" modes require the clock signal
to be delayed on the PCB.
The Rockchip platform has long used the above mentioned PHY modes and
private delay prop to describe the internal IO delay settings of the
chip, which is inconsistent with what is described in the documentation.
Some background, for RK3576, you can assume that:
tx_delay_time(ns) = 0.0579 * delay_line_count + 0.105
For example, tx_delay = <0x20> means:
time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns
Recently, Andrew has often mentioned the problem of phy mode in board
level configuration. So let's start with the RK3576 to modify this.
Please test this series of patches, thanks.
Chaoyi Chen (3):
arm64: dts: rockchip: Change gmac phy-mode to rgmii-id for rk3576 evb1
arm64: dts: rockchip: Change gmac phy-mode to rgmii-id for
roc-rk3576-pc
arm64: dts: rockchip: Change gmac phy-mode to rgmii-id for ROCK 4D
arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++----
arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 5 ++---
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 5 ++---
3 files changed, 8 insertions(+), 10 deletions(-)
--
2.51.1
On Wed, Jan 21, 2026 at 11:15:45AM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> According to the description in the net documentation, PHY modes
> "rgmii", "rgmii-rxid" and "rgmii-txid" modes require the clock signal
> to be delayed on the PCB.
>
> The Rockchip platform has long used the above mentioned PHY modes and
> private delay prop to describe the internal IO delay settings of the
> chip, which is inconsistent with what is described in the documentation.
>
> Some background, for RK3576, you can assume that:
>
> tx_delay_time(ns) = 0.0579 * delay_line_count + 0.105
Where did this formula come from? Is it in the datasheet.
Andrew
Hi Andrew, On 1/21/2026 8:57 PM, Andrew Lunn wrote: > On Wed, Jan 21, 2026 at 11:15:45AM +0800, Chaoyi Chen wrote: >> From: Chaoyi Chen <chaoyi.chen@rock-chips.com> >> >> According to the description in the net documentation, PHY modes >> "rgmii", "rgmii-rxid" and "rgmii-txid" modes require the clock signal >> to be delayed on the PCB. >> >> The Rockchip platform has long used the above mentioned PHY modes and >> private delay prop to describe the internal IO delay settings of the >> chip, which is inconsistent with what is described in the documentation. >> >> Some background, for RK3576, you can assume that: >> >> tx_delay_time(ns) = 0.0579 * delay_line_count + 0.105 > > Where did this formula come from? Is it in the datasheet. > These are measured values obtained from hardware signal testing. They are not documented in the TRM. -- Best, Chaoyi
Hi,
On Wed, Jan 21, 2026 at 11:15:45AM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> According to the description in the net documentation, PHY modes
> "rgmii", "rgmii-rxid" and "rgmii-txid" modes require the clock signal
> to be delayed on the PCB.
>
> The Rockchip platform has long used the above mentioned PHY modes and
> private delay prop to describe the internal IO delay settings of the
> chip, which is inconsistent with what is described in the documentation.
>
> Some background, for RK3576, you can assume that:
>
> tx_delay_time(ns) = 0.0579 * delay_line_count + 0.105
>
> For example, tx_delay = <0x20> means:
>
> time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns
>
> Recently, Andrew has often mentioned the problem of phy mode in board
> level configuration. So let's start with the RK3576 to modify this.
>
> Please test this series of patches, thanks.
The RTL8211F PHY driver does not use the "tx-internal-delay-ps"
property, which would require using phy_get_internal_delay(). Also
the hardware only seems to support enabling/disabling a fixed delay
of 2ns, so it cannot be implemented as far as I can tell. So unless
I missed something, this series makes no sense as-is.
My suggestion would be to add support for <rx/tx>-internal-delay-ps
to the Rockchip GMAC driver by introducing a new rk_gmac_ops
entry to translate the standard properties into register values:
int rk3576_delay_conversion(unsigned int delay_ps) {
return (delay_ps*10 - 1050) / 579;
}
That allows using standard properties in DT instead of vendor
specific "rx_delay"/"tx_delay". This results in a much better board
description and shows how far boards derive from the the standard
2ns (which can use rgmii-id without any extra delay specification).
Greetings,
-- Sebastian
Hi Sebastian, Andrew,
On 1/21/2026 1:51 PM, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Jan 21, 2026 at 11:15:45AM +0800, Chaoyi Chen wrote:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> According to the description in the net documentation, PHY modes
>> "rgmii", "rgmii-rxid" and "rgmii-txid" modes require the clock signal
>> to be delayed on the PCB.
>>
>> The Rockchip platform has long used the above mentioned PHY modes and
>> private delay prop to describe the internal IO delay settings of the
>> chip, which is inconsistent with what is described in the documentation.
>>
>> Some background, for RK3576, you can assume that:
>>
>> tx_delay_time(ns) = 0.0579 * delay_line_count + 0.105
>>
>> For example, tx_delay = <0x20> means:
>>
>> time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns
>>
>> Recently, Andrew has often mentioned the problem of phy mode in board
>> level configuration. So let's start with the RK3576 to modify this.
>>
>> Please test this series of patches, thanks.
>
> The RTL8211F PHY driver does not use the "tx-internal-delay-ps"
> property, which would require using phy_get_internal_delay(). Also
> the hardware only seems to support enabling/disabling a fixed delay
> of 2ns, so it cannot be implemented as far as I can tell. So unless
> I missed something, this series makes no sense as-is.
>
> My suggestion would be to add support for <rx/tx>-internal-delay-ps
> to the Rockchip GMAC driver by introducing a new rk_gmac_ops
> entry to translate the standard properties into register values:
>
> int rk3576_delay_conversion(unsigned int delay_ps) {
> return (delay_ps*10 - 1050) / 579;
> }
>
> That allows using standard properties in DT instead of vendor
> specific "rx_delay"/"tx_delay". This results in a much better board
> description and shows how far boards derive from the the standard
> 2ns (which can use rgmii-id without any extra delay specification).
>
Oh, your approach was also my initial thought.
I first asked whether it would be more appropriate to implement this
in the PHY or in the GMAC, and Andrew told me it should preferably be
done in the PHY. But I'm not sure whether all PHYs support this
operation.
Andrew, would it be possible to implement this in the GMAC for cases
where the PHY does not support it? Thanks.
--
Best,
Chaoyi
> > That allows using standard properties in DT instead of vendor
> > specific "rx_delay"/"tx_delay". This results in a much better board
> > description and shows how far boards derive from the the standard
> > 2ns (which can use rgmii-id without any extra delay specification).
> >
>
> Oh, your approach was also my initial thought.
>
> I first asked whether it would be more appropriate to implement this
> in the PHY or in the GMAC, and Andrew told me it should preferably be
> done in the PHY. But I'm not sure whether all PHYs support this
> operation.
>
> Andrew, would it be possible to implement this in the GMAC for cases
> where the PHY does not support it? Thanks.
As i commented to one of the patches, the PHY will be adding 2ns by
default when 'rgmii-id' is used. If you read the RGMII standard, you
also see there is quite a wide tolerance for these delays. So unless
there is a badly designed PCB which needs something well away from
2ns, i don't think it is necessary.
Andrew
© 2016 - 2026 Red Hat, Inc.