[GSoC] OpenRISC port | ISR_Enable/Disable and isr_level

Hesham Moustafa heshamelmatary at gmail.com
Thu Jul 31 13:54:29 UTC 2014

Hi all,

I was trying to figure out where to increment ISR level related
variables. First, I wanna indicate that the current OpenRISC port only
has two level of interrupts: disable/enable. Given that, does this
mean that the maximum interrupt level is 1?

I noticed that there is some architectures have its own (static)
variable to contain isr_level, other RTEMS portable structures like
per_cpu structure has its own isr_level variable, and some have this
embedded in Context_Control. Maybe one of the previous variables are
just reading from an original one? If so, where it's? I assume it's
all read from one global/static variable which we can get directly
from a call to _CPU_ISR_Disable down to the architecture specific
function (at cpu.h?). If that's right, should _CPU_ISR_Disable (in
case of OpenRISC) just did the magic to disable interrupts in HW, and
always return 1 (or increment a static variable if interrupts are
already disable and do nothing in HW?)
_CPU_ISR_Enable in turn, should check on this level, decrements it,
and only do the HW magic to enable interrupts when level = 1? Please
correct me if I am getting this wrong.

Another question is, where/when should this variable be
incremented/decremented? Currently I did that from or1k/cpu.h from the
HW disable/enable interrupts function (which is called from
_ISR_[Disable|Enable]. Also, there are some architectures (like nios2)
increment/decrement it from the _ISR_Handler sometimes hard-coded in
assembly code. And of course, which variable exactly to be incremented
(the static one, the one at per_cpu and using macros for calculating
its address/offset, or where?)
I see also some high-level variable always incremented before every
call to _ISR_Enable, and decremented before _ISR_Disable.

Thanks in advance,

More information about the devel mailing list