From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: An driver error when I using aplay! Date: Mon, 07 Jun 2004 18:25:15 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20040607140817.A28526@flint.arm.linux.org.uk> <20040607145113.B28526@flint.arm.linux.org.uk> <20040607160442.D28526@flint.arm.linux.org.uk> <20040607161812.F28526@flint.arm.linux.org.uk> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20040607164401.G28526@flint.arm.linux.org.uk> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Russell King Cc: Jaroslav Kysela , Roc Wu , Clemens Ladisch , Alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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