From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mark Huth <mhuth@mvista.com>
Cc: Dale Farnsworth <dale@farnsworth.org>,
Netdev <netdev@oss.sgi.com>, Jeff Garzik <jgarzik@pobox.com>,
Ralf Baechle <ralf@linux-mips.org>,
Manish Lachwani <mlachwani@mvista.com>,
Brian Waite <brian@waitefamily.us>,
"Steven J. Hill" <sjhill@realitydiluted.com>,
James Chapman <jchapman@katalix.com>
Subject: Re: mv643xx(2/20): use MII library for PHY management
Date: Wed, 24 Aug 2005 10:33:26 +1000 [thread overview]
Message-ID: <1124843606.5158.124.camel@gaston> (raw)
In-Reply-To: <430BC09A.3090401@mvista.com>
On Tue, 2005-08-23 at 17:34 -0700, Mark Huth wrote:
> It's good to use the abstractions and common code, but in this case
> there is a significant performance difference. The MDIO read/write on
> this family does a cpu spin wait for the mdio operation to complete.
> Last time I measured this (back when fixing up a 2.4.20 implementation)
> I got around 100 us for the mii_ioctl path, of which a good bit was in
> the spin loop waiting for the MDIO operation to complete. A quick look
> seems to indicate the spin loop is still in this version of the driver.
>
> Given that the NIC chip gives cheap access to the link status and a
> couple of other interesting bits, the change to use the mii library has
> a performance impact.
Is it possible to implement the mdio functions without a spin loop ?
Also, it might be a good idea to use the PHY driver model (a-la sungem)
rather than miilib...
Ben.
next prev parent reply other threads:[~2005-08-24 0:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-28 23:38 [PATCH: 2.6.12-rc1] mv643xx: ethernet driver updates Dale Farnsworth
2005-03-28 23:40 ` mv643xx(1/20): Add mv643xx_enet support for PPC Pegasos platform Dale Farnsworth
2005-03-28 23:42 ` mv643xx(2/20): use MII library for PHY management Dale Farnsworth
2005-08-24 0:34 ` Mark Huth
2005-08-24 0:33 ` Benjamin Herrenschmidt [this message]
2005-03-28 23:43 ` mv643xx(3/20): use MII library for ethtool functions Dale Farnsworth
2005-03-28 23:44 ` mv643xx(4/20): Update the Artesyn katana mv643xx ethernet platform data Dale Farnsworth
2005-03-28 23:45 ` mv643xx(5/20): update ppc7d platform for new mv643xx_eth " Dale Farnsworth
2005-03-28 23:46 ` mv643xx(6/20): use netif_msg_xxx() to control log messages where appropriate Dale Farnsworth
2005-03-28 23:47 ` mv643xx(7/20): move static prototypes from header file into driver C file Dale Farnsworth
2005-03-28 23:48 ` mv643xx(8/20): remove ETH_FUNC_RET_STATUS and unused ETH_TARGET enums Dale Farnsworth
2005-03-28 23:49 ` mv643xx(9/20): make internal functions take device pointer param consistently Dale Farnsworth
2005-03-28 23:49 ` mv643xx(10/20): compile fix for non-NAPI case Dale Farnsworth
2005-03-28 23:51 ` mv643xx(11/20): rename all functions to have a common mv643xx_eth prefix Dale Farnsworth
2005-03-28 23:55 ` mv643xx(12/20): reorder code to avoid prototype function declarations Dale Farnsworth
2005-03-28 23:55 ` mv643xx(13/20): remove useless function header block comments Dale Farnsworth
2005-03-28 23:56 ` mv643xx(14/20): whitespace and indentation cleanup Dale Farnsworth
2005-03-28 23:57 ` mv643xx(15/20): Add James Chapman to copyright statement and author list Dale Farnsworth
2005-03-28 23:57 ` mv643xx(16/20): Limit MTU to 1500 bytes unless connected at GigE speed Dale Farnsworth
2005-03-30 20:09 ` Jeff Garzik
2005-03-30 21:46 ` Dale Farnsworth
2005-03-28 23:58 ` mv643xx(17/20): Reset the PHY only at driver open time Dale Farnsworth
2005-03-28 23:59 ` mv643xx(18/20): Isolate the PHY at device close Dale Farnsworth
2005-03-29 0:00 ` mv643xx(19/20): Ensure NAPI poll routine only clears IRQs it handles Dale Farnsworth
2005-03-29 0:01 ` mv643xx(20/20): Fix promiscuous mode handling Dale Farnsworth
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=1124843606.5158.124.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=brian@waitefamily.us \
--cc=dale@farnsworth.org \
--cc=jchapman@katalix.com \
--cc=jgarzik@pobox.com \
--cc=mhuth@mvista.com \
--cc=mlachwani@mvista.com \
--cc=netdev@oss.sgi.com \
--cc=ralf@linux-mips.org \
--cc=sjhill@realitydiluted.com \
/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.