From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] 1/3 Implement generic device DMA mapping support Date: Mon, 01 Mar 2004 18:51:56 +0100 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20040229223820.C17862@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: <20040301174517.J24955@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 , Alsa Devel list List-Id: alsa-devel@alsa-project.org At Mon, 1 Mar 2004 17:45:17 +0000, Russell King wrote: > > On Mon, Mar 01, 2004 at 04:41:00PM +0100, Takashi Iwai wrote: > > At Sun, 29 Feb 2004 22:38:20 +0000, > > Russell King wrote: > > > > > > This is the first shot at this - I've tested it on ARM, covering both > > > ISA ALSA devices on a PCI machine, and driver model devices on a non- > > > PCI, non-ISA machine. However, it needs more testing. Can people > > > on alsa-devel please test these patches. > > > > > > This patch adds support for the generic device/driver model to ALSA > > > for the sole purpose of supporting their DMA mapping functionality. > > > > > > This patch changes snd_malloc_sgbuf_pages() to use this dma mapping > > > functionality. > > > > thanks for the patch. using struct device is nice for > > generalization. > > > > after a short glance, the only drawback i found is that you disabled > > the single pci page allocation hack for i386. this was needed to > > cover the non-atomic page allocation. > > for example, sb live needs to allocate more than 100MB single pages > > for the wavetable data. the allocation with GFP_ATOMIC can fail > > easily in such a case, althogh there is enough memory after swapping. > > maybe we can leave this function as another... > > I think you've assumed that: > > + res = dma_alloc_coherent(dev, PAGE_SIZE << pg, dma, GFP_KERNEL); > > in snd_malloc_dev_pages() uses GFP_ATOMIC. Please look closer. ah, yes, then it's fine. thanks. a small concern about GFP_KERNEL is that i experienced the stall when the kernel tried to allocate large continuous pages with GFP_KERNEL, e.g. modprobe stops infinitely in the module init phase (and you cannot even interrupt that process). does dma_alloc_coherent(GFP_KERNEL) with big pages work without stall? Takashi ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click