BSP question: nested interrupts?

[Chris Nott]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140501/f9d530df/attachment.html>