From: Rene Herman <rene.herman@keyaccess.nl>
To: Santiago Garcia Mantinan <manty@manty.net>
Cc: Takashi Iwai <tiwai@suse.de>,
linux-kernel@vger.kernel.org, Adam Belay <ambx1@neo.rr.com>
Subject: [PATCH] Re: ALSA in 2.6 failing to find the OPL chip of the sb cards
Date: Sun, 11 Jan 2004 06:33:36 +0100 [thread overview]
Message-ID: <4000E030.2020500@keyaccess.nl> (raw)
In-Reply-To: <3FFFA8C3.6040609@keyaccess.nl>
[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]
Rene Herman wrote:
NOTE: I seem unable to contact Adam Belay; his ISP is not accepting mail
from mine. Takashi, if you agree attached patch is a correct fix, could
you relay it to Adam?
>> ALSA sound/drivers/opl3/opl3_lib.c:444: OPL2/3 chip not detected at
>> 0x388/0x38a
>> ALSA sound/isa/sb/sb16.c:484: sb16: no OPL device at 0x388-0x38a
>>
>> I think I have already said that in 2.4 it works, and I have tested both
>> alsa in the kernel plus alsa sources downloaded from alsa-project,
>> this last
>> one works in 2.4 but doesn't work in 2.6.
>
> I'm seeing the same behaviour with a Sound Blaster AWE64 Gold. It seems
> it's not an ALSA problem though, but ISA-PnP.
Assuming ALSA isn't misusing the PnP API, it's indeed not ALSA, but PnP.
It also isn't actually an OPL3 issue, but MPU401. Trouble is that sb16.c
doesn't set mpu_port to SNDRV_DEFAULT_PORT, but hardcodes the values for
the first two cards as 0x330 and 0x300 (Takashi: why is that, by the
way? At least for ISA-PnP cards SNDRV_DEFAULT_PORT would seem better?).
This causes the initialisation code to call pnp_resource_change() for
the MPU port resource, which clears IORESOURCE_AUTO for that resource.
The rest of the PnP layer, seeing IORESOURCE_AUTO clear, then never
touches that resource again, but at that point IORESOURCE_IO (indicating
an I/O port resource) hasn't yet been set, so that when it later gets to
isapnp_set_resources(), that function bails out believing it has reached
the end of the I/O port resources for the device. Since SB is resource
0, MPU401 resource 1 and OPL3 resource 2 for the device, only SB gets
enabled, MPU401 and OPL3 do not.
Making sure IORESOURCE_IO gets set fixes it. Having
pnp_init_resource_table() do this seems proper.
The attached patch works for me:
rene@7ixe4:~$ sbiload -l
Port Client name Port name
64:0 Rawmidi 0 - MPU-401 (UART) 0-0 MPU-401 (UART) 0-0
65:0 Emu8000 WaveTable Emu8000 Port 0
65:1 Emu8000 WaveTable Emu8000 Port 1
65:2 Emu8000 WaveTable Emu8000 Port 2
65:3 Emu8000 WaveTable Emu8000 Port 3
66:0 OPL3 FM synth OPL3 FM Port
Rene.
[-- Attachment #2: linux-2.6.1_pnp_resource.diff --]
[-- Type: text/plain, Size: 1449 bytes --]
--- linux-2.6.1/drivers/pnp/manager.c.orig 2004-01-11 05:32:34.000000000 +0100
+++ linux-2.6.1/drivers/pnp/manager.c 2004-01-11 05:15:36.000000000 +0100
@@ -223,25 +223,25 @@
table->irq_resource[idx].name = NULL;
table->irq_resource[idx].start = -1;
table->irq_resource[idx].end = -1;
- table->irq_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET;
+ table->irq_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET | IORESOURCE_IRQ;
}
for (idx = 0; idx < PNP_MAX_DMA; idx++) {
table->dma_resource[idx].name = NULL;
table->dma_resource[idx].start = -1;
table->dma_resource[idx].end = -1;
- table->dma_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET;
+ table->dma_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET | IORESOURCE_DMA;
}
for (idx = 0; idx < PNP_MAX_PORT; idx++) {
table->port_resource[idx].name = NULL;
table->port_resource[idx].start = 0;
table->port_resource[idx].end = 0;
- table->port_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET;
+ table->port_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET | IORESOURCE_IO;
}
for (idx = 0; idx < PNP_MAX_MEM; idx++) {
table->mem_resource[idx].name = NULL;
table->mem_resource[idx].start = 0;
table->mem_resource[idx].end = 0;
- table->mem_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET;
+ table->mem_resource[idx].flags = IORESOURCE_AUTO | IORESOURCE_UNSET | IORESOURCE_MEM;
}
}
next prev parent reply other threads:[~2004-01-11 5:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-07 21:29 ALSA in 2.6 failing to find the OPL chip of the sb cards Santiago Garcia Mantinan
2004-01-08 17:21 ` Takashi Iwai
2004-01-08 22:42 ` Santiago Garcia Mantinan
2004-01-09 17:17 ` Santiago Garcia Mantinan
2004-01-09 17:37 ` Takashi Iwai
2004-01-09 20:14 ` Santiago Garcia Mantinan
2004-01-10 7:24 ` Rene Herman
2004-01-11 5:33 ` Rene Herman [this message]
2004-01-12 15:35 ` [PATCH] " Takashi Iwai
2004-01-13 23:29 ` Adam Belay
2004-01-14 19:07 ` Adam Belay
2004-01-15 0:36 ` Rene Herman
2004-01-15 23:35 ` Rene Herman
2004-01-18 22:26 ` Santiago Garcia Mantinan
2004-01-12 21:14 ` Santiago Garcia Mantinan
2004-01-12 15:31 ` Takashi Iwai
2004-01-12 20:51 ` Rene Herman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4000E030.2020500@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=ambx1@neo.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manty@manty.net \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.