At Tue, 17 Jun 2008 15:23:03 +0200 (CEST), Jaroslav Kysela wrote: > > On Tue, 17 Jun 2008, Takashi Iwai wrote: > > > At Tue, 17 Jun 2008 14:12:06 +0200 (CEST), > > Jaroslav Kysela wrote: > > > > > > On Tue, 17 Jun 2008, Takashi Iwai wrote: > > > > > > > At Tue, 17 Jun 2008 13:42:40 +0200 (CEST), > > > > Jaroslav Kysela wrote: > > > > > > > > > > On Tue, 17 Jun 2008, Alan Horstmann wrote: > > > > > > > > > > > I have just confirmed that pasting > > > > > > > > > > > > #define GFP_DMA32 ((__force gfp_t)0x04u) > > > > > > > > > > > > into /alsa-kernel/pci/emu10k1/memory.c (not a correct fix -just taken from > > > > > > 2.6.24 headers) enables build to complete. So there should be no other > > > > > > hidden issues. > > > > > > > > > > Could you try attached patch (also pasted bellow)? > > > > > > > > That's too overhead. A simple #ifndef GFP_DMA32 would work. > > > > And, GFP_DMA32 isn't GFP_DMA. > > > > > > But old kernels with dma_mask < 0xffffffff sets GFP_DMA flag for page > > > allocation. So there's no regression. > > > > GFP_DMA32 means to allocate from ZONE_DMA32 which was a part of > > ZONE_NORMAL. > > Yes for 2.6, but 2.4 kernels do not have this flag. The function > pci_alloc_consistent() was used before your patch "[ALSA] emu10k1 - > simplify page allocation for synth" and pci_alloc_consistent() just uses > GFP_DMA flag for page allocation when dma_mask < 32bit. So the result is > same. No. pci_alloc_consistent() wasn't directly used, and there was already a hack for that in the memory allocator. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
