On Mon, Jan 27, 2003 at 03:36:41PM +0100, Jaroslav Kysela wrote:
>
> Any notes?
Actually I was wondering if you could provide some further information about the
nature of these multidevice sound cards so I can better understand the
situation.
1.) How are the componets of a typical card divided among the sub-devices. (ex:
control, mpu, wave table, etc)
2.) Are all the devices required for the card to properly function, in other
words, must the card always have possession of all of the sound related
sub-devices in order to function at a minimal level.
3.) Are there any other isapnp cards that depend on multiple devices per
driver, to my knowledge only a limited set of sound cards do.
Thanks,
Adam
On Wed, 29 Jan 2003, Adam Belay wrote:
> On Mon, Jan 27, 2003 at 03:36:41PM +0100, Jaroslav Kysela wrote:
> >
> > Any notes?
>
> Actually I was wondering if you could provide some further information about the
> nature of these multidevice sound cards so I can better understand the
> situation.
>
> 1.) How are the componets of a typical card divided among the sub-devices. (ex:
> control, mpu, wave table, etc)
There are these logical devices as you mentioned plus (optional) joystick
or IDE controler which the sound driver doesn't drive.
> 2.) Are all the devices required for the card to properly function, in other
> words, must the card always have possession of all of the sound related
> sub-devices in order to function at a minimal level.
No, but that's not the point. The sound driver must grab all devices to
follow hardware structure.
3.) Are there any other isapnp cards that depend on multiple devices per
driver, to my knowledge only a limited set of sound cards do.
Almost all isapnp soundcards. The opl3sa2 driver is an exception. Try to
grep for ISAPNP_DEVICE_ID in linux/sound/isa directory + subdirectories.
Anyway, as I said. The card is bus (PCI has something similar - PCI
bridges).
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
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
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
is a bad idea to represent the pnpbios as a card. When ACPI is introduced, both
pnpbios and ACPI will be cardless protocols. Therefore I think it is best to
use the pnp_driver structure instead of the pnpc_driver structure in the
opl3sa2 ALSA driver.
Any aditional comments?
Regards,
Adam
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
To allow grouping of card devices, we can use the driver_attach() function
from the probe() callback.
Also, the current pnp_protocol should be detached from the driver model.
I think that it's internal thing for the PnP device management.
> pnpbios and ACPI will be cardless protocols. Therefore I think it is best to
> use the pnp_driver structure instead of the pnpc_driver structure in the
> opl3sa2 ALSA driver.
The opl3sa2 driver is an exception. All others will require groups of
devices.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
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
On Wed, 5 Feb 2003, Adam Belay wrote:
> 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.
I'm sure that this model will work, but it's a bit complicated to
allocate devices in this way. I'd prefer to probe / allocate devices in
one shot. Anyway, it's a step forward. I'm thinking about this scenario:
Pass id list "match all" (or we can have a match callback in the
pnp_driver structure) and find/allocate multiple devices manually in
probe.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs