From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030198AbWGMNbK (ORCPT ); Thu, 13 Jul 2006 09:31:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751473AbWGMNbK (ORCPT ); Thu, 13 Jul 2006 09:31:10 -0400 Received: from mail.suse.de ([195.135.220.2]:9601 "EHLO mx1.suse.de") by vger.kernel.org with ESMTP id S1751472AbWGMNbI (ORCPT ); Thu, 13 Jul 2006 09:31:08 -0400 Date: Thu, 13 Jul 2006 15:30:55 +0200 Message-ID: From: Takashi Iwai To: Russell King Cc: Nick Piggin , Marc Singer , Linux-Kernel Subject: Re: DMA memory, split_page, BUG_ON(PageCompound()), sound In-Reply-To: <20060712103241.GA7908@flint.arm.linux.org.uk> References: <20060709000703.GA9806@cerise.buici.com> <44B0774E.5010103@yahoo.com.au> <20060710025103.GC28166@cerise.buici.com> <44B1FAE4.9070903@yahoo.com.au> <20060710162600.GB18728@flint.arm.linux.org.uk> <44B28F93.9020304@yahoo.com.au> <20060712103241.GA7908@flint.arm.linux.org.uk> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta25) (eggplant) (+CVS-20060326) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Wed, 12 Jul 2006 11:32:41 +0100, Russell King wrote: > > On Tue, Jul 11, 2006 at 03:34:11AM +1000, Nick Piggin wrote: > > Russell King wrote: > > >On Mon, Jul 10, 2006 at 04:59:48PM +1000, Nick Piggin wrote: > > > > > >>I guess you could do it a number of ways. Maybe having GFP_USERMAP > > >>set __GFP_USERMAP|__GFP_COMP, and the arm dma memory allocator can > > >>strip the __GFP_COMP. > > >> > > >>If you get an explicit __GFP_COMP passed down, the allocator doesn't > > >>know whether that was because they want a user mappable area, or > > >>really want a compound page (in which case, stripping __GFP_COMP is > > >>the wrong thing to do). > > > > > > > > >So I'll mask off __GFP_COMP for the time being in the ARM dma allocator > > >with a note to this effect? > > > > I believe that should do the trick, yes (AFAIK, nobody yet is > > explicitly relying on a compound page from the dma allocator). > > In which case should ALSA be passing __GFP_COMP to the dma allocator ? I would be willing to remove __GFP_COMP if it's not needed :) Passing this flag is really confusing. The driver doesn't use the compound pages at all but it was added just to enable mmap support. So, Nick's proposal appears reasonable to me. Takashi