* Two questions about streaming DMA flushing
@ 2012-10-31 2:15 Li Haifeng
2012-10-31 7:50 ` Catalin Marinas
2012-10-31 9:08 ` Russell King - ARM Linux
0 siblings, 2 replies; 7+ messages in thread
From: Li Haifeng @ 2012-10-31 2:15 UTC (permalink / raw)
To: linux-arm-kernel
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?
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?
Regards,
Haifeng Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/fbdfd887/attachment-0001.html>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Two questions about streaming DMA flushing
2012-10-31 2:15 Two questions about streaming DMA flushing Li Haifeng
@ 2012-10-31 7:50 ` Catalin Marinas
2012-10-31 9:40 ` Li Haifeng
2012-10-31 9:08 ` Russell King - ARM Linux
1 sibling, 1 reply; 7+ messages in thread
From: Catalin Marinas @ 2012-10-31 7:50 UTC (permalink / raw)
To: linux-arm-kernel
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).
> 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).
--
Catalin
^ permalink raw reply [flat|nested] 7+ messages in thread
* Two questions about streaming DMA flushing
2012-10-31 2:15 Two questions about streaming DMA flushing Li Haifeng
2012-10-31 7:50 ` Catalin Marinas
@ 2012-10-31 9:08 ` Russell King - ARM Linux
2012-10-31 9:42 ` Li Haifeng
2012-10-31 10:09 ` Rajanikanth H.V
1 sibling, 2 replies; 7+ messages in thread
From: Russell King - ARM Linux @ 2012-10-31 9:08 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 31, 2012 at 10:15:04AM +0800, 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?
Wrong. beq is not a function call.
> 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?
Cache prefetching.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Two questions about streaming DMA flushing
2012-10-31 7:50 ` Catalin Marinas
@ 2012-10-31 9:40 ` Li Haifeng
2012-10-31 10:50 ` Catalin Marinas
0 siblings, 1 reply; 7+ messages in thread
From: Li Haifeng @ 2012-10-31 9:40 UTC (permalink / raw)
To: linux-arm-kernel
2012/10/31 Catalin Marinas <catalin.marinas@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Two questions about streaming DMA flushing
2012-10-31 9:08 ` Russell King - ARM Linux
@ 2012-10-31 9:42 ` Li Haifeng
2012-10-31 10:09 ` Rajanikanth H.V
1 sibling, 0 replies; 7+ messages in thread
From: Li Haifeng @ 2012-10-31 9:42 UTC (permalink / raw)
To: linux-arm-kernel
2012/10/31 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Wed, Oct 31, 2012 at 10:15:04AM +0800, 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?
>
> Wrong. beq is not a function call.
Yes, It's my wrong. sorry for my careless.
>
>> 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?
>
> Cache prefetching.
Thanks!
^ permalink raw reply [flat|nested] 7+ messages in thread
* Two questions about streaming DMA flushing
2012-10-31 9:08 ` Russell King - ARM Linux
2012-10-31 9:42 ` Li Haifeng
@ 2012-10-31 10:09 ` Rajanikanth H.V
1 sibling, 0 replies; 7+ messages in thread
From: Rajanikanth H.V @ 2012-10-31 10:09 UTC (permalink / raw)
To: linux-arm-kernel
> > 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?
>
> Cache prefetching.
>
Speculative prefetch?
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121031/4ea66442/attachment-0001.html>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Two questions about streaming DMA flushing
2012-10-31 9:40 ` Li Haifeng
@ 2012-10-31 10:50 ` Catalin Marinas
0 siblings, 0 replies; 7+ messages in thread
From: Catalin Marinas @ 2012-10-31 10:50 UTC (permalink / raw)
To: linux-arm-kernel
On 31 October 2012 09:40, Li Haifeng <omycle@gmail.com> wrote:
> 2012/10/31 Catalin Marinas <catalin.marinas@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?
Yes, that's exactly the point of DMA_FROM_DEVICE, the device is going
to write that buffer anyway.
--
Catalin
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-10-31 10:50 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-31 2:15 Two questions about streaming DMA flushing Li Haifeng
2012-10-31 7:50 ` Catalin Marinas
2012-10-31 9:40 ` Li Haifeng
2012-10-31 10:50 ` Catalin Marinas
2012-10-31 9:08 ` Russell King - ARM Linux
2012-10-31 9:42 ` Li Haifeng
2012-10-31 10:09 ` Rajanikanth H.V
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).