public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Fabio Estevam <festevam@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v5 2/2] net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
Date: Fri, 22 Aug 2014 16:40:39 -0300	[thread overview]
Message-ID: <1408736439-3780-2-git-send-email-festevam@gmail.com> (raw)
In-Reply-To: <1408736439-3780-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam@freescale.com>

When testing the FEC driver on a mx6solox we noticed that the TDAR bit gets
always cleared prior then the READY bit is cleared in the last BD, which causes
FEC packets reception to always fail.

As explained by Ye Li:

"The TDAR bit is cleared when the descriptors are all out from TX ring, but on 
mx6solox we noticed that the READY bit is still not cleared right after TDAR. 
These are two distinct signals, and in IC simulation, we found that TDAR always
gets cleared prior than the READY bit of last BD becomes cleared. 
In mx6solox, we use a later version of FEC IP. It looks like that this 
intrinsic behaviour of TDAR bit has changed in this newer FEC version."

Fix this by polling the READY bit of BD after the TDAR polling, which covers the
mx6solox case and does not harm the other SoCs.

No performance drop has been noticed with this patch applied when testing TFTP
transfers on several boards of different i.mx SoCs.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v4:
- Improve wording in the commit log.

 drivers/net/fec_mxc.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 56178d4..4bfd625 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -719,13 +719,22 @@ static int fec_send(struct eth_device *dev, void *packet, int length)
 			break;
 	}
 
-	if (!timeout)
+	if (!timeout) {
 		ret = -EINVAL;
+		goto out;
+	}
 
-	invalidate_dcache_range(addr, addr + size);
-	if (readw(&fec->tbd_base[fec->tbd_index].status) & FEC_TBD_READY)
+	timeout = FEC_XFER_TIMEOUT;
+	while (--timeout) {
+		invalidate_dcache_range(addr, addr + size);
+		if (!(readw(&fec->tbd_base[fec->tbd_index].status) & FEC_TBD_READY))
+			break;
+	}
+
+	if (!timeout)
 		ret = -EINVAL;
 
+out:
 	debug("fec_send: status 0x%x index %d ret %i\n",
 			readw(&fec->tbd_base[fec->tbd_index].status),
 			fec->tbd_index, ret);
-- 
1.9.1

  reply	other threads:[~2014-08-22 19:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-22 19:40 [U-Boot] [PATCH v5 1/2] net: fec_mxc: Adjust RX DMA alignment for mx6solox Fabio Estevam
2014-08-22 19:40 ` Fabio Estevam [this message]
2014-08-23  6:10 ` Stefan Roese

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=1408736439-3780-2-git-send-email-festevam@gmail.com \
    --to=festevam@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox