[PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board

[Alexey Charkov]

On Thu, Jan 8, 2026 at 12:38 PM Chaoyi Chen <chaoyi.chen at rock-chips.com> wrote:
>
> On 1/8/2026 4:11 PM, Alexey Charkov wrote:
> > On Thu, Jan 8, 2026 at 12:02 PM Chaoyi Chen <kernel at airkyi.com> wrote:
> >>
> >> On 1/8/2026 3:42 PM, Chaoyi Chen wrote:
> >>> Hello Alexey, Andrew,
> >>>
> >>> On 1/8/2026 2:53 PM, Alexey Charkov wrote:
> >>>> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew at lunn.ch> wrote:
> >>>>>
> >>>>>> +&gmac0 {
> >>>>>> +     clock_in_out = "output";
> >>>>>> +     phy-mode = "rgmii-rxid";
> >>>>>
> >>>>> rgmii-rxid is odd. Does the PCB really have an extra long TX clock
> >>>>> line, but a short RX clock line?
> >>>>>
> >>>>> Try changing this to rgmii-id, and drop the tx_delay property.
> >>>>
> >>>> Actually it would be great if Rockchip could clarify the delay
> >>>> duration introduced by a single delay element in GMAC-IOMUX delay
> >>>> lines, which are controlled in the GMAC driver by the {tx,rx}_delay
> >>>> properties. Maybe we could then switch to using
> >>>> {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side
> >>>> as envisaged in DT bindings [1], and use phy-mode = "rgmii-id"
> >>>> throughout. Chaoyi, any chance you could ask around in your hardware
> >>>> team?
> >>>>
> >>>> Currently though removing the delays at GMAC side altogether causes
> >>>> unstable link operation - see [2] for example.
> >>>>
> >>>> [1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
> >>>> [2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c
> >>>
> >>> Sorry, this problem has been discussed many times before. It's because
> >>> the gmac on the Rockchip platform currently relies on setting the
> >>> corresponding delay via phy-mode [3].
> >>>
> >>> [3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/
> >>>
> >>> The delay introduced by the delay line is not absolute. In reality,
> >>> it depends on factors such as the chip's design and process technology.
> >>>
> >>> And for RK3576, you can assume that:
> >>>
> >>>       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
> >>>
> >>> And I believe {tx,rx}_internal_delay_ps is indeed a good idea.
> >>> I'll try to add them in v3. Thanks.
> >>>
> >>
> >> I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY,
> >> and compared to doing it in the MAC, which one is the better choice?
> >
> > Your PHY defaults to 1950ps in rgmii-id [1], so adding anything on top
> > of that on GMAC side would land you with a longer total TX delay than
> > you currently get according to the coefficients you've just posted
> > (1784.1ps). I would say go for "tx-internal-delay-ps = <1800>" on the
> > PHY side for the closest match.
> >
> > [1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36
>
> Ah, I thought it was something like this:
>
> &gmac0 {
>         phy-mode = "rgmii";

phy-mode = "rgmii-id";

>         tx-internal-delay-ps = <1784>;

Drop this, as recommended in the lengthy note at the bottom of the
binding doc [1] (the GMAC shouldn't be adding a delay that is close to
2ns).

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L354

> };
>
> But what you actually said was this:
>
> &mdio1 {

&mdio0 I guess (but same applies to gmac1+mdio1)

>         rgmii_phy: ethernet-phy at 1 {
>                 compatible = "ethernet-phy-ieee802.3-c22";
>                 reg = <0x1>;
>                 tx-internal-delay-ps = <1784>;

The PHY binding [2] says it can't accept arbitrary values here - only
150ps increments. So you'll need either 1650 or 1800 to get close to
your calculated value above.

[2] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/motorcomm%2Cyt8xxx.yaml#L36

>         };
> };
>
> These two `tx-internal-delay-ps` things shouldn't be the same, right?

They add up, which you don't need in this case AFAICT.

Best regards,
Alexey