On Mon, Oct 09, 2023 at 11:29:12AM +0100, Robin Murphy wrote:
It looks a bit odd that this ends up applying to all of Coldfire, while the associated cache flush only applies to the M532x platform, which implies that we'd now be relying on the non-coherent allocation actually being coherent on other Coldfire platforms. Would it work to do something like this to make sure dma-direct does the right thing on such platforms (which presumably don't have caches?), and then reduce the scope of this FEC hack accordingly, to clean things up even better?
Probably. Actually Greg comment something along the lines last time, and mentioned something about just instruction vs instruction and data cache.
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index b826e9c677b2..1851fa3fe077 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -27,6 +27,7 @@ config COLDFIRE select CPU_HAS_NO_BITFIELDS select CPU_HAS_NO_CAS select CPU_HAS_NO_MULDIV64 + select DMA_DEFAULT_COHERENT if !MMU && !M523x
Although it would probably make more sense to simply not select CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE and CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU for these platforms and not build the non-coherent code at all. This should also include all coldfire platforms with mmu (M54xx/M548x/M5441x). Then again for many of the coldfire platforms the Kconfig allows to select CACHE_WRITETHRU/CACHE_COPYBACK which looks related. Greg, any chance you could help out with the caching modes on coldfire and legacy m68knommu?
