[U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.

From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.
Date: Mon, 23 Aug 2010 16:53:30 +0200	[thread overview]
Message-ID: <OF9972B1D8.BA625141-ONC1257788.0051B87D-C1257788.0051CDA2@transmode.se> (raw)
In-Reply-To: <AANLkTi=W-k6VNhw_7NJPh_tcVRjOv7NzeWsNtNH0VeEi@mail.gmail.com>

Ben Warren <biggerbadderben@gmail.com> wrote on 2010/08/23 16:12:07:
>
> Hi Jocke,
>
> On Monday, August 23, 2010, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > Ben Warren <biggerbadderben@gmail.com> wrote on 2010/08/23 09:08:17:
> >>
> >> ? Hi Detlev,
> >>
> >> On 8/13/2010 1:20 AM, Detlev Zundel wrote:
> >> > Hi Jocke,
> >> >
> >> >>>> Instead of always performing an autoneg, check if the PHY
> >> >>>> already has a link and if it matches one of the requested
> >> >>>> modes. Initially only 100MbFD is optimized this way.
> >> >>> Isn't it about time that we think about _not_ stopping the ethernet
> >> >>> device after every transaction?
> >> >> Hi Detlev
> >> >>
> >> >> UEC does this already, my patch was to address the initial delay
> >> >> you get for the first transaction. Now my PHY based boards gets the link
> >> >> up just as quick as Fixed PHY for the first transaction.
> >> > Forgive me to not look into this any deeper, but do I understand you
> >> > correctly that you do this by essentially no-oping the eth_halt()
> >> > function? ?Isn't this then effectively violating what net.c expects the
> >> > device to do?
> >> >
> >> > I was thinking that net.c itself should not do this continous start/stop
> >> > thing as it has problems on many interfaces. ?On one ARM machine I've
> >> > again seen problems with the MAC address programming because the
> >> > eth_halt() resets the controller and so it forgets its address again.
> >> > Also the USB-CDC example where the _whole interface_ on the host side is
> >> > being torn down after each tftp transfer prompts me to think along this
> >> > line.
> >> >
> >> > So in effect I guess my response was rather a ping to Ben, sorry for
> >> > that ;)
> >> >
> >> Sorry for the delay on this. ?I'm all for changing the existing
> >> behavior. ?It seems to me that the only time we would ever want to wind
> >> an interface down is if we switch the active one (even then, I'm not
> >> sure). ?My world view is limited, but I can't imagine that even changing
> >> interfaces happens much in real world U-boot usage, that is the non-lab,
> >> non-interactive use cases. ?What would you think about adding something
> >> like ifup and ifdown commands so that users could explicitly start/stop
> >> interfaces?
> >
> > Sure, bringing I/F's up and down needlessly isn't a good thing. However my
> > patch doesn't change that behaviour. It only optimizes the need for a PHY AN
> > the first time one performs a eth transaction.
> >
>
> I know.  I guess my e-mail was more directed towards Detlev's musings.

Ah, great. You will apply this patch then?

          Jocke