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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox