Messages in this thread | | | Subject | Re: 2.3 wish: integrate pcmcia into mainstream kernel | Date | Fri, 04 Jun 1999 09:24:38 BST | From | David Howells <> |
| |
I'll put forward my configuration manager _again_. It can do or can aid with a lot of what David Hinds wants to do, I think.
Also for Linus's requirements, the PnP bit can be removed and left as several implementations in just the half a dozen or so drivers that actually make use of it (Yuk!).
As for what David Hinds wants:
> > > "What irq is really free" > > > "What dma is really free" > > > "Give me some physical address space that isnt used" > > And "Give me some IO address space that isn't used" > > > > 1 & 2 you can kind of work around. #3 is a pain. Its also one that needs > > > to be addressed for the 3D work (AGP GART) and for some I2O devices. > > > > I agree that #2 and #3 is needed, although I disagree about it being a > > major pain.
#1 Can't be done as a query yet, but auto-configure with IRQ-share-flag not set can handle it. #2 Can't be done as a query yet, but auto-configure handles DMA channels exclusively anyway #3 Auto-configuration does this for memory space #4 Auto-configuration does this for IO space
> Support for ISA PnP hardware isn't the issue. What I need is support > for PnP BIOS calls: the calls to retrieve PCI interrupt routing > information and hardware resource tables, specifically.
Has support for PnP-BIOS, and adds appropriate device/bus definitions into the melting pot for this interface. (It also has ISA-PnP support).
> It doesn't work that way. I need to allocate an interrupt for PCMCIA: > how do I pick it?
The auto-configuration tool that comes with my configuration manager handles this - you tell it what IRQ's a device can use, and it does its best to find a configuration that doesn't conflict with any other drivers it knows about, subject to sharing constraints. The most suprising thing about this bit of code (in my opinion) is how little memory it actually takes.
> And IO ports? I try probing for "free" IO space, because again, the > resources known to the Linux kernel are too incomplete to be depended > on.
My configuration manager does the best it can... It can't do anything about devices and I/O port ranges it knows absolutely nothing about, but it can shuffle such ranges as it does know about around to get the best fit.
David Howells
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |