From: Andy Fleming <afleming@gmail.com>
To: Bryan Wu <bryan.wu@canonical.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
Sascha Hauer <s.hauer@pengutronix.de>,
Greg Ungerer <gerg@uclinux.org>,
Amit Kucheria <amit.kucheria@canonical.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] netdev/fec: fix performance impact from mdio poll operation
Date: Fri, 7 May 2010 11:06:38 -0500 [thread overview]
Message-ID: <i2l2acbd3e41005070906me50416bapd8154a567406b886@mail.gmail.com> (raw)
In-Reply-To: <1273199239-11057-2-git-send-email-bryan.wu@canonical.com>
On Thursday, May 6, 2010, Bryan Wu <bryan.wu@canonical.com> wrote:
> BugLink: http://bugs.launchpad.net/bugs/546649
> BugLink: http://bugs.launchpad.net/bugs/457878
>
> After introducing phylib supporting, users experienced performace drop. That is
> because of the mdio polling operation of phylib. Use msleep to replace the busy
> waiting cpu_relax() and remove the warning message.
I'm a little confused by this patch. In order to improve performance,
you made the mdio functions fail silently? Why are you getting
timeouts at all? The Phy lib is not going to respond well if an mdio
write times out without returning an error. And returning an error
means the whole state machine has to reset, as a failed write is not
something we currently handle gracefully.
Is it possible to use an interrupt to get the phy state change? This
would allow the phy lib to stop its incessant polling. It doesn't
solve the question of why it's timing out, though.
>
> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
> Acked-by: Andy Whitcroft <apw@canonical.com>
> ---
> drivers/net/fec.c | 45 +++++++++++++++++++++------------------------
> 1 files changed, 21 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 2b1651a..9c58f6b 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -203,7 +203,7 @@ static void fec_stop(struct net_device *dev);
> #define FEC_MMFR_TA (2 << 16)
> #define FEC_MMFR_DATA(v) (v & 0xffff)
>
> -#define FEC_MII_TIMEOUT 10000
> +#define FEC_MII_TIMEOUT 10
>
> /* Transmitter timeout */
> #define TX_TIMEOUT (2 * HZ)
> @@ -611,13 +611,29 @@ spin_unlock:
> /*
> * NOTE: a MII transaction is during around 25 us, so polling it...
> */
> -static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
> +static int fec_enet_mdio_poll(struct fec_enet_private *fep)
> {
> - struct fec_enet_private *fep = bus->priv;
> int timeout = FEC_MII_TIMEOUT;
>
> fep->mii_timeout = 0;
>
> + /* wait for end of transfer */
> + while (!(readl(fep->hwp + FEC_IEVENT) & FEC_ENET_MII)) {
> + msleep(1);
> + if (timeout-- < 0) {
> + fep->mii_timeout = 1;
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
> +{
> + struct fec_enet_private *fep = bus->priv;
> +
> +
> /* clear MII end of transfer bit*/
> writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT);
>
> @@ -626,15 +642,7 @@ static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
> FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
> FEC_MMFR_TA, fep->hwp + FEC_MII_DATA);
>
> - /* wait for end of transfer */
> - while (!(readl(fep->hwp + FEC_IEVENT) & FEC_ENET_MII)) {
> - cpu_relax();
> - if (timeout-- < 0) {
> - fep->mii_timeout = 1;
> - printk(KERN_ERR "FEC: MDIO read timeout\n");
> - return -ETIMEDOUT;
> - }
> - }
> + fec_enet_mdio_poll(fep);
>
> /* return value */
> return FEC_MMFR_DATA(readl(fep->hwp + FEC_MII_DATA));
> @@ -644,9 +652,6 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
> u16 value)
> {
> struct fec_enet_private *fep = bus->priv;
> - int timeout = FEC_MII_TIMEOUT;
> -
> - fep->mii_timeout = 0;
>
> /* clear MII end of transfer bit*/
> writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT);
> @@ -657,15 +662,7 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
> FEC_MMFR_TA | FEC_MMFR_DATA(value),
> fep->hwp + FEC_MII_DATA);
>
> - /* wait for end of transfer */
> - while (!(readl(fep->hwp + FEC_IEVENT) & FEC_ENET_MII)) {
> - cpu_relax();
> - if (timeout-- < 0) {
> - fep->mii_timeout = 1;
> - printk(KERN_ERR "FEC: MDIO write timeout\n");
> - return -ETIMEDOUT;
> - }
> - }
> + fec_enet_mdio_poll(fep);
>
> return 0;
> }
> --
> 1.7.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2010-05-07 16:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 2:27 [PATCH 0/2] net-next/fec: bug fixing after introduced phylib supporting Bryan Wu
2010-05-07 2:27 ` [PATCH 1/2] netdev/fec: fix performance impact from mdio poll operation Bryan Wu
2010-05-07 16:06 ` Andy Fleming [this message]
2010-05-08 10:07 ` Bryan Wu
2010-05-08 15:25 ` Andy Fleming
2010-05-16 7:28 ` David Miller
2010-05-28 5:23 ` Bryan Wu
2010-05-07 2:27 ` [PATCH 2/2] netdev/fec: fix ifconfig eth0 down hang issue Bryan Wu
2010-05-28 5:26 ` Bryan Wu
2010-05-28 7:48 ` David Miller
2010-05-28 8:03 ` Bryan Wu
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=i2l2acbd3e41005070906me50416bapd8154a567406b886@mail.gmail.com \
--to=afleming@gmail.com \
--cc=amit.kucheria@canonical.com \
--cc=bryan.wu@canonical.com \
--cc=davem@davemloft.net \
--cc=gerg@uclinux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=s.hauer@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).