Re: 2.5.73: ALSA ISA pnp_init_resource_table compile errors

[Adam Belay <ambx1@neo.rr.com>]

On Wed, Jul 16, 2003 at 08:22:52PM +0200, Adrian Bunk wrote:
> On Tue, Jul 15, 2003 at 10:47:32PM +0000, Adam Belay wrote:
> > Could I see the output for 01:01.00/options and 01:01.00/resources also,
> > perhaps it will provide some insight.  I'm guessing the resources may be
> > incorrect in that node.
>
> It's below, this using with 2.6.0-test1 (same dmesg output):
> 
> <--  snip  -->
> 
> # cat /sys/bus/pnp/devices/01\:01.01/resources
> state = active
> io 0x330-0x331
> irq 9
> # cat /sys/bus/pnp/devices/01\:01.01/options
> Dependent: 01 - Priority preferred
>    port 0x330-0x330, align 0xf, size 0x2, 16-bit address decoding
>    irq 2/9 High-Edge
> Dependent: 02 - Priority acceptable
>    port 0x300-0x330, align 0xf, size 0x2, 16-bit address decoding
>    irq 2/9 High-Edge
> Dependent: 03 - Priority functional
>    port 0x300-0x330, align 0xf, size 0x2, 16-bit address decoding
>    irq 2/9,10,11,15 High-Edge
> # cat /sys/bus/pnp/devices/01\:01.00/resources
> state = active
> io 0x220-0x22f
> io 0x388-0x38b
> io 0x500-0x50f
> irq 5
> dma 1
> dma disabled
> # cat /sys/bus/pnp/devices/01\:01.00/options
> Dependent: 01 - Priority preferred
>    port 0x220-0x220, align 0x1f, size 0x10, 16-bit address decoding
>    port 0x388-0x388, align 0x7, size 0x4, 16-bit address decoding
>    port 0x530-0x530, align 0x7, size 0x10, 16-bit address decoding
>    irq 5 High-Edge
>    dma 1 8-bit byte-count type-A
>    dma 3 8-bit byte-count type-A
> Dependent: 02 - Priority acceptable
>    port 0x220-0x240, align 0x1f, size 0x10, 16-bit address decoding
>    port 0x388-0x388, align 0x7, size 0x4, 16-bit address decoding
>    port 0x530-0x530, align 0xf, size 0x10, 16-bit address decoding
>    irq 5,7 High-Edge
>    dma 0,1,3 8-bit byte-count type-A
>    dma 0,1,3 8-bit byte-count type-A
> Dependent: 03 - Priority functional
>    port 0x220-0x280, align 0x1f, size 0x10, 16-bit address decoding
>    port 0x388-0x3b8, align 0x7, size 0x4, 16-bit address decoding
>    port 0x500-0x560, align 0xf, size 0x10, 16-bit address decoding
>    irq 5,7,10 High-Edge
>    dma 0,1,3 8-bit byte-count type-A
>    dma 0,1,3 8-bit byte-count type-A
> Dependent: 04 - Priority functional
>    port 0x220-0x280, align 0x1f, size 0x10, 16-bit address decoding
>    port 0x388-0x3b8, align 0x7, size 0x4, 16-bit address decoding
>    port 0x500-0x620, align 0xf, size 0x10, 16-bit address decoding
>    irq 5,7,10,11 High-Edge
>    dma 0,1,3 8-bit byte-count type-A
>    dma <none> 8-bit byte-count type-A
> Dependent: 05 - Priority functional
>    port 0x220-0x280, align 0x1f, size 0x10, 16-bit address decoding
>    port 0x388-0x3b8, align 0x7, size 0x4, 16-bit address decoding
>    port 0x500-0x620, align 0xf, size 0x10, 16-bit address decoding
>    irq 5,7,2/9,10,11,15 High-Edge
>    dma 0,1,3 8-bit byte-count type-A
>    dma <none> 8-bit byte-count type-A
> # 
> 
> <--  snip  -->
> 
> > Thanks,
> > Adam
> 
> cu
> Adrian
>

Hi Adrian,

Thanks for the information, I think I have a good idea of whats going here.
Notice the disabled dma in node 01:01.00.  The alsa code appears to not be
able to handle a disabled dma for this device.  The offending code is
probably here:

sound/isa/ad1816a/ad1816a_lib.c - line 609 - function snd_ad1816a_create

	if (request_dma(dma2, "AD1816A - 2")) {
		snd_ad1816a_free(chip);
		return -EBUSY;
	}
	chip->dma2 = dma2;

The value of disabled dma2 is -1.  Therefore the request_dma fails because
of this code:

int request_dma(unsigned int dmanr, const char * device_id)
{
	if (dmanr >= MAX_DMA_CHANNELS)
		return -EINVAL;

	if (xchg(&dma_chan_busy[dmanr].lock, 1) != 0)
		return -EBUSY;

	dma_chan_busy[dmanr].device_id = device_id;

	/* old flag was 0, now contains 1 to indicate busy */
	return 0;
} /* request_dma */

Because it is unsigned long it requests dma 0xffff which is greater than
MAX_DMA_CHANNELS and therefore the function returns -EINVAL.

So I'd imagine we could fix the driver to support this... Jaroslav, any
comments?  Perhaps we could use pnp_dma_valid?  Also it would be nice to
add a printk that will display if snd_ad1816a_create fails.

There is one question unanswered however, why is pnp picking the resource
option 4 or possibly 5 (assigning a blank dma).  Its almost as if dma 3 is
in use?

Could I see the following?

1.) the output of /proc/dma
2.) the output of
# cd /sys/bus/pnp/devices
# find */resources | xargs cat | grep dma
3.) the output of
# cd /sys/bus/pnp/devices
# find */resources | xargs cat | grep io

Also there is a kernel parameter to allow dma 0.  It is 'allowdma0' and
I predict the extra dma will get the sound card working.

Thanks,
Adam