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

[Ben Warren]

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.
>       Jocke

Regards,
Ben