Tim Kelly wrote:
> Hi Michael,
> 
> 
>>Hmm, in my naivity I'd think that assigning different virqs to PCI devices
>>sharing the same IRQ ( be it >through a bridge or different functions of
>>the same device, like many USB controllers ) isn't a bad thing - >this
>>could hide the sharing from the drivers - well, as long as the kernel can
>>figure out where the IRQ >really came from. Can it do that with a PCI
>>bridge? I mean - is there a register in the bridge to indicate >which
>>slots fired IRQs?
> 
> 
> I would think pretty much the same thing, in that the virq mechanism helps
> make the interrupt masking process easier. It does run into problems when
> there are more than 28 hardware irqs, though, since the virq value is just
> 32 bits. I think this is where the none/edge/level/pulse stuff in
> intr_establish is supposed to encode a difference, but I don't see on the
> backend there's decoding to differentiate.

There are 64 possible hardware irqs (ICU_LEN), the virq mechanism is nothing
more than a renumbering of the hardware irq numbers into a smaller range
that allows a single int to be used to hold a bitfield of masked or pending
interrupts.  The virqs are dynamically allocated in mapirq(), if devices
share a hardware irq they will correctly map to the same virq.

Hardware interrupt lines may only be shared by devices which use compatible
edge/level/pulse signaling.  Attempts to intr_establish() a hardware irq as
two different types can't be done (currenly results in a kernel panic).


> Isn't the bridge responsible for tracking which devices are behind it and
> what they do, based on the PCI tag?
> 
> 
>>So I guess everything on the USB card ( 3xOHCI, 1x EHCI ) should share the
>>same virq, but the audio card >should get a different one.
> 
> 
> It seems to me that devices with different IPL levels shouldn't share
> virqs, too.

The levels blocked by intr_calcmasks() is the union of the IPL levels of
all devices sharing the IRQ.  Sharing an IRQ between an audio and a USB
device would be particularly bad: USB is supposed to be at a low priority
(IPL_USB == IPL_BIO), but this device gets elevated to IPL_AUDIO.  Even
worse, any code running at IPL_BIO would block the shared IRQ, so the audio
interrupt will experience high latency.

-Neil