All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: Clemens Ladisch <cladisch@fastmail.net>
Cc: Krzysztof Helt <krzysztof.h1@gmail.com>,
	ALSA devel <alsa-devel@alsa-project.org>
Subject: Re: [PATCH] opti931: additional check for OPL3 device
Date: Mon, 17 Sep 2007 14:26:25 +0200	[thread overview]
Message-ID: <46EE7271.2050303@gmail.com> (raw)
In-Reply-To: <1190025593.12774.1211014755@webmail.messagingengine.com>

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On 09/17/2007 12:39 PM, Clemens Ladisch wrote:

> Rene Herman wrote:

>> At least 16 won't do -- the OPTi chip provides a 12-byte range. More
>> than 8 would work, but just +8 is fine. I have all OPTi ISA-PnP chips
>> (924, 925, 931, 933) and more aren't going to be produced. The 0x380
>> base is what it calls the OPL4Base and ALBase (AdLib) is at 0x388.
> 
> Are there chips that have both OPL4Base and ALBase?

Not as seperate PnP resources no. Here are pnpdumps for the 4 PnP chips:

http://members.home.nl/rene.herman/opti/

(yes, OPTi 933 is OPT0931 same as OPTi 931)

>> The chip can defer to external FM it seems, but even if there are
>> OPTi/OPL4 combo's out there in the wild (I sort of doubt it)
> 
> Why?

Because an OPL4 is fairly rarely seen as is and all OPTi (PnP) chips I have 
ever seen are on dirt cheap mass-market soundcards. It does not make a lot 
of sense from a business standpoint to put a cheap chip with integrated OPL3 
on a card and then wire up an expensive OPL4 to it. Admittedly, some of 
early OPTi chips may have been somewhat less junky -- 931/3 are worst in 
that respect.

>> the driver's just doing opl3 anyway. ie, still needs just the +8.
> 
> Only the 93x driver; the 92x driver has OPL4 support.

You're right, somehow managed to miss that. According to the code, there's 
overlap with PnP at the 924 which is unfortunate since it means we can't 
just add 8 (unconditionally, nor when the area is larger than 8) to the PnP 
resource -- an OPL4 would be probed for at the wrong address.

How about this? This adds 8 to fm_port only if we're checking for an OPL3 at 
a 16-byte aligned address (such as the 0x380-0x3f0 from the PnP chips). Is 
still second guessing the user if (s)he supplied the value, but what can you 
do. Ack?

Rene.


[-- Attachment #2: opti9xx-fm_port2.diff --]
[-- Type: text/plain, Size: 910 bytes --]

diff --git a/sound/isa/opti9xx/opti92x-ad1848.c b/sound/isa/opti9xx/opti92x-ad1848.c
index 60c120f..1f5af7b 100644
--- a/sound/isa/opti9xx/opti92x-ad1848.c
+++ b/sound/isa/opti9xx/opti92x-ad1848.c
@@ -1890,12 +1890,15 @@ static int __devinit snd_opti9xx_probe(struct snd_card *card)
 			}
 		}
 #endif	/* !OPTi93X */
-		if (!opl3 && snd_opl3_create(card,
-					     chip->fm_port,
-					     chip->fm_port + 2,
-					     OPL3_HW_AUTO, 0, &opl3) < 0) {
-			snd_printk(KERN_WARNING "no OPL device at 0x%lx-0x%lx\n",
-				   chip->fm_port, chip->fm_port + 4 - 1);
+		if (!opl3) {
+			if ((chip->fm_port & 15) == 0)
+				chip->fm_port += 8;
+			error = snd_opl3_create(card, chip->fm_port,
+						chip->fm_port + 2,
+						OPL3_HW_AUTO, 0, &opl3);
+			if (error < 0)
+				snd_printk(KERN_WARNING "no OPL device at 0x%lx-0x%lx\n",
+					   chip->fm_port, chip->fm_port + 4 - 1);
 		}
 		if (opl3) {
 #ifdef CS4231

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2007-09-17 12:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-14 14:35 [PATCH] opti931: additional check for OPL3 device Krzysztof Helt
2007-09-14 14:52 ` Clemens Ladisch
2007-09-14 16:47   ` Krzysztof Helt
2007-09-17  8:14     ` Clemens Ladisch
2007-09-17 10:10       ` Rene Herman
2007-09-17 10:39         ` Clemens Ladisch
2007-09-17 12:26           ` Rene Herman [this message]
2007-09-17 12:26           ` Krzysztof Helt
2007-09-17 12:40             ` Rene Herman
2007-09-17 13:57               ` Rene Herman
2007-09-17 14:45               ` Krzysztof Helt
2007-09-17 15:09                 ` Takashi Iwai
2007-09-17 23:04                 ` Rene Herman
2007-09-14 16:33 ` 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=46EE7271.2050303@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=cladisch@fastmail.net \
    --cc=krzysztof.h1@gmail.com \
    /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.