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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox