The assembler supports the following instructions related to flushing the cache:
FLUSH <CACHE(s)>
WRITEBACK <CACHE(s)>
INVALIDATE <CACHE(s)>
flush_invalidate_caches() – uses “FLUSH DM_CACHE & FLUSH PM_CACHE ” instruction.
This instruction ensures that the cache is cleared and any updated copy in the cache is not cleared without writing back to L2/L3 memory.
flush_no_invalidate_caches() – uses “WRITEBACK DM_CACHE & WRITEBACK PM_CACHE” instruction: This instruction ensures that all the modified data in cache is written back to L2/L3. But it will not clear the cache.
"INVALIDATE DM_CACHE & INVALIDATE PM_CACHE" instruction clears the cache unconditionally without writing back to L2/L3 memory.
flush_data_buffer api with ADI_FLUSH_DATA_INV, calls flush_invalidate_caches() which Invalidates *and* writes back the specified caches(s).
flush_data_buffer api with ADI_FLUSH_DATA_NOINV, calls flush_no_invalidate_caches() which Writes back the specified caches(s).
If your input data buffer resides in cacheable memory, then after modifying the buffer it should be flushed from memory using the flush_data_buffer API in the ADI_FLUSH_DATA_NOINV mode. This prevents the DMA transfer from accessing stale data.
If your results buffer resides in cacheable memory, then before triggering the RX DMA channel to permit transferring new results, the buffer should be flushed using the flush_data_buffer API in the ADI_FLUSH_DATA_NOINV mode. The data should then not be accessed until the RX DMA channel says the next set of results are ready. When the results are ready, the buffer should be invalidated by calling the flush_data_buffer API in the ADI_FLUSH_DATA_INV mode.