Porting ethernet driver from FREEBSD to rtems-libbsd

[Sebastian Huber]

This interrupt server task is a hack. It works for proper interrupt 
controllers. You must be able to disable a single interrupt source in 
the interrupt controller.

On 28/05/15 14:23, Isaac Gutekunst wrote:
> I'm going to chime in since this sounds like a similar problem I've 
> experienced on a PIC32.
>
> I wanted to reword what Ragunath said in my own words to see if I 
> understand it.
>
> 1) The RX ISR fires, vectoring the code to the ISR entry.
> 2) The code in the ISR disables interrupts, creates an event to be 
> handled by RTEMS (in a non interrupt context)
> 3) At some point (dispatch function), interrupts are enabled
> 4) Since the RTEMS task responsible for performing non-generic 
> handling hasn't run, the hardware condition that created the initial 
> interrupt has not been cleared. Therefore, the interrupt controller 
> vectors to the ISR entry again, repeating the cycle.

Yes, this is how it works on the beagle BSP.  With the ARM GIC it works 
like this:

1) The RX ISR fires, vectoring the code to the ISR entry.
2) The code in the ISR disables exactly this interrupt source, creates 
an event to be handled by RTEMS (in a non interrupt context)
3) The interrupt server thread eventually calls the real ISR routine 
which clears the interrupt condition.
4) The interrupt server thread enables exactly this interrupt source.

>
>
> In this case, the fundamental problem is that an ISR will continue 
> firing until the condition causing it is resolved. In the case of an 
> RX interrupt, that usually would mean reading data from a SFR or 
> buffer. I'm not familiar with this specific case, but it sounds 
> awfully similar.
>
> Does this sound right?
>
> If so, it seems like a rather fundamental problem I haven't been able 
> to resolve. I'm hoping someone has found a reasonable solution that I 
> wasn't smart enough to figure out my self.
>
> Isaac
>
> On Thu, May 28, 2015 at 8:01 AM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto: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;
>
>       }
>     }
>
>     On 28/05/15 13:50, ragu nath wrote:
>
>         Hi Sebastian,
>
>         The problem is with rx interrupt. We are enabling rx interrupt
>         before
>         it is processed. The rtems server task do not get an
>         opportunity to
>         run.
>
>         I found this might be the logical explanation of the issue.
>         bsp_interrupt_dispatch() calls bsp_interrupt_server_trigger which
>         disables the rx interrupt and creates BSP_INTERRUPT_EVENT . 
>         For this
>         event, bsp_interrupt_server_task() was supposed to call the actual
>         interrupt handler and then enable the rx interrupt. But before the
>         event is processed, we enable the rx interrupt in dispatch
>         function.
>         So again rx interrupt is generated and event is created and
>         the cycle
>         goes on. Server task is never executed in turn actual interrupt
>         handler is never executed.
>
>         Since we enable the interrupt, it occurs again and again as we
>         never handle it.
>
>         Is there any other possibility that I might need to look into?
>
>
>         Thanks,
>         Ragunath
>
>         On Thu, May 28, 2015 at 4:58 PM, Sebastian Huber
>         <sebastian.huber at embedded-brains.de
>         <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>             Hello,
>
>             the bsp_interrupt_dispatch() is quite complicated in the
>             beagle BSP. Is the
>             interrupt controller of this chip really that broken? Sane
>             interrupt
>             controllers block interrupts of equal or lower priority
>             relative to the
>             currently pending interrupt.
>
>
>     -- 
>     Sebastian Huber, embedded brains GmbH
>
>     Address : Dornierstr. 4, D-82178 Puchheim, Germany
>     Phone   : +49 89 189 47 41-16 <tel:%2B49%2089%20189%2047%2041-16>
>     Fax     : +49 89 189 47 41-09 <tel:%2B49%2089%20189%2047%2041-09>
>     E-Mail  : sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     PGP     : Public key available on request.
>
>     Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>     _______________________________________________
>     devel mailing list
>     devel at rtems.org <mailto:devel at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
>
>

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.