|
Scott,
do you have a suggestion how to keep OR1200 as it
is and make definition of PIC broader to fit also the edge triggered interrupt
scheme?
regards,
Damjan
----- Original Message -----
Sent: Thursday, February 20, 2003 5:29
PM
Subject: Re: [openrisc] PIC
documentation
Damjan Lampret wrote:
software sould clear PICSR after it cleared
device's interrupt request register. So if there is new interrupt from a
device, it will automatically set the bit in PICSR
again. My point is that the *architectural*
description of the PIC is tied to its current *implementation*, the OR1200.
If another implementation ever arises in which the peripherals deliver
an edge-triggered interrupt signal to the PIC rather than a level-triggered
interrupt, then software can not safely clear the PICSR due to the race
condition I mentioned in my last message, i.e. without risking dropping an
interrupt from a different device than the one being serviced. I believe
that it is for this reason every interrupt controller I have ever seen (other
than the OR1k PIC) provides a means to *atomically* mask out a particular
pending interrupt without affecting other pending interrupts.
If the
PIC becomes a mandatory part of the OR1k architecture, then the specification
probably ought to make it clear that it is only suitable for use with
level-sensitive interrupts and that an external interrupt controller is
necessary to employ edge-triggered interrupts. IMHO, the PIC in its
current form is not sufficiently general compared to typical interrupt
controllers to require it as a mandatory part of the or1k
architecture.
The main point of PICSR is to connect several
devices to a single interrupt request of the OR1200 and the software can see
which device tree asserted an interrupt and only look in that device
tree for the device that asserted interrupt.
I don't think there's any misunderstanding on
the purpose of the PIC.
-Scott
|