On 8/21/2014 3:57 PM, 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 ?
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. 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.
Agree that the solution should cover all FEC IP versions. Thus, to wait all BD
sent by FEC, we must check not only the TDAR but also the READY bit in last BD.
>>> 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.
The delay time is relevant with the data length and transmit frequency, this
is the difficulty. A long delay decreases the performance.
>
> Best regards,
> Stefano Babic
>
Best regards,
Ye Li
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
