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