All of lore.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 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.