[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Ben Warren <biggerbadderben@gmail.com>]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>   
>> Dear Scott Wood,
>>
>> In message <498A0D5C.5060901@freescale.com> you wrote:
>>     
>>> Andy Fleming wrote:
>>>       
>>>> Hmmm....I made that change for a reason.  Waiting for autonegotiation
>>>> to finish on a tsec with no link was quite tiresome.  If you've hooked
>>>> up the 4th tsec, and try to boot, you end up waiting for *three* tsecs
>>>> to timeout.  If dhcp fails because the link isn't up you can always
>>>> try again, or add a delay before dhcp starts so that the link is up.
>>>>
>>>> I'm open to other suggestions, but I really don't want to go back to
>>>> the old behavior.
>>>>         
>>> Is there any way that you could do the auto-negotiation in parallel?
>>>       
>
> Excellent suggestion!
>
> Related suggestion: if we knew that the PHY was strapped to start 
> autonegotiation on power up (it is a board-specific option, typically 
> true), we could enhance the code to use those autonegotiation results 
> rather than hitting the PHY with the reset hammer and restarting 
> autonegotiation.  This would have an added advantage of "reducing" 
> network start up time by 2 seconds (assuming normal power up time is 
> more than 2 seconds) by overlapping the software initialization and PHY 
> autonegotiation.
>
>   
I think this is a good idea.  Serial autonegotiation is really such a 
time killer and has little to do with software, why not at least do a 
best effort attempt at letting all PHYs (or as many as the board 
developer feels like) autonegotiate as early in the process as possible?
>> You definitely do not want to do that.
>>
>> Requirement is NOT to initialize network interfaces unless used by
>> U-Boot.
>>     
>
> Autonegotiation is *not necessarily* a violation of this principle.  The 
> autonegotiation is in the PHY and is (should be) logically completely 
> separate from initializing the network interface (MAC).
>
> Just because the PHY is ready to run should have no impact on u-boot or 
> linux start up.  Case in point: most PHYs actually start their 
> autonegotiation when power is applied (it typically is a strapping option).
>
> Caveats:
> * I have not looked at the code, but the PHY initialization is probably 
> coupled in s/w with the MAC (ethernet chip) initialization.  This would 
> have to be changed to decouple the two.
>   
Currently, it depends greatly on the interface since each does its own 
thing.   I have some PHY-related development ongoing (phylib branch of 
the net tree) that leverages heavily from the Linux PHY drivers and some 
existing U-boot drivers that will let the user specify all sorts of 
things in board code.  I'd hoped to get it into the current release but 
that date's creeping up and  I'm low on time.  I hope to start RFCing it 
soon so in the following release we can migrate as many ethernet drivers 
as possible.  Anyway, with it we should be able to at least start AN via 
software in parallel, if desired of course.
> * Typically, PHYs have an interrupt output line.  I'm assuming here that 
> the interrupt is disabled.  If the interrupt is *enabled,* it *would* 
> violate u-boot's ground rule about not leaving hardware grenades laying 
> around.  The interrupt can be disabled in the PHY itself or at the CPU 
> end of the interrupt line.
>    1) It would be very unusual to have the interrupt enabled in u-boot.
>         I would be surprised if any PHY initialization enables the
>         interrupt (it is a control bit in a register in the PHY,
>         I forgot if it is a standard register or PHY-specific).
>    2) If a PHY interrupt causes a problem in linux, it is a driver bug
>         IMHO because it would mean the linux driver enabled the interrupt
>         before initializing the handler.  This would be a race condition
>         bug regardless of what u-boot does with the PHY and I trust none
>         of these are present in linux.  ;-/
>
>   
>> Best regards,
>>
>> Wolfgang Denk
>>     
>
> Ditto,
> gvb
>
> _________
Good discussion.

cheers,
Ben