Re: [openrisc] PIC documentation

[Scott Furman <sfurman@rosum.com>]

Title:

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