yes I think we could consider this
case as inadequate description of PICSR in architecture manual. In OR1200
RTL PICSR needs to be cleared in SW. Same is implemented in or1ksim.
However there is possibility that PICSR is not implemented, or perhaps entire
PIC is not implemented. In this case device driver would only have to clear
interrupt in the device itself and not in the PIC. So this needs to be fixed
somehow, either by better explanation in the manual or by a requirement that
PICSR always needs to be implemented (which in a way a like because it
simplifies things and in a way I don't like because it puts restrictions on HW
implementations)
There’s an
implementation-dependent aspect of this that worries me:
When acknowledging an
interrupt, only the PICSR bit corresponding to the interrupt needs to be
cleared. That requires reading the value PICSR, masking out one bit and
writing the result back to the PICSR. During that update process,
there’s a possible race condition because a different IRQ could be raised
after the PICSR is read but before it is written. If
interrupts are level-triggered, that’s not a problem because the PICSR will
reflect the OR of the written data and the asserted interrupt lines.
But, if interrupts are edge-triggered in a particular OR1K implementation, the
write to the PICSR would discard the new interrupt.
To me, that suggests
that the architecture needs a way to clear bits in the PICSR atomically.
For example, there could be a PIC “Acknowledgement Register” in which a 1-bit
written into any given position clears the corresponding bit in the
PICSR.
On a related note, I
have attached a one-character patch that I would like to check in to the
OR1200. It causes the low two bits of the PICMR register to always read
back as 1’s rather than always reading back as 0’s, since interrupt lines 0
and 1 are treated as unmasked.
-Scott