[alsa-devel] [Alsa-devel] [RFC][RFT] Adding support for Jazz16 based sound cards

[Rene Herman]

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 
those.

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

http://members.home.nl/rene.herman/jazz16.diff

Looks more involved now, but posted mainly for completeness; correcting 
yesterday's post. Has been tested and found working again.

Rene.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jazz16.diff
Url: http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070320/b47bd567/attachment-0001.bat