On Sat, Dec 15, 2018 at 12:14:29AM +1000, Greg Ungerer wrote:
Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work by virtue of the SoC only having an instruction cache (the older V2 cores).
Is there a good an easy case to detect if a core has a cache? Either runtime or in Kconfig?
The MMU case is fixable, but I think it will mean changing away from the fall-back virtual:physical 1:1 mapping it uses for the kernel address space. So not completely trivial. Either that or a dedicated area of RAM for coherent allocations that we can mark as non-cachable via the really course grained and limited ACR registers - not really very appealing.
What about CF_PAGE_NOCACHE? Reading arch/m68k/include/asm/mcf_pgtable.h suggest this would cause an uncached mapping, in which case something like this should work: http://git.infradead.org/users/hch/misc.git/commitdiff/4b8711d436e8d56edbc5ca19aa2be639705bbfef
The noMMU case in general is probably limited to something like that same type of dedicated RAM/ACR register mechamism. The most commonly used periperal with DMA is the FEC ethernet module, and it has some "special" (used very loosely) cache flushing for parts like the 532x family which probably makes it mostly work right. There is a PCI bus on the 54xx family of parts, and I know general ethernet cards on it (like e1000's) have problems I am sure are related to the fact that coherent memory allocations aren't.
If we really just care about FEC we can just switch it do use DMA_ATTR_NON_CONSISTENT and do explicit cache flushing. But as far as I can tell FEC only uses DMA coherent allocations for the TSO headers anyway, is TSO even used on this SOC?
