[GSoC] OpenRISC port | ISR_Enable/Disable and isr_level

[Joel Sherrill]

On 7/31/2014 9:31 AM, Hesham Moustafa wrote:
> 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?
Yes. The level returned is simply the value from the sr and is simply put
back in the sr to restore the previous level.

This nests nicely although we do not intend that it ever does.
>>> 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?
It is in the per cpu information structure.

If you do not have interrupt levels in hardware or a driver reenables
interrupts,
in practice, it will always be 0 when a task is executing and always 1
when in an ISR.

But that is not the general case. If interrupts are reenabled in the ISR
handler or
there are multiple IRQ sources and the CPU/PIC prioritizes them, then
nesting
IRQs is fairly routine.
>>> Thanks in advance,
>>> Hesham
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985