Re: 2.6.26-rc1 regression: ISA DMA broken (bisected)

[Takashi Iwai <tiwai@suse.de>]

At Wed, 14 May 2008 17:40:55 +0200,
Rene Herman wrote:
> 
> On 14-05-08 15:01, Takashi Iwai wrote:
> > At Wed, 14 May 2008 14:46:44 +0200,
> > Rene Herman wrote:
> 
> >> If it's going to be useful, definitely. The attached does not just set
> >>
> >>    dev->dma_mask = &dev->coherent_dma_mask
> >>
> >> as in the fallback_dev when dma_alloc_coherent() is passed a NULL device 
> >> only due to the mask juggling in snd_dma_hack_alloc_coherent() (which 
> >> wouldn't break, but...) but introduces its own copy in struct isa_dev 
> >> same as struct pnp_dev. As far as I'm aware, there's no actual reason 
> >> for keeping it other than that and if the hack could go I'd rather lose 
> >> the private mask copy again also.
> > 
> > The snd_dma_hack_alloc_coherent() is gone in the latest ALSA tree.
> > It wasn't merged to 2.6.26, though.
> 
> Ah, good, thanks, I'll forward port to current ALSA.

Check the master branch of the following tree for the latest ALSA:
	git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

> >> At least the ALSA one isn't passing a literal NULL it seems. But yes, 
> >> current NULL-hack reinstatement (it's been merged by Linus already) is 
> >> definitely the correct fix for now.
> > 
> > Yes.  We need to fix the caller of snd_pcm_lib_preallocate_pages*()
> > under sound/isa.  Currently it's called with snd_dma_isa_data(), which
> > is expanded to NULL.  Replace it with a proper device pointer should
> > suffice.
> 
> Like this?

I prefer passing the device pointer directly.

Note that snd_dma_isa_data() is just for making the code compatible
more easily with older kernels in alsa-driver tree.  Otherwise we'd
need a patch file for each source file.  But, the patch-file approach
is cleaner (for the upstream) anyway at this stage.

>  With this (on top of the previous patch setting the dma_mask 
> ofcourse) legacy ISA actually appears to be fine but it's then ISAPnP 
> which goes bonkers again. Sigh. Getting an allocation failure. Don't 
> understand why yet since pnp_alloc_dev() definitely sets the mask 
> already. Will stare...


thanks,

Takashi