[PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup
Florian Fainelli
f.fainelli at gmail.com
Mon Jul 24 14:49:22 PDT 2017
On 07/24/2017 02:21 PM, Mason wrote:
> 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?
Presumably because this is almost the middle of the available range and
it still provides a value that is within the specification...
> - What use are 0.25 ns and 3.4 ns skew?
Accounting for extreme PCB traces lengths possibly, or just exposing the
raw values that the HW supports by increments of 0.25 ns, just because
the HW supports it.
> - Why doesn't the PHY support a "recommended" value like 1.8 ns?
>
> Does anyone have pointers to good resources?
The PHY datasheet and the RGMII specification really ought to be the
starting points, there is not much more to it. Maybe go ask your support
person at Qualcomm/Atheros about their PHY design?
--
Florian
More information about the linux-arm-kernel
mailing list