From: Adam Belay <ambx1@neo.rr.com>
To: Jaroslav Kysela <perex@suse.cz>
Cc: Daniel Ritz <daniel.ritz@gmx.ch>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [alsa, pnp] more on opl3sa2
Date: Tue, 21 Jan 2003 16:02:28 +0000 [thread overview]
Message-ID: <20030121160228.GH26108@neo.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0301212101130.6355-100000@pnote.perex-int.cz>
On Tue, Jan 21, 2003 at 09:09:14PM +0100, Jaroslav Kysela wrote:
> > the card is not detected by pnp, that problem stays. is that a problem of the pnp layer or is
> > my toshiba laptop just so damn stupid??
>
> Nope. It's fault of the driver. It scans for a card. Actually, the
> structure card -> devices is created only by the ISA PnP driver.
>
> I don't see any reason to not group the PnP BIOS devices into one "card",
> too. Adam, do you have any comments?
>
I have considered this approach several times. However, there are the following
problems with representing the pnpbios devices under one card:
1.) If a driver attaches to the pnpbios card all other card-based drivers will
be unable to use the pnpbios. One will attach and cause the others to fail. It
is possible for the user to have more than one pnpbios sound card but with this
approach such a user would only be able to use one sound device from the entire
pnpbios.
2.) Doing so would misrepresent the pnpbios topology because it physically
doesn't have any cards.
3.) The opl3sa2 driver doesn't need a card because it is only asking for one
device anyway. Using the card interface puts unnecessary overhead on both the
driver and the pnp layer.
4.) The PnP Card Services were designed to support older hardware (pre-pnpbios).
Eventually vendors realized how stupid it was to use more than one device to
perform a single function. Therefore the opl3sa2 and others do not use several
devices and do not need a card interface.
I propose that we use a different solution...
What if we have the opl3sa2 driver along with the other one device drivers
use the pnp_driver interface instead of the pnpc_driver. Jaroslav, Do you
agree with this or would you suggest something else? If you agree, I'll get
to work on a patch.
Regards,
Adam
next prev parent reply other threads:[~2003-01-21 20:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-19 18:07 [alsa, pnp] more on opl3sa2 Daniel Ritz
2003-01-21 19:06 ` Daniel Ritz
2003-01-21 20:09 ` Jaroslav Kysela
2003-01-21 16:02 ` Adam Belay [this message]
2003-01-21 21:43 ` Jaroslav Kysela
2003-01-21 18:23 ` Adam Belay
2003-01-22 2:37 ` Kai Germaschewski
2003-01-22 8:23 ` Jaroslav Kysela
2003-01-22 9:44 ` Jaroslav Kysela
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=20030121160228.GH26108@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=daniel.ritz@gmx.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@suse.cz \
/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