diff mbox

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

Message ID 20101117131429.9F55E14E646@gemini.denx.de
State Superseded
Delegated to: Kumar Gala
Headers show

Commit Message

Wolfgang Denk Nov. 17, 2010, 1:14 p.m. UTC 
Dear Zhao Chenhui,

In message <1289986984-2314-1-git-send-email-b26998@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.

This patch description is wrong, as you do not simply revert that
patch.  Instead, you modify  the code, shifting the setting from a
geric one into a XPEDITE5370 specific one.

When doing so, you should at least put the respective board maintainer
on CC.  I understand your patch was not even tested on the XPEDITE5370
board?


But actually I think your approach is wrong - Peter's solution looks
reasobanle to me.  When your boards with a specific PHY have problems,
then your boards should add appropriate CONFIG_TSEC_TBICR_SETTINGS to
their board config files.


If you insist in changing this code, you might as well clean it up a
bit, like that:





Best regards,

Wolfgang Denk

Comments

Peter Tyser Nov. 17, 2010, 3:49 p.m. UTC | #1 
Hi Zhao,

> In message <1289986984-2314-1-git-send-email-b26998@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.

Best,
Peter
Li Yang-R58472 Nov. 18, 2010, 4:13 a.m. UTC | #2 
>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@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.

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.

- Leo
Peter Tyser Nov. 18, 2010, 5:01 a.m. UTC | #3 
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@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?

Best,
Peter
Li Yang-R58472 Nov. 18, 2010, 6:50 a.m. UTC | #4 
>Subject: RE: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps
>fullduplex in SGMII mode"
>
>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@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-1000Mbp
>> >s- 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.

I guess the point is to save MDIO signals to the external PHY and read the
negotiated result from the internal TBI PHY.

>
>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?
>
>Best,
>Peter
Peter Tyser Nov. 18, 2010, 3:34 p.m. UTC | #5 
<snip>

> >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.
> 
> I guess the point is to save MDIO signals to the external PHY and read the
> negotiated result from the internal TBI PHY.

Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO
interface to their PHYs'?  I've never heard of a board that doesn't, and
would guess the tsec driver in U-Boot requires a PHY to be accessible
via MDIO to use the corresponding network interface.

I can forward you the email thread about SGMII auto-negotiation with
Freescale's FAE off-list if you'd like as well.

Best,
Peter
Yang Li Nov. 19, 2010, 5:53 a.m. UTC | #6 
><snip>
>
>> >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.
>>
>> I guess the point is to save MDIO signals to the external PHY and read
>> the negotiated result from the internal TBI PHY.
>
>Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO interface
>to their PHYs'?  I've never heard of a board that doesn't, and would guess
>the tsec driver in U-Boot requires a PHY to be accessible via MDIO to use
>the corresponding network interface.

I'm not sure which specific silicon omits the MDIO signal.  But quoting from
the app note you mentioned:

" Depending on the PowerQUICC part used, some eTSEC’s may or may not
provide an external
MDIO management interface. However, the TBI block for each eTSEC is
associated in a one to one
manner, even if that eTSEC does not have an external MDIO connection."

The auto-negotiation mechanism between TBI PHY and real PHY does make
it possible
to save external MDIO signals if only SGMII interface is used.

>
>I can forward you the email thread about SGMII auto-negotiation with
>Freescale's FAE off-list if you'd like as well.

Yes, please.  Thanks

- Leo
Peter Tyser Nov. 20, 2010, 12:01 a.m. UTC | #7 
On Fri, 2010-11-19 at 13:53 +0800, Li Yang wrote:
> ><snip>
> >
> >> >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.
> >>
> >> I guess the point is to save MDIO signals to the external PHY and read
> >> the negotiated result from the internal TBI PHY.
> >
> >Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO interface
> >to their PHYs'?  I've never heard of a board that doesn't, and would guess
> >the tsec driver in U-Boot requires a PHY to be accessible via MDIO to use
> >the corresponding network interface.
> 
> I'm not sure which specific silicon omits the MDIO signal.  But quoting from
> the app note you mentioned:
> 
> " Depending on the PowerQUICC part used, some eTSEC’s may or may not
> provide an external
> MDIO management interface. However, the TBI block for each eTSEC is
> associated in a one to one
> manner, even if that eTSEC does not have an external MDIO connection."

I believe some parts don't have an external MDIO interface for every
eTSEC.  if my memory is correct the MPC8572 only has 2 MDIO ports and 3
eTSECS.  But 1 MDIO port can be used to communicate with all 3 eTSECS'
PHYs assuming each PHY has a unique address.  (eg eTSEC1, 2, and 3 use
eTSEC1's MDIO port).

> The auto-negotiation mechanism between TBI PHY and real PHY does make
> it possible
> to save external MDIO signals if only SGMII interface is used.

That seems like an awfully big sacrifice to save routing 2 signals.
I've never heard of anyone doing this.  I don't think the current tsec
driver in U-Boot would support this configuration either, so I'm not
sure how much weight it holds.

> >I can forward you the email thread about SGMII auto-negotiation with
> >Freescale's FAE off-list if you'd like as well.
> 
> Yes, please.  Thanks

I just forwarded it.

Best,
Peter
Kumar Gala Dec. 2, 2010, 4:52 a.m. UTC | #8 
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@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
diff mbox

Patch

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 9b5dd92..c205a7e 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -292,13 +292,11 @@  static uint tsec_local_mdio_read(volatile tsec_mdio_t *phyregs,
 
 /* By default force the TBI PHY into 1000Mbps full duplex when in SGMII mode */
 #ifndef CONFIG_TSEC_TBICR_SETTINGS
-#define TBICR_SETTINGS ( \
+#define CONFIG_TSEC_TBICR_SETTINGS ( \
 		TBICR_PHY_RESET \
 		| TBICR_FULL_DUPLEX \
 		| TBICR_SPEED1_SET \
 		)
-#else
-#define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS
 #endif /* CONFIG_TSEC_TBICR_SETTINGS */
 
 /* Configure the TBI for SGMII operation */
@@ -311,7 +309,7 @@  static void tsec_configure_serdes(struct tsec_private *priv)
 	tsec_local_mdio_write(priv->phyregs_sgmii, priv->regs->tbipa, TBI_TBICON,
 			TBICON_CLK_SELECT);
 	tsec_local_mdio_write(priv->phyregs_sgmii, priv->regs->tbipa, TBI_CR,
-			TBICR_SETTINGS);
+			CONFIG_TSEC_TBICR_SETTINGS);
 }
 
 /* Discover which PHY is attached to the device, and configure it