[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: interruption sequence
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? and accroding to your explaination,
does different PCI devices with same interrupt pin use
the same interrupt vector?
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?
Shanghai Bell Company, Shanghai, China
> From: Richard Walter[SMTP:firstname.lastname@example.org]
> Sent: Thursday, March 23, 2000 1:49 AM
> To: email@example.com; firstname.lastname@example.org
> Subject: RE: interruption sequence
> In addition to Ivan's answer (which I agree is correct), there is
> one other point that I think the original question was asking about:
> In general, PCI devices should IGNORE the interrupt acknowledge bus
> cycle. Interrupt Acknowledge is implicitly addressing the system
> controller, which 99.9% of the time is embedded in the chipset. All
> other PCI devices should ignore it. (To a certain extent, the INTACK
> is a case where x86 intrudes on the "architecture-independent" PCI bus.)
> Ivan's answer listed the software steps of interrupt servicing.
> From a hardware perspective, this is what happens:
> (Items in ()'s happen without your device being aware of them.)
> 1. Your device asserts INTx#.
> (2. The system interrupt controller notices that your INTx# is asserted
> and interrupts the CPU.)
> (3. The CPU issues a bus cycle to get the vector of the interrupt,
> generating an INTACK cycle on the PCI bus.)
> (4. The system interrupt controller responds to the INTACK cycle and
> returns vector information to the CPU. (All other PCI devices
> ignore the INTACK cycle.) )
> (5. Software executes the interrupt service routine which needs to check
> all devices that are potentially sharing this interrupt to see
> who wants service.)
> 6. Your driver will read a bit from your device that indicates that it
> is asserting INTx#. This bit can be located anywhere in your
> device's space; there is no PCI mandated location of this.
> (although it ought to be in a memory BAR and not config space.)
> 7. Your driver will service your device and then write control info back
> to the device indicating that it has serviced the interrupt.
> 8. Your device deasserts INTx#.
> -Richard Walter
> Note: I speak for myself, not for Auspex.
> > From email@example.com Wed Mar 22 05:24:03 2000
> > Hello Assato san,
> > I understand your question:
> > How does an interrupt get associated with a device?
> > The answer is as follows:
> > 1. The software handles the interrupt:
> > 2. The interrupt handling software must ask the possible devices if
> > they have an interrupt pending.
> > 3. If no device has an interrupt pending, then process an error or
> > ignore the interrupt.
> > 4. Else handle the device's request
> > 5. Continue polling possible interrupting devices
> > Note: If the interrupt is not properly programmed in the PCI
> > space, then it is possible to have an interrupt handling error (see #3
> > above).
> > I hope this answers your question.
> > Best regards,
> > Ivan
> > -----Original Message-----
> > From: ASATO [mailto:firstname.lastname@example.org]
> > Sent: Wednesday, March 22, 2000 2:46 AM
> > To: email@example.com
> > Subject: interruption sequence
> > Hi all
> > It is unsuitable for the contents. I have some question.
> > Although the CBE bus was decoded in order to terminate interruption of
> > device using the interrupt acknowledge, naturally the interruption
> signal to
> > other devices will also be inputted.
> > How has knowing that it is the interrupt acknowledge turned to itself
> > out of device?
> > Or, device had to decode such as an address or something?
> > Please give me some advices interruption sequence
> > ----------------------------------------
> > ASKA Electronic corporation
> > ASATO
> > mailto:firstname.lastname@example.org
> > ----------------------------------------