From: Adam Belay <ambx1@neo.rr.com>
To: Jaroslav Kysela <perex@perex.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [alsa, pnp] more on opl3sa2 (fwd)
Date: Wed, 5 Feb 2003 22:01:32 +0000 [thread overview]
Message-ID: <20030205220132.GA10021@neo.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0302031457580.1116-100000@pnote.perex-int.cz>
On Mon, Feb 03, 2003 at 03:15:59PM +0100, Jaroslav Kysela wrote:
> On Thu, 30 Jan 2003, Adam Belay wrote:
>
> > Hi Jaroslav,
> >
> > How does this sound...
> >
> > What if we make pnp card services match against all pnp cards and allow more
> > than one card driver to use the same card. This can be accomplished if we detach
> > the card portion from the driver model and use driver_attach. If you feel it is
>
> The question is probably another. I know that your solution will work, but
> do we need such hack against the driver model in our code? If you work
> with cards as buses, it allows us the same model as PCI code.
>
> > necessary, we could also add an optional card id to the pnp_device_id structure.
> > As for the pnpbios, I disagree with putting it under one card. If the pnpbios
> > contains two opl3sa2 sound cards then only one will be matched and therefore it
>
> It's not true. The driver model calls probe for all instances.
>
> > is a bad idea to represent the pnpbios as a card. When ACPI is introduced, both
>
> Note that if we make card as bus, then this problem will disapear.
> The enumeration will be simple: devices on the one bus. And it's strong
> advantage over current implementation when bus == protocol.
>
> What do you think about this model:
>
> bus (PnP BIOS) -> devices
> bus (ACPI) -> devices
> bus (ISA PnP) -> bus (cards) -> devices
>
I think this model has potential but before we go that direction I'd like to hear
your reactions on another more simplistic model. I'll express it with a
hypothetical code example. This model completely drops individual card matching
and is compatible with both card users and non-card users.
static struct pnp_device_id snd_als100_pnpids[] = {
/* ALS100 - PRO16PNP */
{.card_id = "ALS0001" .id = "@@@0001", .driver_data = ALS100_AUDIO},
{.card_id = "ALS0001" .id = "@X@0001", .driver_data = ALS100_MPU},
{.card_id = "ALS0001" .id = "@H@0001", .driver_data = ALS100_OPL},
/* ALS110 - MF1000 - Digimate 3D Sound */
{.card_id = "ALS0110" .id = "@@@1001", .driver_data = ALS100_AUDIO},
{.card_id = "ALS0001" .id = "@X@1001", .driver_data = ALS100_MPU},
{.card_id = "ALS0001" .id = "@H@1001", .driver_data = ALS100_OPL},
---> snip
};
static int __init snd_card_als100_probe(struct pnp_dev * dev, struct pnp_device_id * id)
{
---> snip
snd_card_t *card;
---> snip
card = snd_card_find(dev->card); /* this function searches for previously
registered sound cards and binds this
device to it if it finds that it was a
member of the same pnp_card */
if (!card) {
if ((card = snd_card_new(index[dev], id[dev], THIS_MODULE,
sizeof(struct snd_card_als100))) == NULL)
return -ENOMEM;
}
switch (id->driver_data) {
case ALS100_AUDIO:
---> snip
case ALS100_MPU:
---> snip
case ALS100_OPL:
---> snip
etc . . .
I'm interested in your opinions on this approach.
Thanks,
Adam
next prev parent reply other threads:[~2003-02-06 2:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0301271534210.2937-100000@pnote.perex-int.cz>
2003-01-29 22:12 ` [alsa, pnp] more on opl3sa2 (fwd) Adam Belay
2003-01-30 8:45 ` Jaroslav Kysela
2003-01-30 22:24 ` Adam Belay
2003-02-03 14:15 ` Jaroslav Kysela
2003-02-05 22:01 ` Adam Belay [this message]
2003-02-09 17:55 ` 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=20030205220132.GA10021@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.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 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.