I didn't see this one make the old list at all, so forward to the new one...

-------- Original Message -------- Subject: Re: [Alsa-devel] [RFC][RFT] Adding support for Jazz16 based sound cards Date: Mon, 19 Mar 2007 23:46:07 +0100 From: Rask Ingemann Lambertsen rask@sygehus.dk To: Rene Herman rene.herman@gmail.com CC: alsa-devel@lists.sourceforge.net, Adam Belay ambx1@neo.rr.com References: 20070311232436.GB9778@sygehus.dk 45FDDA0F.7050503@gmail.com

On Mon, Mar 19, 2007 at 01:32:15AM +0100, Rene Herman wrote:

I just now tested this on a standalone Jazz16 and it seems to be working fine for me. I once had ogg123 segfault on me at the end of playback but was unsuccesful in reproducing -- may have been a fluke.

Thanks. I'll try out ogg123.

As to the comments...

The changes to the SB code to support the Jazz16 I ofcourse agree with. Supporting a new card is great. I am however not a huge fan of the new PnP protocol. It's cute, but I feel it's a little over-engineered and could just as well live directly in snd-jazz16.

See below.

This setup also shares that same problem with the BIOS generally not having reserved/routed the resources -- on a general PCI/ISA system the user needs to go into the BIOS setup and reserve the resources the card is (or will be, in this case) set to. So now the user really needs to know what resources are going to be assigned, destroying the plug and play idea...

Not really. A standards compliant PnPBIOS set up with "PnP aware OS = YES" will use only enough resources to boot the system, which should leave enough irqs and dmas for the Linux PnP layer to do its work.

I think there are three good reasons to use the PnP layer:

1) The PnP layer informs the PCI layer of irqs to try to avoid - please see pnp_register_irq_resource() in drivers/pnp/resource.c. 2) The PnP layer knows which resources are used by active devices, even if they have not been allocated using e.g. request_region(). This happens in practice. For example:

$ cat /sys/bus/pnp/devices/01:02.00/resources state = active io 0x2a0-0x2af io 0x390-0x393 io 0x500-0x50f irq 5 dma 0 dma 1 $ cat /proc/ioports [...] 0200-0200 : ns558-pnp 0201-0201 : ns558-pnp 0208-020f : ns558-pnp 0213-0213 : ISAPnP 0280-028f : ES18xx 0356-0356 : ide2 0360-0361 : MPU401 UART 0376-0376 : 0000:00:07.1 0376-0376 : ide1 0390-0391 : OPL2/3 (left) 0392-0393 : OPL2/3 (right) 03c0-03df : vga+ 03e8-03ef : serial 03f6-03f6 : 0000:00:07.1 03f6-03f6 : ide0 03f8-03ff : serial 0500-050f : AD1816A 0800-0807 : ES18xx - CTRL [...]

Notice that 0x2a0-0x2af is missing from /proc/ioports. The PnP layer will avoid using that port range because it knows a device is using it. 3) Knowing which resources a card can utilize, the PnP layer can try to stay away from those resources when configuring other cards. The PnP layer doesn't do that yet in a stock kernel, but I've patched it to do so. I'll try to get those patches into the kernel.

An advantage of autoprobing in a PnP protocol driver (as opposed to doing so in a sound card driver) is that it happens before any file systems have been mounted, so if the autoprobe happens to find one of those #%!$@ NE2000 cards and lock up the system, it won't corrupt your disks.