[alsa-devel] [Alsa-devel] [RFC][RFT] Adding support for Jazz16 based sound cards
rene.herman at gmail.com
Tue Mar 20 22:23:35 CET 2007
On 03/19/2007 11:46 PM, Rask Ingemann Lambertsen wrote:
>> 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.
There's also the "routed" bit though. I actually ran into this recently
when I was playing with snd-sgalaxy (which is why I'm harping on it).
An sgalaxy is also a (partly) software configurable card and when not
given explicit parameters the driver just searches for an unrequested
IRQ and DMA and then programs the card for it. Over here it grabbed IRQ
10 but then didn't work anyway, and only started working when I set IRQ
10 to "Legacy ISA" in the BIOS setup. It seems the IRQ simply was not
available to ISA without having done that (no, no PCI cards were using
IRQ 10 or anything).
I must say though that my comment above was partly based on a somewhat
foggy understanding of how things get assigned. Yes, _if_ this "routing"
problem I seemed to be experiencing is not a serious problem in practice
(Adam? Are you able to comment?) then the fact that the PnP layer will
be handing out the resources taking into account the other (known) cards
is indeed a practical advantage of using that layer.
> 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.
How does that help? On my systems (one AMI, all others Award BIOses) all
PCI cards get assigned their IRQ before the OS ever boots. That "PnP OS:
Yes/No" switch only effects whether or not the BIOS will fully configure
all ISA-PnP cards.
> 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:
Yes, this is an advantage. It does miss all the resources used by old
ISA cards for which no (normal or pnp protocol as in this one) drivers
have been loaded but I guess that's not much of a difference with a
regular ISA driver...
> 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.
I guess that could be an advantage.
When I was looking at pnp/isa integration a while ago myself I was
looking at it from the angle of generic old ISA (ie, hardwired non
settable resources) and concluded that for these there wasn't any point.
Having looked a little closer at the resource assigment being done in
the PnP layer now, I now feel there's some point, but still little for
But with software settable devices such as this Jazz16, there ofcourse
is rather more point. I believe the routing issue I refferred to above
is the most important thing to have answered.
I also still don't really like "splitting the one driver into the two
pieces" like that but well, we don't actually have all that many
software settable ISA devices and I guess it's not _too_ bad to have a
few of these "front-ends" run as a protocol driver at boot as long as it
stays "a few".
Hey, I already said I like the concept...
By the way; in the "straightforward version" I posted yesterday I
neglected to reserve the SB_JAZZ16_CONFIG_PORT and the SB range before
poking at it during setup. Attached version corrects that. Updated patch
including your SB changes still at
Looks more involved now, but posted mainly for completeness; correcting
yesterday's post. Has been tested and found working again.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Alsa-devel