>
> I want to allocate an IRQ for a PCI device driver. Normally this is easy
> enough, since the BIOS would reserve it for me, then I would just have to
> bus_alloc_resource and not even care which IRQ line it's using.
This is how it works in -current.
> Thing is, here the BIOS hasn't allocated an IRQ, so I'll need to
> bus_set_resource in my probe to get one. To complicate matters, the
> device's interrupt generator is pretty flexible, and can generate an
> interrupt on (almost) any IRQ line. I have to tell it which IRQ to use
> when I know which one has been allocated.
Er, no, PCI interrupts don't work like that. A PCI device has four
interrupt pins (A-D) which are routed in an opaque fashion to up to four
different interrupt lines. You can (sometimes) tell the device which pin
to generate an interrupt on, but it will normally tell *you*.
> 1. Hardwire it, by using bus_set_resource with a specific IRQ. This isn't
> nice, as it'll fail if someone else's setup is already using the one I
> pick (or some other device attach will fail later on).
This is guarateed to fail most of the time.
> 2. Find out what IRQs are free and set and allocate one of those. This is
> nicer than 1), but then if some poor device attach later on in boot was
> expecting to use that IRQ, it'll break.
This is also guaranteed to fail most of the time, as it doesn't matter
which interrupts are "free" (you may actually be routed to an interrupt
that's already in use somewhere else).
> Does anyone know of a sensible & portable way around this? Perhaps IRQ
> sharing could save me in some way...
Look at the PCI interrupt routing code I committed to -current.
Backporting it to -stable should be pretty simple (it will get harder as
the code diverges more).
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message