All of lore.kernel.org
 help / color / mirror / Atom feed
From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.
Date: Fri, 13 Aug 2010 10:20:46 +0200	[thread overview]
Message-ID: <m2sk2ix6sh.fsf@ohwell.denx.de> (raw)
In-Reply-To: <OF3F4FFCED.34AF9611-ONC125777D.004D8284-C125777D.004DBBCE@transmode.se> (Joakim Tjernlund's message of "Thu, 12 Aug 2010 16:09:03 +0200")

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 ;)

Cheers
  Detlev

-- 
Peace of mind isn't at all superficial to technical work.  It's the
whole thing.   That which  produces it is good work  and that which
destroys it is bad work.
                                        -- Robert M. Pirsig
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

  reply	other threads:[~2010-08-13  8:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-10 14:36 [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg Joakim Tjernlund
2010-08-10 20:23 ` Mike Frysinger
2010-08-11  6:20   ` Joakim Tjernlund
2010-08-12 12:58 ` Detlev Zundel
2010-08-12 14:09   ` Joakim Tjernlund
2010-08-13  8:20     ` Detlev Zundel [this message]
2010-08-13 13:18       ` Joakim Tjernlund
2010-08-23  7:08       ` Ben Warren
2010-08-23  7:53         ` Joakim Tjernlund
2010-08-23 14:12           ` Ben Warren
2010-08-23 14:53             ` Joakim Tjernlund
2010-08-23 15:19         ` [U-Boot] Start/stop of network devices (was: Re: [PATCH] UEC PHY: Speed up initial PHY neg.) Detlev Zundel
2010-08-24 18:35           ` Joakim Tjernlund
2010-09-13  4:18 ` [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg Ben Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2sk2ix6sh.fsf@ohwell.denx.de \
    --to=dzu@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.