Thread (43 messages) 43 messages, 5 authors, 2013-10-25

[PATCH v8 13/19] swiotlb-xen: use xen_dma_map/unmap_page, xen_dma_sync_single_for_cpu/device

From: Stefano Stabellini <hidden>
Date: 2013-10-24 11:00:40
Also in: lkml, xen-devel

On Wed, 23 Oct 2013, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 23, 2013 at 06:20:25PM +0100, Stefano Stabellini wrote:
quoted
On Wed, 23 Oct 2013, Konrad Rzeszutek Wilk wrote:
quoted
On Thu, Oct 17, 2013 at 06:43:28PM +0100, Stefano Stabellini wrote:
quoted
Call xen_dma_map_page, xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
xen_dma_sync_single_for_device from swiotlb-xen to ensure cpu/device
coherency of the pages used for DMA, including the ones belonging to the
swiotlb buffer.
You lost me.

Isn't it the driver's responsibility to do this?

Looking at what 'xen_dma_map_page()' does for x86 it looks to add an extra
call - page_to_phys - and we ignore it here.
map_page on arm calls the right cache flushes needed to communicate with
the device. Same with unmap_page.
If this is flushing the cache then I think it makes more sense to do
that without this fancy 'dma_map_page'.

Just call it 'xen_flush_dma_page' and make it a nop on all platforms
except ARM.
I am OK with making it a nop on x86, it makes sense.
However I would like to keep it called xen_dma_map_page: after all it
corresponds exactly to the native map_page dma_op. It is part of the same
"contract".

quoted
On x86 they are basically nop.
It calls page_to_phys in your patch. That is hardly nop.
I see. It is certainly worth optimizing it out on x86.
Of course if one day the x86 map_page dma_op starts doing something
useful, we can go back to call it from xen_dma_map_page.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help