On (22/01/11 09:59), Christoph Hellwig wrote: [..] > >>> You mean you would call "invalidate_kernel_vmap_range" before "dma_sync_sgtable_for_cpu" ? > >> > >> Yes. > > > > Could you explain why? > > the vmap range is the one actually use for cpu access and thus most > prone for speculation, so I'd invalidate it first. It probably does > not matter to much, but that order looks more sensible. Shall we do the same in videobuf2? ---- diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c index 7c4096e62173..0e3f264122af 100644 --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c @@ -132,12 +132,12 @@ static void vb2_dc_prepare(void *buf_priv) if (!buf->non_coherent_mem) return; - /* For both USERPTR and non-coherent MMAP */ - dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir); - /* Non-coherent MMAP only */ if (buf->vaddr) flush_kernel_vmap_range(buf->vaddr, buf->size); + + /* For both USERPTR and non-coherent MMAP */ + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir); } static void vb2_dc_finish(void *buf_priv) @@ -152,12 +152,12 @@ static void vb2_dc_finish(void *buf_priv) if (!buf->non_coherent_mem) return; - /* For both USERPTR and non-coherent MMAP */ - dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir); - /* Non-coherent MMAP only */ if (buf->vaddr) invalidate_kernel_vmap_range(buf->vaddr, buf->size); + + /* For both USERPTR and non-coherent MMAP */ + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir); } /*********************************************/
