From: Andrew Rembrandt <kernel@rembrandt.dev>
To: Inochi Amaoto <inochiama@gmail.com>
Cc: Yixun Lan <dlan@kernel.org>,
linux-riscv@lists.infradead.org, spacemit@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: dts: spacemit: k3-pico-itx: Fix non-functional ethernet TX timing
Date: Tue, 9 Jun 2026 20:24:46 +0200 [thread overview]
Message-ID: <aihYftGNcpUd4UUR@mcmanus> (raw)
In-Reply-To: <aiemGajqcQeY9avz@inochi.infowork>
On Tue, Jun 09, 2026 at 01:37:56 pm Inochi Amaoto wrote:
> You should set tx-internal-delay-ps of the phy instead of
> the controller. This is a phy in "rgmii-id" mode.
Thanks for the review. I don't think that works on this board, but
please let me know if I'm missing something.
The PHY is a Realtek RTL8211F. Its driver only toggles the chip's fixed
~2ns delay on/off from phy-mode, and per the datasheet that's a hardware
limit, not a driver one -- the RTL8211F has no tunable delay, so a ps
value on the PHY node has nothing to act on.
The only configurable delay element on K3 is the SoC RGMII delay line,
and dwmac-spacemit programs it from tx-/rx-internal-delay-ps read off
the controller node (spacemit_dwmac_probe()), so that is where the
property has to live to take effect. This is the MAC "fine tuning ...
values expected here are small" case described in
Documentation/devicetree/bindings/net/ethernet-controller.yaml: the
RTL8211F supplies the fixed ~2ns via rgmii-id and the MAC adds a 400ps
trim on top. Ideally the PHY would own the delay, but as Andrew Lunn
noted reviewing dwmac-meson8b, that requires the PHY to implement a
configurable delay, which not all do.
The already-merged k1-bananapi-f3 does the same thing: eth1 combines
phy-mode = "rgmii-id" with tx-internal-delay-ps = <250> on the
controller node (via the K1 EMAC rather than dwmac, but the same DT
pattern).
Would you be OK keeping it on the controller given the above? For v2 I
can add an explicit rx-internal-delay-ps = <0> to match the other
SpacemiT boards (k1-bananapi-f3 included) and spell this reasoning out
in the commit message.
Thanks,
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Rembrandt <kernel@rembrandt.dev>
To: Inochi Amaoto <inochiama@gmail.com>
Cc: Yixun Lan <dlan@kernel.org>,
linux-riscv@lists.infradead.org, spacemit@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: dts: spacemit: k3-pico-itx: Fix non-functional ethernet TX timing
Date: Tue, 9 Jun 2026 20:24:46 +0200 [thread overview]
Message-ID: <aihYftGNcpUd4UUR@mcmanus> (raw)
In-Reply-To: <aiemGajqcQeY9avz@inochi.infowork>
On Tue, Jun 09, 2026 at 01:37:56 pm Inochi Amaoto wrote:
> You should set tx-internal-delay-ps of the phy instead of
> the controller. This is a phy in "rgmii-id" mode.
Thanks for the review. I don't think that works on this board, but
please let me know if I'm missing something.
The PHY is a Realtek RTL8211F. Its driver only toggles the chip's fixed
~2ns delay on/off from phy-mode, and per the datasheet that's a hardware
limit, not a driver one -- the RTL8211F has no tunable delay, so a ps
value on the PHY node has nothing to act on.
The only configurable delay element on K3 is the SoC RGMII delay line,
and dwmac-spacemit programs it from tx-/rx-internal-delay-ps read off
the controller node (spacemit_dwmac_probe()), so that is where the
property has to live to take effect. This is the MAC "fine tuning ...
values expected here are small" case described in
Documentation/devicetree/bindings/net/ethernet-controller.yaml: the
RTL8211F supplies the fixed ~2ns via rgmii-id and the MAC adds a 400ps
trim on top. Ideally the PHY would own the delay, but as Andrew Lunn
noted reviewing dwmac-meson8b, that requires the PHY to implement a
configurable delay, which not all do.
The already-merged k1-bananapi-f3 does the same thing: eth1 combines
phy-mode = "rgmii-id" with tx-internal-delay-ps = <250> on the
controller node (via the K1 EMAC rather than dwmac, but the same DT
pattern).
Would you be OK keeping it on the controller given the above? For v2 I
can add an explicit rx-internal-delay-ps = <0> to match the other
SpacemiT boards (k1-bananapi-f3 included) and spell this reasoning out
in the commit message.
Thanks,
Andrew
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-06-09 18:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 18:23 [PATCH] riscv: dts: spacemit: k3-pico-itx: Fix non-functional ethernet TX timing Andrew Rembrandt
2026-06-08 18:23 ` Andrew Rembrandt
2026-06-09 5:37 ` Inochi Amaoto
2026-06-09 5:37 ` Inochi Amaoto
2026-06-09 18:24 ` Andrew Rembrandt [this message]
2026-06-09 18:24 ` Andrew Rembrandt
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=aihYftGNcpUd4UUR@mcmanus \
--to=kernel@rembrandt.dev \
--cc=dlan@kernel.org \
--cc=inochiama@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=spacemit@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.