Hi everybody, I'm reviving this thread because we've found some more issues
related to the BBB bsp_interrupt_dispatch. I'm CCing Ben Gras since he may know
a bit more about this than we do.
On Thu, May 28, 2015 at 8:01 AM, Sebastian Huber <sebastian.huber at
embedded-brains.de> wrote:
> It depends on the capabilities of the interrupt controller. Maybe you have
> to drop the support for nested interrupts. The bsp_interrupt_dispatch()
> function for a state of the art interrupt controller looks like this
> (arm-gic-irq.c):
>
> void bsp_interrupt_dispatch(void)
> {
> volatile gic_cpuif *cpuif = GIC_CPUIF;
> uint32_t icciar = cpuif->icciar;
> rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
> rtems_vector_number spurious = 1023;
>
> if (vector != spurious) {
> uint32_t psr = _ARMV4_Status_irq_enable();
>
> bsp_interrupt_handler_dispatch(vector);
>
> _ARMV4_Status_restore(psr);
>
> cpuif->icceoir = icciar;
>
> }
> }
Is there a reason why the BBB bsp_interrupt_dispatch routine calls
bsp_interrupt_vector_disable bsp_interrupt_vector_enable instead of just doing
what Sebastian says? We've found that not only it doesn't work with the
interrupt server machinery, it also breaks the new GPIO API since
generic_bank_isr in gpio.c also calls bsp_interrupt_vector_disable/enable.
The only way we could make this work was by removing those calls in
generic_bank_isr. Removing them in bsp_interrupt_dispatch causes the entire
system to hang.
In fact, this is the only BSP we could find that does this. None of the others
call bsp_interrupt_vector_disable/enable inside their bsp_interrupt_dispatch.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
