[U-Boot] [PATCH v4] net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
When testing the FEC driver on a mx6solox we noticed that the TDAR bit gets always cleared prior then the READY bit is set in the last BD, which causes FEC transmission to fail.
As explained by Ye Li:
"The TDAR bit is set when the descriptors are all out from TX ring, but the descriptor properly is in transmitting not READY. These are two signals, and in Ic simulation, we found the TDAR always clear prior than the READY bit of last BD. In mx6solox, we use a latest version of FEC IP. It looks the intrinsic behave of TDAR bit is changed in this FEC version, not any bug in mx6sx."
Fix this by polling the READY bit of BD after the TDAR polling, which covers the mx6solox case and does not harm for the other SoCs.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- Changes since v3: - Place invalidate_dcache_range in the correct location Changes since v2: - Poll FEC_TBD_READY after polling TDAR
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- 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 4cefda4..675d53c 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -711,13 +711,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);
On Thursday, August 21, 2014 at 07:10:32 PM, Fabio Estevam wrote:
When testing the FEC driver on a mx6solox we noticed that the TDAR bit gets always cleared prior then the READY bit is set in the last BD, which causes FEC transmission to fail.
As explained by Ye Li:
"The TDAR bit is set when the descriptors are all out from TX ring, but the descriptor properly is in transmitting not READY.
Again, I do not understand this sentence :-(
These are two signals, and in Ic simulation, we found the TDAR always clear prior than the READY bit of last BD.
And this is the behavior of which version of the FEC IP, the "old" one or the one present in MX6slx ?
In mx6solox, we use a latest version of FEC IP. It looks the intrinsic behave of TDAR bit is changed in this FEC version, not any bug in mx6sx."
Fix this by polling the READY bit of BD after the TDAR polling, which covers the mx6solox case and does not harm for the other SoCs.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
[...]
Best regards, Marek Vasut
Hi Marek,
On 8/22/2014 1:18 AM, Marek Vasut wrote:
On Thursday, August 21, 2014 at 07:10:32 PM, Fabio Estevam wrote:
When testing the FEC driver on a mx6solox we noticed that the TDAR bit gets always cleared prior then the READY bit is set in the last BD, which causes FEC transmission to fail.
As explained by Ye Li:
"The TDAR bit is set when the descriptors are all out from TX ring, but the descriptor properly is in transmitting not READY.
Again, I do not understand this sentence :-(
When transmitting data, FEC internal DMA reads the TX descriptor and move the data from the buffer pointed by TX descriptor to FEC internal FIFO. All TX descriptors are managed in a ring. We found the TDAR is cleared at DMA starting last descriptor of the ring, not at DMA having last descriptor finished. So this bit clears earlier than the READY bit of last descriptor. The delay is the time for the data sending of last descriptor.
These are two signals, and in Ic simulation, we found the TDAR always clear prior than the READY bit of last BD.
And this is the behavior of which version of the FEC IP, the "old" one or the one present in MX6slx ?
This is the behavior of current FEC IP on mx6sx. For old ones, we did not do simulation for them, but it seems the TDAR clear at the last TX descriptor finished.
In mx6solox, we use a latest version of FEC IP. It looks the intrinsic behave of TDAR bit is changed in this FEC version, not any bug in mx6sx."
Fix this by polling the READY bit of BD after the TDAR polling, which covers the mx6solox case and does not harm for the other SoCs.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
[...]
Best regards, Marek Vasut
Best regards, Ye Li
On Friday, August 22, 2014 at 05:02:37 AM, Li Ye-B37916 wrote:
Hi Marek,
On 8/22/2014 1:18 AM, Marek Vasut wrote:
On Thursday, August 21, 2014 at 07:10:32 PM, Fabio Estevam wrote:
When testing the FEC driver on a mx6solox we noticed that the TDAR bit gets always cleared prior then the READY bit is set in the last BD, which causes FEC transmission to fail.
As explained by Ye Li:
"The TDAR bit is set when the descriptors are all out from TX ring, but the descriptor properly is in transmitting not READY.
Again, I do not understand this sentence :-(
When transmitting data, FEC internal DMA reads the TX descriptor and move the data from the buffer pointed by TX descriptor to FEC internal FIFO. All TX descriptors are managed in a ring. We found the TDAR is cleared at DMA starting last descriptor of the ring, not at DMA having last descriptor finished. So this bit clears earlier than the READY bit of last descriptor. The delay is the time for the data sending of last descriptor.
These are two signals, and in Ic simulation, we found the TDAR always clear prior than the READY bit of last BD.
And this is the behavior of which version of the FEC IP, the "old" one or the one present in MX6slx ?
This is the behavior of current FEC IP on mx6sx. For old ones, we did not do simulation for them, but it seems the TDAR clear at the last TX descriptor finished.
Thanks for clarification. Fabio, can you please document this with a big comment in the code ?
Best regards, Marek Vasut
Hi Marek,
On Fri, Aug 22, 2014 at 7:26 AM, Marek Vasut marex@denx.de wrote:
Thanks for clarification. Fabio, can you please document this with a big comment in the code ?
Yes, I can do that in v6.
Does the below version look good?
From 782be534aa37ba3da2f8d0ed607b26b2dd71c7d7 Mon Sep 17 00:00:00 2001
From: Fabio Estevam fabio.estevam@freescale.com Date: Fri, 22 Aug 2014 17:59:44 -0300 Subject: [PATCH v6 2/2] net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
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 v5: - Put explanation why we need to poll READY bit after TDAR into the code
drivers/net/fec_mxc.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 6afc827..bdd8108 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -719,13 +719,36 @@ 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) + /* + * The TDAR bit is cleared when the descriptors are all out from TX + * 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. + */ + 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);
participants (4)
-
Fabio Estevam -
Fabio Estevam -
Li Ye-B37916 -
Marek Vasut