At Wed, 18 Nov 2009 15:20:56 +0100, Ralf Baechle wrote:
On Tue, Nov 17, 2009 at 10:29:10AM +0100, Takashi Iwai wrote:
Actually, this has been a looong-standing problem. I have a series of patches to fix these issues, but it's more intensively involved with dma_*() functions.
The patches can be found in test/dma-fix branch of sound GIT tree. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
This basically adds dma_mmap_coherent() function to feasible architectures, which is already implemented for ARM, so far.
Cool - but needs a little further tweaking to work right. That's a solution which will use uncached accesses on all MIPS systems.
IP27/IP35-family machines will explode when you try that. Eventually the cache coherency logic will notice that cache, directory caches and memory have become inconsistent and bombard the CPU with a bunch of nasty exceptions.
OK, that's really bad.
Hardware designers do such things to you. Often even for a reason.
Heh, not only software engineers are so crazy ;)
For cache-coherent machines otoh it's a big waste of performance.
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;
if (!plat_device_is_coherent(dev)) 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);
Thomas - you're the IP28 specialist. Would the plat_device_is_coherent() above have to become a cpu_is_noncoherent_r10000() call? Any further nasties?
Thanks for checking!
You're welcome!
So basically I'd not mind putting this into the Linux/MIPS tree; we still can iron out the kinks from there on and probably much better than by having arch stuff in the ALSA tree.
Yes, that's the very purpose of my patchset.
I recall this new API having been posted for discussion to linux-arch. What was the outcome? I'd only like to add a new API if the other arch maintainers see it fit their needs also.
Well, we haven't reached the consensus. The discussion faded away somehow mainly because I had too little time to update and ping people again.
In Tokyo, I talked with some guys regarding this. Ben agreed to take this approach for ppc, and David said that he doesn't mind for sparc part. Fujita-san mentioned it's no big problem to add one op from the generic dma_ops.
So, maybe somehow need to convince James in the end (and ask Paul to check SH part, too), then it'll be all up... theoretically :)
Anyway, I'm going to raise the discussion again on linux-arch. I'm afraid it's a bit too late game for 2.6.33, but starting now is better than too late again.
thanks,
Takashi