mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
To: Alexey Charkov <alchark@gmail.com>
Cc: Chaoyi Chen <kernel@airkyi.com>, Andrew Lunn <andrew@lunn.ch>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Quentin Schulz <quentin.schulz@cherry.de>,
	Kever Yang <kever.yang@rock-chips.com>,
	Jonas Karlman <jonas@kwiboo.se>, John Clark <inindev@gmail.com>,
	FUKAUMI Naoki <naoki@radxa.com>,
	Jimmy Hon <honyuenkwun@gmail.com>,
	Dragan Simic <dsimic@manjaro.org>,
	Michael Riesch <michael.riesch@collabora.com>,
	Peter Robinson <pbrobinson@gmail.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	Andy Yan <andy.yan@rock-chips.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board
Date: Thu, 8 Jan 2026 17:02:52 +0800	[thread overview]
Message-ID: <779a407c-0464-4d46-b73d-ad61834f1fcf@rock-chips.com> (raw)
In-Reply-To: <CABjd4YyMj=1pQBwqo9suu0W_HD=MG=zb5wo9dheguMBxi+oNqA@mail.gmail.com>

On 1/8/2026 4:49 PM, Alexey Charkov wrote:
> On Thu, Jan 8, 2026 at 12:38 PM Chaoyi Chen <chaoyi.chen@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@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@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@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.
> 

Ah, got it. Thank you for the clarification :)

-- 
Best, 
Chaoyi

  reply	other threads:[~2026-01-08  9:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-07  7:03 [PATCH v2 0/2] " Chaoyi Chen
2026-01-07  7:03 ` [PATCH v2 1/2] dt-bindings: arm: " Chaoyi Chen
2026-01-07  7:03 ` [PATCH v2 2/2] arm64: dts: " Chaoyi Chen
2026-01-07  7:56   ` Alexey Charkov
2026-01-07  8:21     ` Heiko Stübner
2026-01-07  9:57       ` Chaoyi Chen
2026-01-07 10:04         ` Chaoyi Chen
2026-01-07 14:54           ` Heiko Stübner
2026-01-07 14:56             ` Heiko Stübner
2026-01-07  9:50     ` Chaoyi Chen
2026-01-07 15:46   ` Quentin Schulz
2026-01-08  6:27     ` Chaoyi Chen
2026-01-08 10:07       ` Quentin Schulz
2026-01-08 10:41         ` Chaoyi Chen
2026-01-08 10:51           ` Quentin Schulz
2026-01-07 18:17   ` Andrew Lunn
2026-01-08  6:53     ` Alexey Charkov
2026-01-08  7:42       ` Chaoyi Chen
2026-01-08  8:01         ` Chaoyi Chen
2026-01-08  8:11           ` Alexey Charkov
2026-01-08  8:38             ` Chaoyi Chen
2026-01-08  8:49               ` Alexey Charkov
2026-01-08  9:02                 ` Chaoyi Chen [this message]
2026-01-08 13:53           ` Andrew Lunn
2026-01-08  6:50   ` Andy Yan
2026-01-08  8:04     ` [PATCH " Chaoyi Chen

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=779a407c-0464-4d46-b73d-ad61834f1fcf@rock-chips.com \
    --to=chaoyi.chen@rock-chips.com \
    --cc=alchark@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=andy.yan@rock-chips.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dsimic@manjaro.org \
    --cc=heiko@sntech.de \
    --cc=honyuenkwun@gmail.com \
    --cc=inindev@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=kernel@airkyi.com \
    --cc=kever.yang@rock-chips.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=michael.riesch@collabora.com \
    --cc=naoki@radxa.com \
    --cc=pbrobinson@gmail.com \
    --cc=quentin.schulz@cherry.de \
    --cc=robh@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=shawn.lin@rock-chips.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®