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.