[alsa-devel] ALSA 1.0.17rc2 release

[Takashi Iwai]

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