[U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode"

[Kumar Gala]

On Nov 17, 2010, at 11:01 PM, Peter Tyser wrote:

> On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote:
>>> Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full
>>> duplex in SGMII mode"
>>> 
>>> Hi Zhao,
>>> 
>>>> In message <1289986984-2314-1-git-send-email-b26998 at freescale.com> you
>>> wrote:
>>>>> On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse
>>>>> VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS)
>>>>> for SGMII mode cause link problems.
>>>>> 
>>>>> Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it.
>>> 
>>> Based on my company's discussions with Freescale and Freescale's appnotes
>>> I believe that the current implementation is correct.  I make reference to
>>> some of this in the original patch:
>>> http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps-
>>> full-duplex-in-SGMII-mode-td26188785.html
>>> 
>>> We use Broadcom PHYs on our boards, which likely has something to do with
>>> the discrepancies between the P2020DS/MPC8572DS vs the
>>> XPedite5370/XPedite5500.  Unless you have additional information that
>>> shows that in-band SGMII auto-negotiation does work per the spec I'd
>>> prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS
>>> workarounds to the P2020DS (already done in commit
>>> 90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS.
>> 
>> 
>> Hi Peter,
>> 
>> From the App Note you mentioned, I didn't find that the auto-negotiation can't be used.
> 
> My understanding is that the SGMII link is always at 1000Mbps speed -
> see figure 1 from the app note.  Additionally look at figure 3.  My
> understand from it, and the app note's text is that SGMII
> auto-negotiation doesn't really occur - its just passing the PHY-side
> auto-negotiation results to the Freescale MAC, which software then
> configures.  I'm not sure what the purpose of the "SGMII
> auto-negotiation" is - its not really auto-negotiating and the same
> information can be read from the PHY via its MDIO interface, which is
> what is happening on X-ES boards currently.
> 
> We were told by a Freescale FAE that SGMII auto-negotiation wasn't
> supported, although 1000 BASE-X auto-negotation was (which mirrored our
> test results).  I can dig up the old emails tomorrow at the office with
> the details.
> 
>> Actually we need the auto-negotiation enabled for almost all Freescale reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards.  If we disable the auto-negotiation on these boards, the SGMII link won't work.  So I guess it might be more common to use auto-negotiation, and a fixed 1000M link is more like a special case.  I'm not sure what's the recommended way for SGMII PHY interconnect though.
> 
> And auto-negotation doesn't work on X-ES hardware which all use Broadcom
> PHYs - which is why I made the original change after consulting a
> Freescale FAE.  Its not a huge deal to me either way as long as the
> XPedite5370 and XPedite5500 continue to not use SGMII auto-negotiation.
> Can someone at Freescale provide a definitive answer about what the
> proper SGMII auto-negotiation scheme is?  And has anyone used it
> successfully or unsuccessfully with a non-Vitesse PHY?

So I believe we do in-band autoneg, it just doesn't convey all the way back as you'd expect.

We've also see Marvell PHYs work in SGMII mode.

I'm going to go back to the way it was and explicitly set CONFIG_TSEC_TBICR_SETTINGS in xpedite537x.h & xpedite550x.h

- k