From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 06 Feb 2009 08:32:14 -0500 Subject: [U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link In-Reply-To: <1233851271.6434.2066.camel@localhost.localdomain> References: <1233782045-488-1-git-send-email-ptyser@xes-inc.com> <2acbd3e40902041320l3bce93c1p989c4c33ca8e7ae@mail.gmail.com> <20090204212632.07F0D8322908@gemini.denx.de> <2acbd3e40902041507s2b02516cgb5e685e9843bb7eb@mail.gmail.com> <1233851271.6434.2066.camel@localhost.localdomain> Message-ID: <498C3BDE.3020102@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Peter Tyser wrote: > On Wed, 2009-02-04 at 17:07 -0600, Andy Fleming wrote: >> On Wed, Feb 4, 2009 at 3:26 PM, Wolfgang Denk wrote: >>> Dear Andy Fleming, >>> >>> In message <2acbd3e40902041320l3bce93c1p989c4c33ca8e7ae@mail.gmail.com> you 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. >>> Why that? Don't you always enable only the interface you are trying to >>> use? >> The problem is that you don't always know which interface you have >> hooked up. So u-boot tries the one set in ethact, and then the next, >> etc. With the old method, the penalty for being wrong was quite high. >> I hadn't run into an issue with the link not being up. Why don't we >> look up the spec, and find out the maximum time we'd have to wait for >> that to happen. That way we get the best of both worlds. My sense is >> that the link comes up fast, but autonegotiation potentially takes a >> while. 2 seconds minimum, it is written in the autonegotiation spec. If you add the spec-required minimum times for each step of the dance, it is 2 seconds. It could take longer, but I've never seen anything but 2 seconds. > My understanding was that link was was never achieved until > autonegotiation was finished. How could link be up before > autonegotiation was complete? > > With the original code I always saw 1 of 2 situations with a variety of > Broadcom PHYs: > 1. Autonegotiation completed and link was detected > 2. Autonegotiation was in process and link was not detected > > I never saw the case that the code referenced: > 3. Autonegotiation was in process and link was detected > > Do others see #3? > > Thanks, > Peter I never tried #3 personally, but my understanding of the link and autonegotiation dance is that #3 is not possible. You may see what appears to be #3 *if* your PHY is strapped to start autonegotiation on application of power (typically true) and *if* you don't do a software reset on the PHY as part of your power up sequence (see also my previous email on this thread). This really isn't #3, it is... 4. Strap the PHY to autonegotiate on application of power and use the results from that rather than resetting the PHY and re-starting auto-negotiation in software. Best regards, gvb