From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: An driver error when I using aplay! Date: Tue, 08 Jun 2004 18:48:08 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20040607145113.B28526@flint.arm.linux.org.uk> <20040607160442.D28526@flint.arm.linux.org.uk> <20040607161812.F28526@flint.arm.linux.org.uk> <20040607164401.G28526@flint.arm.linux.org.uk> <20040607190416.K28526@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: <20040608174057.A24431@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 Tue, 8 Jun 2004 17:40:58 +0100, Russell King wrote: > > On Tue, Jun 08, 2004 at 05:48:45PM +0200, Takashi Iwai wrote: > > At Mon, 7 Jun 2004 19:04:16 +0100, > > Russell King wrote: > > > > > 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? > > > > > > Oddly that's what I did on VIVT caches to get Alsa working a few months > > > ago, but its very unclean and the way I did it, it exposes the "dma" > > > address in the actual page - which would be a major security problem > > > if I let the code out. As I said back then, I didn't have a clean > > > solution for this. > > > > Well, i386 and x86-64 provide a function change_page_attr() for this > > purpose. But it's also a horrible arch-spec hack. > > > > How about to introduce a function like alloc_pages_noncached()? > > Just a quick response on this point while I wait for a rebuild (because > I don't have time to think about the rest of your reply at the moment - > and then I'll probably forget about it by the end of tonight, sorry...) Hehe, I have also a quite limited FIFO queue ;) > I think you'll find that alloc_pages_noncached() is unimplementable on > x86 and other architectures. Some architectures are unable to turn the > cache on and off on a per-page basis, while others can. Some need to > ensure that the relative mappings of two pages fall on the same cache > colour. Some need reprogramming of some hardware depending on where > stuff is mapped. The list goes on and on... Yes. > Basically, I think you'll find that this part of the ALSA API isn't > universally implementable across all kernel architectures. Right. Remember that now the control/status mmap isn't mandatory any more. We can live without it safely. But still it's nicer to use it as much as possible. That is, the scenario is: alloc_pages_noncached() may fail - we accept it. Then the mmap returns the error, and alsa-lib tries non-mmap behavior. -- Takashi Iwai ALSA Developer - www.alsa-project.org ------------------------------------------------------- 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