Beaglebone Black interrupt dispatch (was: Porting ethernet driver from FREEBSD to rtems-libbsd)

[Martin Galvan]

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.