On Fri, May 2, 2014 at 10:18 AM, Ben Gras <b...@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 <chr...@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@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel >> >> >> >> _______________________________________________ >> rtems-devel mailing list >> rtems-devel@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel >> > > > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel