At Thu, 21 Aug 2008 18:01:49 +0200,
I wrote:
>
> At Thu, 21 Aug 2008 08:55:12 -0500,
> James Bottomley wrote:
> >
> > On Thu, 2008-08-21 at 12:19 +0200, Takashi Iwai wrote:
> > > At Wed, 20 Aug 2008 12:58:08 -0500,
> > > James Bottomley wrote:
> > > >
> > > > On Wed, 2008-08-20 at 18:53 +0200, Takashi Iwai wrote:
> > > > > > I'm afraid there are several problems. The first is that it doesn't do
> > > > > > what you want. You can't map a coherent page to userspace (which is at
> > > > > > a non congruent address on parisc) and still expect it to be
> > > > > > coherent ... there's going to have to be fiddling with the page table
> > > > > > caches to make sure coherency isn't destroyed by aliasing effects
> > > > >
> > > > > Hmm... how bad would be the coherency with such a simple mmap method?
> > > > > In most cases, we don't need the "perfect" coherency. Usually one
> > > > > process mmaps the whole buffer and keep reading/writing. There is
> > > > > another use case (sharing the mmapped buffer by multiple processes),
> > > > > but this can be disabled if we know it's not feasible beforehand.
> > > >
> > > > Unfortunately, the incoherency is between the user and the kernel.
> > > > That's where the aliasing effects occur, so realistically, even though
> > > > you've mapped coherent memory to the user, the coherency of that memory
> > > > is only device <-> kernel. When the any single user space process
> > > > writes to it, the device won't see the write unless the user issues a
> > > > flush.
> > >
> > > I see. In the case of ALSA mmap mode, a user issues an ioctl to
> > > notify after the read/write access, so it'd be relatively easy to add
> > > a sync operation.
> > >
> > > Does the call of dma_sync_*_for_device() suffice for that purpose?
> >
> > No ... dma_sync_* sync's from the kernel to the device ... you don't
> > need that if the memory is already coherent.
> >
> > The problem is that the data you want the device to see is held in a
> > cache above the user space mapping ... it's that cache that has to be
> > flushed (i.e. you need to flush through the user mappings, not through
> > the kernel ones).
> >
> > > (BTW, how does the fb driver work on this?)
> >
> > It sets the shared page to uncached on all its mappings. Turning off
> > caching (assuming the platform can do it ... not all can) is a good way
> > to eliminate aliasing issues.
>
> Thanks for clarification.
> How about the revised patch below (for PARISC)?
... and the below is for MIPS.
thanks,
Takashi
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index 891312f..2307f56 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -387,3 +387,16 @@ void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
}
EXPORT_SYMBOL(dma_cache_sync);
+
+int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t handle, size_t size)
+{
+ struct page *pg;
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ cpu_addr = (void *)dma_addr_to_virt(handle);
+ pg = virt_to_page(cpu_addr);
+ return remap_pfn_range(vma, vma->vm_start,
+ page_to_pfn(pg) + vma->vm_pgoff,
+ size, vma->vm_page_prot);
+}
+EXPORT_SYMBOL(dma_mmap_coherent);
diff --git a/include/asm-mips/dma-mapping.h b/include/asm-mips/dma-mapping.h
index c64afb4..ab12cd4 100644
--- a/include/asm-mips/dma-mapping.h
+++ b/include/asm-mips/dma-mapping.h
@@ -68,6 +68,9 @@ extern int dma_is_consistent(struct device *dev, dma_addr_t dma_addr);
extern void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction direction);
+extern int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t handle, size_t size);
+
#if 0
#define ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY
