On Thu, Jul 24, 2014 at 8:05 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> I have spent some times look at other architectures and below is what >> I found. Please correct me if I am wrong, especially >> for_device():DMA_FROM_DEVICE. >> >> _for_cpu(): >> case DMA_BIDIRECTIONAL: >> case DMA_FROM_DEVICE: >> /* invalidate cache */ >> break; >> case DMA_TO_DEVICE: >> /* do nothing */ >> break; > > This seems fine: for a FROM_DEVICE mapping, we have flushed all > dirty entries during the _for_device or the map operation, > so if any clean entries are around, they need to be invalidated > in order to read the data from the device. > > for TO_DEVICE, we don't care about the cache, because we are > going to overwrite the data, and we don't need to do anything. Okay. > >> ------------------------- >> _for_device(): >> case DMA_BIDIRECTIONAL: >> case DMA_TO_DEVICE: >> /* flush and invalidate cache */ >> break; >> case DMA_FROM_DEVICE: >> /* should we invalidate cache or do nothing? */ >> break; > > You actually don't need to invalidate the TO_DEVICE mappings > in both _for_device and _for_cpu. You have to flush them > in for_device, and you have to invalidate them at least once, > but don't need to invalidate them again in for_cpu if you have > done that already in for_device and your CPU does not do any > speculative prefetches that might populate the dcache. Nios2 processor doesn't have flush-cache-only instruction. Its flush instruction will do 2 operations, flush and invalidate cache. > In case of for_device FROM_DEVICE, you have to invalidate or > flush the caches to ensure that no dirty cache lines are > written to memory, but only if your CPU has a write-back > cache rather than write-through. Nios2 has a write-back cache. So, will do invalidate cache here. > For bidirectional mappings, you may have to flush and invalidate. To confirm, do you mean bidirectional for both for_device and for_cpu? Thanks. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
