Porting ethernet driver from FREEBSD to rtems-libbsd

[Isaac Gutekunst]

That explains a lot and makes a lot of sense. I was thinking about only
disabling the entire interrupt controller.

Thanks!

Isaac

On Thu, May 28, 2015 at 8:34 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150528/13709865/attachment-0001.html>