RE: interruption sequence

[Richard Walter <rwalter@corp.auspex.com>]

> From SVCRHT@sbell.com.cn Wed Mar 22 18:43:51 2000
> 
> Hi
>    There are still something confuse me. Since interrupt 
> controller is on the motherboard, Why does CPU gernerate 
> an INTACK cycle on the PCI bus to get the vector from 
> interrupt controller?

This comes from ye olde stone ages of PCI (circa 1994) when the
original PCI chipsets appeared.  As today, they were divided up
into a "north bridge" and a "south bridge" (although they we're
called that back then.)  Back then, most of these systems ran
DOS (around this time Intel was just introducing the dual-CPU capable
P54c's and APICs weren't integrated into the CPUs or chipsets.  You
actually needed separate external I/O APICs and Local APICs.) and the
PCI interrupts were just mapped onto ISA interrupts.  So, when
the x86 CPU issued an interrupt acknowledge cycle on the CPU bus,
that needed to somehow get to the interrupt controller to get
the vector and to let the interrupt controller know that the CPU
was entering interrupt state.  Therefore, an Interrupt Acknowledge
bus cycle for PCI to get the IntAck from north bridge to south bridge.
(To a certain extent, you can blame this on "PC-compatibility")

If you use the APIC (either for Multi-CPU operation or just because
APICs are cool...), then the interrupts and interrupt acknowledges
and some other stuff all flow across the APIC bus and you should not
see any interrupt acknowledge PCI cycles in that case. 

>                         and accroding to your explaination, 
> does different PCI devices with same interrupt pin use 
> the same interrupt vector? 

Well, that depends on what you mean by the same "interrupt pin".

If you're thinking of register 0x3D ("interrupt pin") in config
space, then the answer is no, different PCI devices with the same
interrupt pin setting in config space do not necessarily use the
same interrupt vector.  (Although they might.)

If you're thinking of pins A6, A7, B7, B8 ("INT[A,B,C,D]#") on the
PCI connector, then the answer is no, different PCI devices driving
the same gold-finger pin on the card do not necessarily use the
same interrupt vector.  (Although they might.)

If you're thinking of wires entering the interrupt controller (either
the old PC-style PIC or an APIC), then the answer is yes, different
PCI devices driving the same wires entering the interrupt controller
must use the same vector.

Essentially, a motherboard designer can connect the various PCI interrupt
signals (INTx# from all slots and on-board devices) to the interrupt
controller in any way she wants to.  The PCI configurator then uses
it's intimate knowledge of that layout, along with the interrupt pin
setting in config space, along with the interrupt routing across PCI
bridges in the PCI-to-PCI bridge spec, to determine which interrupts from
devices are connected to which wires entering the interrupt controller.
This determines the vector that that device will use and the configurator
will write a value back to the interrupt line (0x3C) in config space
to tell the driver which vector it is connected to.

For DOS compatability in the x86 world, this vector is assumed to be
an ISA-interrupt number that the PCI interrupt is mapped to.  However,
it is possible to have the wires going to the PIC different from the
wires going to the APIC, and so the PCI configurator also builds a table
in memory that a multi-processing aware OS can use to reconfigure the
devices if it wants to.

I hope that I havn't confused things further by this...

>    I have also another question. How does the Operation 
> System process the PCI interrupt? For example, in WindowsNT, 
> if you use DDK to develop a PCI device driver, it seemed 
> that windowsNT knows which PCI device has generated the 
> interrupt. so when you write the interrupt handler of a 
> PCI device. All the things you should do is just filling  
> some codes in the function. I am not quite sure about this, 
> but if it's true, then different PCI device drivers are 
> all independent. It is unnecessary to check the interrupt 
> source in the device driver since OS has find it out, but 
> how? could someone give me more detailed information?

I don't know how NT works in any detail, so I'm going to let someone
else answer these.

> Ren Hantao
> 2000/3/23
> 
> ======================================
> Shanghai Bell Company, Shanghai, China
> Email:svcrht@sbell.com.cn
> Tel:  86-21-58541240-3616
> Fax:  86-21-58541240-7450
> ======================================

-Richard Walter
rwalter@corp.auspex.com
Note: I speak for myself, not for Auspex