Mugunthan's address bounces. Removing it. Adding Grygorii's address instead.
On 14/07/2017 23:08, Mason wrote: > Hello, > > I've discussed this subject in the past, but we never reached > a conclusion, AFAIR. > > The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock delays. > > https://www.redeszone.net/app/uploads/2014/04/AR8035.pdf > > > 1) RX clock delay > > Commit 2e5f9f281ee8369f56d403b4a52942f19b6978f8 > > In fact, RX clock delay is *ENABLED* by default at > reset. So if a board actually required it *disabled* > then we actually need to set the bit to 0. > > Reference: > 4.2.25 rgmii rx clock delay control > > > 2) TX clock delay > > Commit 1ca6d1b1aef4628ff0fe458135ddb008d134ad8f > > TX clock delay is DISABLED by default, so no surprises > there... except that it is only DISABLED after *HW reset*. > > After a SW reset, such as that performed in Linux IIUC, > the PHY retains the value previously set. > > So if a bootloader such a Uboot enabled TX delay, then > Linux would "inherit" the setting, even if it performs > a reset. If the PHY setting calls for no TX clock delay, > the Linux driver would have to actively disable it. > > Reference: > 4.2.26 rgmii tx clock delay control > > > I can (of course) send a patch fixing both issues, but > what was said last time was that "it's too late to > fix it now, since the fix risks breaking working > setups". Is that an accurate paraphrase? > > > 3) There's also a RGMII GTX_CLK documented as > "RGMII transmit clock, 125 MHz digital. Adding a 22 ohm > damping resistor is recommended for EMI design near MAC side" > => Is that TX_CLK? > There's a 2-bit related field called Gtx_dly_val > which allows tweaking the delay > > Select the delay of gtx_clk. > 00: 0.25ns > 01: 1.3ns > 10: 2.4ns > 11: 3.4ns > (DEFAULT 10b = 2.4 ns, BUT Retain val on SW reset, > so inherit bootloader value) > I'm not sure the current DT allows such fine-grained > tweaking? Should we enhance it? > > > 4) There's the whole mess of having clock delays > supported both by the PHY *AND* the MAC. If both > add a delay, things won't work as expected. > What's the recommended approach there? > > > Regards.
