[U-Boot] i.MX51: FEC: Cache coherency problem?

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi David,

Le 19/07/2011 10:58, David Jander a ?crit :

>>> 587         flush_cache(&fec->tbd_base[fec->tbd_index], 4);
>>
>> This is what is needed assuming the below is initiating a memory to
>> peripheral DMA. Is your buffer only 4 bytes long?
>
> No it isn't. I know, I should flush the whole buffer area, but this was just
> enough to get the status field flushed, so the FEC started transmitting, and
> the while loop ended eventually. The result was still not correct, but at
> least it won't hang.

Seems like you're flushing while the DMA engine is running... That's 
calling for race conditions IMO. You should only have the DMA engine 
running while you are sending something or while you are expecting to 
receive something (U-Boot differs from an OS in that devices are not 
kept running unless actually needed).

> What would be more expensive, flushing just the buffer area, or
> flush_dcache_all()?

You should call the API for flushing the area only. Obviously, you'll 
flush either just as much, or possibly more (thus take longer) if you 
flush the whole data cache.

> Yes, I did. These two lines really is the minimum necessary to exit the while
> loop. It won't work if I leave out either of those.
> Now that I know a little more, I guess this is because of the status field in
> the buffer-descriptor being checked in the while loop, and that is still in
> cache. So the only thing line 589 does, is invalidate the caches, so the next
> readw() returns the value stored by the FEC, which is apparently faster than
> this piece of code :-)

One more reason not to let it run its DMA until you're ready. :)

> Best regards,

Amicalement,
-- 
Albert.