BSP question: nested interrupts?

[Ben Gras]

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.




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 listrtems-devel at rtems.orghttp://www.rtems.org/mailman/listinfo/rtems-devel
>
>
>
> _______________________________________________
> 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/20140502/ddc57dcc/attachment-0001.html>