BSP question: nested interrupts?

[Gedare Bloom]

On Fri, May 2, 2014 at 10:18 AM, Ben Gras <beng at shrike-systems.com> wrote:
> All,
>
> Based on the replies, my question wasn't phrased precisely enough - possibly
> by underestimating how different our contexts are that we're operating in.
> Wouldn't be the first time!
>
> What I was really asking was: does RTEMS expect from a BSP that interrupts
> will nest? Or doesn't it matter to the correct functioning of RTEMS? Or is
> it something more subtle like 'if interrupt set X is active, interrupt set Y
> must still be able to occur.'
>
> I gather it's (ideally?) the latter, where Y are based on the highest
> priority level in X. Which is fine for me, that's pretty close to the
> current state of the beagle code. I was having a hard time allowing X to
> occur (without infinite recursion) while X was still active. The active irq
> was probably masked implicitly in other BSPs I looked at.
>
Nested interrupts means the higher-priority interrupt can be serviced
while lower-priority interrupt is still active. It is quite hard
(impossible?) to service recursively the same interrupt source. You
need something like Linux split interrupt handling (top/bottom halves)
to do this well.

>
>
>
> On Thu, May 1, 2014 at 7:53 PM, Chris Nott <chrisn at vl.com.au> wrote:
>>
>> Ben,
>>
>> Just reviewing interrupts now. I'm not sure your question fully makes
>> sense. Unlike smaller embedded arms (eg. Cortex-M3), he interrupts on
>> Cortex-A8 are two-phase. There is an external (to the ARM core) interrupt
>> controller that feeds interrupts to the ARM IRQ and FIRQ lines. The ARM
>> process itself actually only has those two interrupt signals.
>>
>> It looks like the code currently handles IRQ and FIRQ serially, so any
>> interrupts at each level would be handled serially regardless of priority
>> set in the INTC. Presumably what we eventually want to do here for both IRQ
>> and FIRQ handlers is, receive the interrupt, immediately set the INTC
>> priority to the received interrupt level to block lower priority interrupts
>> (including the current interrupt), then acknowledge IRQ/FIRQ and dispatch
>> the actual interrupt handler at a lower CPU priority so we can nest IRQ/FIRQ
>> and handle higher priority interrupts.
>>
>> I'm not quite familiar with ARM family yet to be sure how this is normally
>> accomplished or if there is an existing supported ARM with the same
>> interrupt controller structure. TI provide sample source including interrupt
>> handler that supports this stuff. It might be a good place to start playing
>> with it, the source pretty much compiles fine in the RTEMS environment.
>>
>> Chris.
>>
>>
>>
>> On 28/04/2014 4:32 AM, Ben Gras wrote:
>>
>> Dear all,
>>
>> I have a question about managing interrupts in a BSP that I have not been
>> able to answer satisfactorily by looking at other BSP code, nor looking
>> throught the documentation or googling. Or asking on the IRC channel :)
>>
>> My question is: are BSPs expected to allow nested interrupts?
>> Specifically, must bsp_interrupt_dispatch() turn interrupts on before
>> calling bsp_interrupt_handler_dispatch for everything else to work properly?
>>
>> Some BSPs do this, some don't. In the Beagle BSP I can do this by masking
>> the currently active interrupt and then enabling them at the CPU level; but
>> enabling all interrupts before the hw-specific handler is called won't
>> deassert the irq at the peripheral so I'm having trouble seeing how that
>> should work.
>>
>> Example: if we are in a timer ISR and loop on polling the uptime ticks, do
>> we expect the ticks to be able to increase? I'm wondering if any of the
>> remaining failing tests are due to this. But also what the best shape of a
>> BSP is.
>>
>> Thanks!
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>