Smivt: Including minor interrupt identity in HW-vectoring scenarios

[christian-herber-nxp]

No description provided.

[mark-honman]

I may be missing something, but can't see the use-case for this - mtopei already provides this information for IMSIC and ACLIC.
Unless CSR accesses are very expensive, the cost of extracting minor ID from the modified mcause.exccode is not significantly different from reading mtopei. (our implementation has +1 cycle for the CSR read).

[christian-herber-nxp]

I may be missing something, but can't see the use-case for this - mtopei already provides this information for IMSIC and ACLIC. Unless CSR accesses are very expensive, the cost of extracting minor ID from the modified mcause.exccode is not significantly different from reading mtopei. (our implementation has +1 cycle for the CSR read).

It is not about the cost. It is about the atomicity. When you are in a vectored handler, you need the minor identity of the interrupt that triggered the handler. If you read the minor identity later (with interrupts still disabled), you can read the identity of a higher priority pending-enabled interrupt.

[mark-honman]

OK, got it!

That is certainly of value to SW; a typical use case is several peripherals of the same type - multiple interrupt table entries may point to the same interrupt handler SW, but that SW needs to know which peripheral to service.

[christian-herber-nxp]

OK, got it!

That is certainly of value to SW; a typical use case is several peripherals of the same type - multiple interrupt table entries may point to the same interrupt handler SW, but that SW needs to know which peripheral to service.

although your reply did lead me to the alternative: If reading topei after enabling interrupts, you will read your own identity. Does not seem to bad to me to be honest. It would have to be done before claiming the interrupt.