Re: [PATCH] ARM: mach-imx6q: add ksz9131rn_phy_fixup

[Philippe Schenker]

On Fri, 2020-03-06 at 12:14 +0100, Ahmad Fatoum wrote:
> Hello Philippe,
> 
> On 3/6/20 10:46 AM, Philippe Schenker wrote:
> > Hi Andrew and Ahmad, thanks for your comments. I totally forgot
> > about
> > those more specific phy-modes. But just because none of our driver
> > supports that. Either the i.MX6 fec-driver as well as the micrel.c
> > PHY
> > driver supports this tags.
> > What do you guys suggest then how I should implement that skew
> > stuff?
> 
> I think implementing them in the Micrel driver would make sense.
> When more specific skews are supplied, these are used.
> If not, the rgmii_[tx]?id applies the appropriate timings for length
> matched
> lines. Device trees matching your use case will then only have to
> specify
> rgmii-txid. 
> 
> > The problem is that i.MX6 has an asynchronic skew of -100 to 900ps
> > only
> > enabling the PHY-delay on TXC and RXC is not in all cases within the
> > RGMII timing specs. That's why I implemented this 'weird' numbers.
> 
> I am not too well-versed with this. What's an asynchronic skew?
> A non-deterministic internal delay..? So, you try to be as accurate as
> possible, so the skew is within the acceptable margin?

Asynchronic was a term I introduced because in RGMII spec, TXC of a MAC
should have -500 to 500ps skew. However the i.MX6 has "asynchronic" -100
to 900ps.

I did a worst-case study of those timing values. If I only enable the
2ns delay on the KSZ9131 PHY this is resulting in a T_setup_T of 1.9-
2.4ns (min-max). Under the assumption that tcyc (cycle time of the
clock) has min-max of 7.2-8.8ns this results in T_hold_T values of min-
max 0.7-2.5ns. The 0.7ns should be at least 1ns according to spec.

If I fine tune these values with the other registers I can "middle-out"
the clock-edges in relation to data signals and therefore I get all
values to be within RGMII timing specs.
> 
> Cheers
> Ahmad
> 
> 
> > Philippe
> >