[U-Boot] [PATCH v2 2/2] net: fec_mxc: Do not error out when FEC_TBD_READY

[Marek Vasut <marex@denx.de>]

On Thursday, August 21, 2014 at 09:57:23 AM, Stefano Babic wrote:
> 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.

This implementation is not suitable, since the behavior of the "new" MX6SX IP 
core differs from the old cores. The old cores did set up the descriptor bit 
properly and this check is in place to trigger a resubmission of datagram if the 
TDAR and the DMA descriptor statuses were out of sync.

> >> 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.

This would be true only if TDAR and BD are in sync, otherwise this would 
introduce change in behavior. But I'm fine with this, it shouldn't be harmful 
either way.

> >> 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.

Yeah.

Best regards,
Marek Vasut