From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Subject: Re: hw_params function and OSS emulation Date: Thu, 23 Aug 2007 14:13:08 -0500 Message-ID: <46CDDC44.40709@freescale.com> References: <46CB2BB4.9060808@freescale.com> <46CC480F.7090604@freescale.com> <46CC4FF3.6090607@freescale.com> <46CC5ADC.4020605@freescale.com> <46CDC5AB.6080602@freescale.com> <46CDD55C.5040301@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by alsa0.perex.cz (Postfix) with ESMTP id 2A93B24366 for ; Thu, 23 Aug 2007 21:13:17 +0200 (CEST) In-Reply-To: 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: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org Takashi Iwai wrote: > At Thu, 23 Aug 2007 13:43:40 -0500, > Timur Tabi wrote: >> Takashi Iwai wrote: >> >>> Err, usually, application = user-space application. Do you mean >>> really this? >> Yes. The application allocates a buffer, locks it down, and passes it to the >> kernel. Since the buffer was allocated in user space, it is virtual >> contiguous but not physically contiguous, hence the need for a list of >> physical addresses. To the hardware, the buffer appears as a collection of >> scattered buffers. Hence, scatter/gather. > > Hm, then it must be a really special application. I've never seen > linux audio apps doing such things... That could be. I'm using a generic definition of S/G. Perhaps I should read the ALSA API before posting further. :-) > The problem in your scenario is that the buffers allocated from > user-space are not always DMA-able for devices, thus not always usable > for the hardware. It's possible for an application to allocate DMA-able memory. I think you need to allocate it normally than use mlock() on it, but it's been a while so I'm not sure. > The ALSA SG-buffer helper is simply to allocate individual pages and > gather as a virtually linear buffer. From the user-space, it's > nothing but a normal linear buffer. So what is the value of having the driver allocate a physically discontiguous buffer when it can easily allocate a contiguous one? Are there systems where allocating a 32KB physically-contiguous buffer is too hard? -- Timur Tabi Linux Kernel Developer @ Freescale