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

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

Le 21/07/2011 08:48, David Jander a ?crit :

>> However, it is still correct that copying from an non-cached area is
>> slower than from cached areas, because of burst reads vs. individual
>> reads. However, I doubt that the u-boot user can tell the difference, as
>> the network latency will far exceed the difference in copy time.

That's assuming cache is only for networking. There can be DMA engines 
in a lot of other peripherals which do not have the same latency as 
network (and then, even for networking, TFTP can be done from a very 
nearby server, possibly even on the same Ethernet segment).

>> The
>> question is, which is easier to do, and that is probably a matter of
>> opinion. However, it is safe to say that so far a cached solution has
>> eluded us. That may be changing, but it would still be nice to know how
>> to allocate a section of un-cached RAM in the ARM processor, in so far
>> as the question has a single answer! That would allow easy portability
>> of drivers that do not know about caches, of which there seems to be many.

That is one approach, which I think prevents cache from being used 
beyond caching pure CPU-used DRAM.

> I agree. Unfortunately, my time is up for now, and I can't go on with trying
> to fix this driver. Maybe I'll pick up after my vacation.
> As for now I settled for the ugly solution of keeping dcache disabled while
> ethernet is being used :-(

Make sure you flush before disabling. :)

> IMHO, doing cache maintenance all over the driver is not an easy or nice
> solution. Implementing a non-cached memory pool in the MMU and a corresponding
> dma_malloc() sounds like much more universally applicable to any driver.

I think cache maintenance is feasible if one makes sure the cached areas 
used by the driver are properly aligned, which simplifies things a lot: 
you don't have to care for flush-invalidate or just-in-time invalidate, 
you just have to flush before sending and invalidate before reading.

> Best regards,

Amicalement,
-- 
Albert.