[PATCH v3 8/8] dt-bindings: net: ethernet-controller: tabulate who adds the RGMII delays

Martin Blumenstingl martin.blumenstingl at googlemail.com
Sat Oct 10 15:37:13 PDT 2026


Hi Andrew, Hi Lucas,

On Sat, Oct 10, 2026 at 12:59 PM Lucas Tanure <tanure at linux.com> wrote:
[...]
> +#   phy-mode    tx-internal-delay-ps  rx-internal-delay-ps  TX delay    RX delay
> +#   rgmii       -                     -                     PCB trace   PCB trace
> +#   rgmii-id    -                     -                     PHY         PHY
> +#   rgmii-id    present               -                     MAC         PHY
> +#   rgmii-id    -                     present               PHY         MAC
> +#   rgmii-id    present               present               MAC         MAC
> +#   rgmii-txid  -                     -                     PHY         PCB trace
> +#   rgmii-txid  present               -                     MAC         PCB trace
> +#   rgmii-rxid  -                     -                     PCB trace   PHY
> +#   rgmii-rxid  -                     present               PCB trace   MAC
We have some boards where the PCB traces result in part (1200ps) of
the delay needed for RGMII (2000ps).
The remainder (800ps) has to be added by either PHY or MAC: the
(RTL8211F) PHY can only generate 0 or 2000ps delay so the MAC has to
take over.
For the three boards I have in mind, please see $ git grep
rx-internal-delay-ps arch/arm64/boot/dts/amlogic/

> +# A property for a clock the PCB already delays is not in this table.
Can you please explain this sentence (I'm not a native English speaker)?
How I interpret the sentence: The PCB may add delays but those are
implicit and not part of the {rx,tx}-internal-delay-ps properties. If
the delays added by the PCB don't cover the full 2ns requirement then
either MAC or PHY need to add the remainder, see fine-tuning below.

> +# It is either the fine tuning described next, or a mistake the MAC
> +# should report as a fatal error.
How can I differentiate between "fine tuning" and "mistake"?


Best regards,
Martin



More information about the linux-amlogic mailing list