From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH 0/5] PCM mmap (temporary) fixes for non-coherent architectures Date: Fri, 15 Jan 2010 08:32:23 +0100 Message-ID: References: <1259248388-20095-1-git-send-email-tiwai@suse.de> <20100101193130.GA21510@rhlx01.hs-esslingen.de> <1263526082.724.395.camel@pasglop> <1263538249.724.405.camel@pasglop> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id D9A8B2433C for ; Fri, 15 Jan 2010 08:32:23 +0100 (CET) In-Reply-To: <1263538249.724.405.camel@pasglop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Benjamin Herrenschmidt Cc: linux-mips@linux-mips.org, alsa-devel@alsa-project.org, Thomas Bogendoerfer , Becky Bruce , Wu Zhangjin , Ralf Baechle , Andreas Mohr , Kumar Gala List-Id: alsa-devel@alsa-project.org At Fri, 15 Jan 2010 17:50:49 +1100, Benjamin Herrenschmidt wrote: > > On Fri, 2010-01-15 at 07:43 +0100, Takashi Iwai wrote: > > > > > It -might- be worth looking at adding code to the USB stack to > > propagate > > > the parent device dma_ops down to USB devices... hard to tell. > > > > Or we may simply need to drop the mmap support on such > > architectures... > > Nah, that would suck since that includes x86 nowadays :-) Ah, no, I meant about non-coherent architectures that can't use vmalloc pages as the intermediate buffer. Dropping mmap for x86 would be a big regression ;) > I think you probably need to separate the struct device * used for DMA > (it could be default be the same as the "main" struct device tho or it > could default to NULL which means no mmap support). > > USB could (if not already) provide an accessor to obtain the HC's struct > device for such mappings. We'll have to discuss that with Alan Stern I > suppose. > > The USB Audio or similar drivers could then use that accessors to fill > up Alsa's dma_device field to replace the "default". The situation of usb-audio is, unfortunately, a bit more complex because the driver needs a continuous ring-buffer. The packet data are copied from that intermediate buffer on demand. This isn't efficient, but the continuous ring-buffer is demanded by the current API design exported as mmap. thanks, Takashi From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jan 2010 08:32:29 +0100 (CET) Received: from cantor2.suse.de ([195.135.220.15]:60108 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491138Ab0AOHcY (ORCPT ); Fri, 15 Jan 2010 08:32:24 +0100 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id AD77B79727; Fri, 15 Jan 2010 08:32:23 +0100 (CET) Date: Fri, 15 Jan 2010 08:32:23 +0100 Message-ID: From: Takashi Iwai To: Benjamin Herrenschmidt Cc: Andreas Mohr , alsa-devel@alsa-project.org, Ralf Baechle , Wu Zhangjin , Thomas Bogendoerfer , linux-mips@linux-mips.org, Kumar Gala , Becky Bruce Subject: Re: [PATCH 0/5] PCM mmap (temporary) fixes for non-coherent architectures In-Reply-To: <1263538249.724.405.camel@pasglop> References: <1259248388-20095-1-git-send-email-tiwai@suse.de> <20100101193130.GA21510@rhlx01.hs-esslingen.de> <1263526082.724.395.camel@pasglop> <1263538249.724.405.camel@pasglop> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-archive-position: 25596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tiwai@suse.de Precedence: bulk X-list: linux-mips Return-Path: X-Keywords: X-UID: 10021 At Fri, 15 Jan 2010 17:50:49 +1100, Benjamin Herrenschmidt wrote: > > On Fri, 2010-01-15 at 07:43 +0100, Takashi Iwai wrote: > > > > > It -might- be worth looking at adding code to the USB stack to > > propagate > > > the parent device dma_ops down to USB devices... hard to tell. > > > > Or we may simply need to drop the mmap support on such > > architectures... > > Nah, that would suck since that includes x86 nowadays :-) Ah, no, I meant about non-coherent architectures that can't use vmalloc pages as the intermediate buffer. Dropping mmap for x86 would be a big regression ;) > I think you probably need to separate the struct device * used for DMA > (it could be default be the same as the "main" struct device tho or it > could default to NULL which means no mmap support). > > USB could (if not already) provide an accessor to obtain the HC's struct > device for such mappings. We'll have to discuss that with Alan Stern I > suppose. > > The USB Audio or similar drivers could then use that accessors to fill > up Alsa's dma_device field to replace the "default". The situation of usb-audio is, unfortunately, a bit more complex because the driver needs a continuous ring-buffer. The packet data are copied from that intermediate buffer on demand. This isn't efficient, but the continuous ring-buffer is demanded by the current API design exported as mmap. thanks, Takashi