[GSoC] OpenRISC port | ISR_Enable/Disable and isr_level

Hesham Moustafa heshamelmatary at gmail.com
Thu Jul 31 14:31:16 UTC 2014

On Thu, Jul 31, 2014 at 4:17 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> On July 31, 2014 8:54:29 AM CDT, Hesham Moustafa <heshamelmatary at gmail.com> wrote:
>>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.
> ISR disable and enable should not need to touch any global data or per thread/CPU data. They disable maskable interrupts at the CPU level. This usually involves a single special status register. Return the value of this register before disable to the caller. That value is passed to enable and flash.
So, for or1k port, should or1k_interrupt_disable (at cpu.h) just
return the value of sr (supervision/status register) before I do
disable interrupts in HW?

>>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.
> I think you have confused isr disable level and isr nest level. Nest level is part of the asm code for irqs.
Now I know that isr_disable_level should hold the content of the sr
register (before disabling interrupts in HW) to be used when calling
_ISR_Enable again.
So, where is isr_nest_level should be defined and touched (in
_ISR_Handler)? And for or1k, should this hold maximum value of 1 at a
given time?
>>Thanks in advance,
>>devel mailing list
>>devel at rtems.org
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the devel mailing list