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

[Joakim Tjernlund]

Ben Warren <biggerbadderben at gmail.com> wrote on 2010/08/23 16:12:07:
>
> Hi Jocke,
>
> On Monday, August 23, 2010, Joakim Tjernlund
> <joakim.tjernlund at transmode.se> wrote:
> > Ben Warren <biggerbadderben at 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