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.
Welcome to my world, Linus. These are MAJOR pains. Actually, for me,
since DMA over PCMCIA is so hopelessly broken as to be irrelevant, I
find that #1 is the biggest pain, followed by #4, followed by #3. On
#3, a 32-bit address space is big enough that if you just close your
eyes and hope for the best, things usually work out ok, sadly enough.
> It's just that nobody ever wrote anything I found acceptable
> (all the patches I ever saw thought they should re-create the broken MS
> documentation about PnP).
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.
> #1 should be a non-issue these days, and in fact works already (and ISA
> stuff should just use exclusive irq's, and then request_irq() will give
> you the information - and if you are sane and don't need exclusive
> interrupts the whole issue is moot anyway).
It doesn't work that way. I need to allocate an interrupt for PCMCIA:
how do I pick it? Currently, I try to probe each "free" interrupt, to
see if it is wired to the bridge. Some bridges don't support software
triggered interrupts, but most do. So, I exclude some irq's by hand,
because even if they appear free, they're probably committed to things
like serial and parallel ports. Sadly, the probe tends to hard-lock
some systems, I don't always know why. Probing an interrupt where the
PCI bridge is expecting pulse-mode, but the Cardbus bridge is sending
level-mode because I don't know any better, seems bad. Using PCI
interrupts for CardBus would be nice, but with PCI_INTERRUPT_LINE
always uninitialized for CardBus Bridges, I'm left with more probing.
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. Usually, the probe works well enough. Sometimes, reading from a
device will screw it up: this seems to be a common problem with sound
cards that have blocks of ports all over the place, some of which may
not be used or even known about by the sound drivers. Other times, a
range of ports reads back as all 0xff's, but if I try to put a PCMCIA
card there, the system wedges. Bummer.
-- Dave Hinds
-
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/