[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54ca7197-780a-68b1-0cf2-88ccc7ce4201@free.fr>
Date: Mon, 24 Jul 2017 23:21:50 +0200
From: Mason <slash.tmp@...e.fr>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Mans Rullgard <mans@...sr.com>,
Marc Gonzalez <marc_gonzalez@...madesigns.com>,
Andrew Lunn <andrew@...n.ch>,
Martin Blumenstingl <martin.blumenstingl@...il.com>,
Grygorii Strashko <grygorii.strashko@...com>,
Fabio Estevam <fabio.estevam@....com>,
Zefir Kurtisi <zefir.kurtisi@...atec.com>,
Timur Tabi <timur@...eaurora.org>,
Daniel Mack <zonque@...il.com>,
netdev <netdev@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"David S. Miller" <davem@...emloft.net>,
Thibaud Cornic <thibaud_cornic@...madesigns.com>
Subject: Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup
On 20/07/2017 14:33, Mason wrote:
> As [Florian] pointed out, the spec states that the
> "Data to Clock input Skew (at Receiver)"
> must be within [ 1.0, 2.6 ] ns.
>
> I understand that 2 ns is 1/4 of a 125 MHz period,
> but it's not clear to me why the above interval is
> centered at 1.8 instead of 2.0 ns.
>
> Also, the AR8035 PHY offers 4 possible TX clock delays:
> { 0.25, 1.3, 2.4, 3.4 } according to their doc.
> The two extremes are outside the interval, when would
> they be useful? In case the transmitter adds "bad" skew?
>
> Why doesn't the PHY support 1.8/2.0? Is it perhaps
> unable to, because of PLL limitations?
I haven't yet found answers for these questions.
- Why is the interval centered at 1.8 instead of 2.0 ns?
- What use are 0.25 ns and 3.4 ns skew?
- Why doesn't the PHY support a "recommended" value like 1.8 ns?
Does anyone have pointers to good resources?
Regards.
Powered by blists - more mailing lists