[alsa-devel] [Fwd: Re: [Alsa-devel] [RFC][RFT] Adding support for Jazz16 based sound cards]
rene.herman at gmail.com
Tue Mar 20 17:33:56 CET 2007
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
Date: Mon, 19 Mar 2007 23:46:07 +0100
From: Rask Ingemann Lambertsen <rask at sygehus.dk>
To: Rene Herman <rene.herman at gmail.com>
CC: alsa-devel at lists.sourceforge.net, Adam Belay <ambx1 at neo.rr.com>
References: <20070311232436.GB9778 at sygehus.dk> <45FDDA0F.7050503 at 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.
> 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
$ 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
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.
Rask Ingemann Lambertsen
More information about the Alsa-devel