Re: change r2pro dts to public hw version (was "Board code with 2 dts" )

From: Trent Piepho <trent.piepho@igorinstitute.com>
To: Oleksij Rempel <linux@rempel-privat.de>
Cc: Frank Wunderlich <frank-w@public-files.de>,
	Ahmad Fatoum <a.fatoum@pengutronix.de>,
	barebox@lists.infradead.org
Subject: Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
Date: Sun, 10 Apr 2022 13:36:06 -0700	[thread overview]
Message-ID: <CAMHeXxP3OeqMFDL_Ry81X80vjKu-G8FDHtwrDJprKOmFc-pTEg@mail.gmail.com> (raw)
In-Reply-To: <6e8479f5-2081-b786-5c9f-298dac95984b@rempel-privat.de>

On Sun, Apr 10, 2022 at 8:00 AM Oleksij Rempel <linux@rempel-privat.de> wrote:
>
> The PHY id is hard coded, so we can find the datasheet:
> http://pdf.eepw.com.cn/i20090903/8d594ec98b62289dd0d3cd17fc8ffdd1.pdf
> Page 46:
> Ts3,
> - if TXPHASE_SEL=0, then clock is shifted by -0.65 ns
> - if TXPHASE_SEL=1, then clock is shifted by  1.35 ns

I do not think that is what they are saying.  Page 38,

TXPHASE_SEL  1: An intentional delay is added on GTX_CLK/ TXC (about
2ns delay in 1000BASE-T, and about 4ns delay in 100BASE-TX and
10BASE-T)

So they add 0 or 2 ns, which makes sense for internal delay added or not.

The table on page 46 is not clock shift, but the required setup time.
The sign is backward from how I would have expected it.  But if the
sign is inverted, then setup time + hold time is constant for both
values of clock delay, which is how it should be.  So when they say
-0.65 ns, what that means is TXD must be stable 0.65 ns before TXC
edge.  RGMII spec is that min setup time at receiver is 1.0 ns, but a
PHY can be better than the spec.  ~0.5 ns is typical.  If TXC is
delayed by 2 ns, then TXD can be stable 1.35 ns _after_ TCX edge and
this still meets the setup time of 0.65 ns.

> So, why mediatek,tx-delay-ps = <1530>? 1.5 is not enough for RGMII.
> In case of rgmii-rxid internal PHY clk skew will be -0.65 ns. Hard to say, if it is typo, but 1530 +
> 650ps will be 2180, which is enough for RGMII.

It doesn't make sense to me to add setup time to delay like that.  It
does produce a value that is the right range, but I think this is just
a coincidence.

>From PHY spec, we have 0.65 ns setup time and 0.2 ns hold time with 4
ns clock period (DDR), with 5% allowed variation (per RGMII).  So the
valid delay range is 0.65 ns to 3.6 ns.  But there are other factors
that reduce this range.  See calculation in section 3 here,
https://www.ti.com/lit/pdf/snla243

So maybe they did this and determined 1.53 ns delay will maximise
setup and hold margin.  Or maybe they copied that value from somewhere
and there is no good reason.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox