public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <ambx1@neo.rr.com>
To: Jaroslav Kysela <perex@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [alsa, pnp] more on opl3sa2
Date: Tue, 21 Jan 2003 18:23:03 +0000	[thread overview]
Message-ID: <20030121182303.GI26108@neo.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0301212223550.6355-100000@pnote.perex-int.cz>

On Tue, Jan 21, 2003 at 10:43:43PM +0100, Jaroslav Kysela wrote:
> On Tue, 21 Jan 2003, Adam Belay wrote:
> > 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.
>
> I see. I think it's a design problem then. The rule card -> one driver is
> bad. We need something between card and device which will take care about
> drivers. Unfortunately, this information is dynamic (only driver knows
> which devices have to be attached).
>
> I think that we need to discuss this thing very carefully.

I agree that we need to discuss this carefully and that there is a need for this
change.  Here are a few ideas to get a discussion started.

How does this sound...
1.) detach pnp card service matching from the driver model, the driver model is
what is imposing this one card per driver limit.
2.) create a special pnp_driver that handles cards and forwards driver model calls
to the pnp card services, we can use attach_driver to avoid matching problems.

design goals for these changes should be as follows:
1.) multiple drivers can bind to one card
2.) pnp_attach, pnp_detach, and pnp status should be phased out and replaced with
the special card driver, in other words the driver model can take care of this.

This will solve the one device limit but I'm not sure how to handle the pnpbios
stuff yet.  I want it to be with as little overhead as possible and would prefer we
don't use fake cards, any ideas?  All that comes to mind for me is a unique pnpbios
ID that the pnp layer will interpret and grant special exceptions.

>
> > 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.
>
> Yes, but IT SHOULD WORK. Although it isn't an most efficient way. (I
> personally think that it's better to keep as much IDs as possible to avoid
> clashes in future).

Hmm, I'm not sure what you mean by clashes in the future.  Nearly all of 
these isapnp devices are no longer manufactured, hence these devices will
not have many future changes.

Still I do see value in describing as many ids as possible but I worry that the
extra overhead may not be worth it.  This also needs to be further discussed.

Regards,
Adam

  reply	other threads:[~2003-01-21 23:11 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
2003-01-21 21:43       ` Jaroslav Kysela
2003-01-21 18:23         ` Adam Belay [this message]
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=20030121182303.GI26108@neo.rr.com \
    --to=ambx1@neo.rr.com \
    --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