From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/2] net: fec_mxc: Do not error out when FEC_TBD_READY
Date: Thu, 21 Aug 2014 09:57:23 +0200 [thread overview]
Message-ID: <53F5A663.3030704@denx.de> (raw)
In-Reply-To: <201408210702.29047.marex@denx.de>
Hi,
On 21/08/2014 07:02, Marek Vasut wrote:
> On Thursday, August 21, 2014 at 06:11:16 AM, Ye Li wrote:
>> The TDAR bit is set when the descriptors are all out from TX ring, but the
>> descriptor properly is in transmitting not READY.
>
> I don't quite understand this, can you please rephrase ?
>
>> 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.
>
> OK, so this behavior is isolated to MX6SX and newer. Then any adjustment should
> focus solely on MX6SX and newer.
Not really. It looks like that the implementation is suitable for
current FEC IP, but this does not mean that is correct at all. A
solution working for all FEC IP versions is surely preferable.
>
>> There are some solutions for this problem. Which would be acceptable?
>> 1. Change the TDAR polling to checking the READY bit in BD.
>
> This would return the cache-grinding, so this is not nice.
>
Agree.
>> 2. Add polling the READY bit of BD after the TDAR polling.
>
> If this would be isolated to MX6SX only, then that is doable.
>
Why not ? On current FEC IP (not MX6SX), this costs only one read of the
BD register. Only by MX6SX is polled again. This looks to me the best
solution.
>> 3. Add a delay after the TDAR polling.
>
> This is just work.
Of course, but it is a trick and we have to add some magical number of
uSec, explaining that with "so it works". My preference goes to 2.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
next prev parent reply other threads:[~2014-08-21 7:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-20 21:24 [U-Boot] [PATCH v2 1/2] net: fec_mxc: Adjust RX DMA alignment for mx6solox Fabio Estevam
2014-08-20 21:24 ` [U-Boot] [PATCH v2 2/2] net: fec_mxc: Do not error out when FEC_TBD_READY Fabio Estevam
2014-08-20 21:34 ` Otavio Salvador
2014-08-21 3:47 ` Marek Vasut
2014-08-21 3:53 ` Marek Vasut
2014-08-21 4:11 ` Ye Li
2014-08-21 5:02 ` Marek Vasut
2014-08-21 7:57 ` Stefano Babic [this message]
2014-08-21 8:35 ` Li Ye-B37916
2014-08-21 11:39 ` Marek Vasut
2014-08-21 3:44 ` [U-Boot] [PATCH v2 1/2] net: fec_mxc: Adjust RX DMA alignment for mx6solox Li Ye-B37916
2014-08-21 3:51 ` Marek Vasut
2014-08-21 6:03 ` Stefan Roese
2014-08-21 12:08 ` Fabio Estevam
2014-08-21 8:01 ` Stefano Babic
2014-08-21 11:55 ` Fabio Estevam
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=53F5A663.3030704@denx.de \
--to=sbabic@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox