Re: [alsa, pnp] more on opl3sa2 (fwd)

Re: [alsa, pnp] more on opl3sa2 (fwd)

[Adam Belay]

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

Re: [alsa, pnp] more on opl3sa2 (fwd)

[Jaroslav Kysela]

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 <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

Re: [alsa, pnp] more on opl3sa2 (fwd)

[Adam Belay]

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

Re: [alsa, pnp] more on opl3sa2 (fwd)

[Jaroslav Kysela]

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 <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

Re: [alsa, pnp] more on opl3sa2 (fwd)

[Adam Belay]

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

Re: [alsa, pnp] more on opl3sa2 (fwd)

[Jaroslav Kysela]

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 <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs