Hi,
It looks like CP15DCacheFlushBuff cleans (i.e. forces dirty data to memory) the first one or two cache lines it is supposed to flush (i.e. invalidate the contents in the cache), judging by the fact that lines
MCRNE p15, #0, r14, c7, c14, #1 @ Clean and Flush D/U line to PoC
MCR p15, #0, r0, c7, c14, #1 @ Clean and Flush D/U line to PoC
are in both in CP15DCacheCleanFlushBuff and CP15DCacheFlushBuff. (And, it matches the info from ARM on http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Babhejba.html about clean and invalidate.)
CP15DCacheFlushBuff then moves on to only flushing cache lines:
MCR p15, #0, r0, c7, c6, #1 @ Flush D/U line to PoC
We discovered this when poisoning a small read buffer that the DMA later wrote to. When calling CacheDataInvalidateBuff, the poisoned data in the cache was cleaned (written to memory), overwriting what the DMA had just put there!
I'm not sure if it's done the way it is for when the data buffer to be cleaned is not aligned on a cache line boundary (which it is, but the code doesn't check). If that is the case, I assume the same situation can arise at the end of the buffer (if the last cache line is shared with other data).
It seems wasteful to always have to call CacheDataCleanBuff before setting up the DMA, just to make sure that a subsequent CacheDataInvalidateBuff doesn't accidentally do any cleaning. I'm hoping you have a better suggestion or explanation of the above.
Thanks,
Orjan