public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;
 	}
 }
 

  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