Two questions about streaming DMA flushing

[Li Haifeng]

2012/10/31 Catalin Marinas <catalin.marinas at arm.com>:
> On Wed, Oct 31, 2012 at 02:15:04AM +0000, Li Haifeng wrote:
>> Sorry to disturb you.
>>
>> I have two questions for streaming DMA flushing @ arch/arm/mm/cache-v7.S.
>>
>> 1.
>> 332 ENTRY(v7_dma_map_area)
>> 333         add     r1, r1, r0
>> 334         teq     r2, #DMA_FROM_DEVICE
>> 335         beq     v7_dma_inv_range
>> 336         b       v7_dma_clean_range
>> 337 ENDPROC(v7_dma_map_area)
>>
>> The function of v7_dma_map_area will invalidate corresponding cache line
>> firstly and then clean the cache for  DMA_FROM_DEVICE . I am confused the
>> sequence of the operations. IMO, the invalidate should be followed by the clean
>> action. Is it right?
>
> If the direction is DMA_FROM_DEVICE, it only invalidates the cache (beq
> instruction).

Sorry for my careless.

Why doesn't need clean for DMA_FROM_DEVICE? Will the data modified
before dma mapping be lost?

>
>> 2.
>> 345 ENTRY(v7_dma_unmap_area)
>> 346         add     r1, r1, r0
>> 347         teq     r2, #DMA_TO_DEVICE
>> 348         bne     v7_dma_inv_range
>> 349         mov     pc, lr
>> 350 ENDPROC(v7_dma_unmap_area)
>>
>> v7_dma_unmap_area, will invalidate corresponding cache line for
>> DMA_FROM_DEVICE . But, at v7_dma_map_area, the invalidate has been done. Why do
>> this again?
>
> There can be speculative loads into the cache, so once the transfer has
> finished you need to invalidate the range again to avoid reading stale
> data (the first invalidate is needed to make sure there aren't any dirty
> cache lines that could be evicted).
>

It is reasonable!

> --
> Catalin