mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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


  reply	other threads:[~2022-04-10 20:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 17:23 Board code with 2 dts Frank Wunderlich
2022-03-22 17:34 ` Ahmad Fatoum
2022-03-23  7:47   ` Aw: " Frank Wunderlich
2022-03-23  8:03     ` Ahmad Fatoum
2022-04-08 11:03       ` change r2pro dts to public hw version (was "Board code with 2 dts" ) Frank Wunderlich
2022-04-08 17:00         ` Oleksij Rempel
2022-04-08 17:19           ` Frank Wunderlich
2022-04-09  8:04             ` Oleksij Rempel
2022-04-09  8:35               ` Aw: " Frank Wunderlich
2022-04-09 16:01                 ` Oleksij Rempel
2022-04-09 17:08                   ` Trent Piepho
2022-04-10  7:41                     ` Oleksij Rempel
2022-04-10  8:28                       ` Frank Wunderlich
2022-04-10  9:28                       ` Trent Piepho
2022-04-10 15:00                         ` Oleksij Rempel
2022-04-10 20:36                           ` Trent Piepho [this message]
2022-04-11  9:00                             ` Aw: " Frank Wunderlich

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=CAMHeXxP3OeqMFDL_Ry81X80vjKu-G8FDHtwrDJprKOmFc-pTEg@mail.gmail.com \
    --to=trent.piepho@igorinstitute.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=frank-w@public-files.de \
    --cc=linux@rempel-privat.de \
    /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