Re: An driver error when I using aplay!

[Takashi Iwai <tiwai@suse.de>]

At Mon, 7 Jun 2004 16:44:01 +0100,
Russell King wrote:
> 
> > Where we're here:  I'd really like to fix the DMA problem of ALSA on
> > ARM.  As I sent you before, the patch is already there but I have no
> > idea whether it's really right or not.  Could you please comment
> > whether the assumptions below are correct?
> > 
> > - the page struct can be retrieved from dma_addr_t of
> >   dma_alloc_coherent() like
> > 
> > 	virt_to_page(bus_to_virt(addr))
> 
> Well, bus_to_virt() is a deprecated interface, and one which is
> meaningless on certain classes of machines.

Yes, ideally such a stuff should be really in the arch-specific kernel
part.  (BTW, the above is assumed to be ARM specific.)

> Really, we shouldn't be adding code which relies on it.

Agreed.

> What we should be doing is something like the following, which is
> a generic set of coherent DMA allocation, freeing, and mmap
> functions which would cover any driver-model based device.

So, do you mean to hide the stuffs like above (and cache disabling) in
this new mmap function dedicated for the coherent DMA?

> snd_pcm_ops_t should have a mmap() method just like everything else
> in the kernel, which allows drivers to select the appropriate mmap()
> implementation.

I thought of this, too.  This may help some cases, but we still need a
generic solution, because a PCI driver can be used in different
architectures.


> > - adding pgprot_noncached() in fop->mmap callback assures that the
> >   mmaped page is accessed without cache side effects.
> 
> Correct, but as it has been already decided elsewhere, interfaces
> which expose pgprot tweaking are broken and new ones should not be
> introduced.

Hmm, is there a standard interface for this purpose?
So far, setting like
	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
looks like the only way to achieve this.

(If this whole mmap method itself is hidden in the generic function,
 this is not exposed, though...)

> They also _may_ only affect the userspace mapping of
> that memory and not kernel space, so this doesn't help the control
> or status mmaped pages.

Oh yes, then how about to use a DMA page for the control/status mmap,
too?


thanks,

Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org