Smidctrl: Removing eithreshold and eidelivery CSRs #669
Conversation
mark-honman
left a comment
mark-honman
left a comment
There was a problem hiding this comment.
The analysis of the AIA spec issue #620 has opened up some more possibilities, so I'm not sure this is the best approach.
I don't care very much about eidelivery - AIA indicates it's more for de-featuring a sophisticated AIA system than anything else.
We do need to explore the possibility of keeping eithreshold instead of creating a new ithreshold CSR. Will write more on #620.
mark-honman
left a comment
mark-honman
left a comment
There was a problem hiding this comment.
Pretty much good to go, but ithreshold needs to go into smidctrl/ssidctrl
| Register {mithreshold} implements exactly IPRIOLEN bits. | ||
|
|
||
| In contrast to existing threshold mechanisms in AIA, | ||
| this CSR applies to major and minor interrupt identities. |
There was a problem hiding this comment.
Since eithreshold is not implemented, xithreshold should be included in sxidctrl, after xtopei?
There was a problem hiding this comment.
I did think about that. I am not aware of a good use case for thresholds without preemption.
Therefore, I believe it is fitting the preemption extension well.
Also if you wanted to use the preemption extension e.g. with an IMSIC, it would be good that this global threshold is in the preemption extension.
There was a problem hiding this comment.
AIA provides threholds but not preemption, so I hope there is a use-case!
But your point about emabling preemption with an IMSIC is valid - the preemption extension should not be tied to a specific interrupt controller.
mark-honman
left a comment
mark-honman
left a comment
There was a problem hiding this comment.
Thanks you for taking the time to thrash out the possibilities.
christian-herber-nxp
deleted the
620-clarify-interaction-of-xithreshold-and-interrupt-file-eithreshold
branch
No description provided.