[Xenomai-help] Interrupt only runs once

[Xenomai-help] Interrupt only runs once

[James Kilts]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

I'm porting Xenomai/I-pipe to the NS921x (an arm9-based) platform, but I'm
having problems getting the interrupts to re-enable after the first
interrupt triggers.

A kernel driver module is being used to test the interrupt latency using an
input GPIO pin which triggers a dedicated external IRQ, to which the ISR
responds by toggling a different GPIO pin.  I realize that there are test
applications which do very similar things, and that the RTDM skin is
preferable over the native API.  Still, I would like to understand why the
interrupt is not being properly acknowledged and reset.

If the ISR manually performs the ACK and EOI using platform specific calls,
subsequent interrupts are handled properly.  My understanding was that
Xenomai should re-enable the interrupt for processing without such
intervention.  How do I force Xenomai to clear and re-enable the interrupt
to handle subsequent interrupts?

Thanks,
James



static int __init turnaround_irq_measure_init(void)
{
    ....

    retval = rt_intr_create(&irq_response_desc,
"ns9xxx_measure_irq_rt_response",
                            TURNAROUND_INPUT_IRQ,
turnaround_irq_measure_response,
                            NULL, NULL);

    if (retval == 0)  // 0 is success
    {
        set_irq_type(TURNAROUND_INPUT_IRQ, IRQ_TYPE_EDGE_FALLING);
        retval = rt_intr_enable(&irq_response_desc);

        if (retval != 0)  // 0 is success
        {
            console_print("Turnaround test driver rt interrupt enable:
FAILED\n");
        }
    }
    else
    {
        console_print("Turnaround test driver rt interrupt create:
FAILED\n");
    }

    return 0;
}


static int turnaround_irq_measure_response(struct xnintr *intr)
{
    /* Set GPIO pin low */
    gpio_set_value(TURNAROUND_OUTPUT_GPIO, 0);

    /* Wait 50 microseconds */
    rt_timer_spin(50000);

    /* Set GPIO pin high */
    gpio_set_value(TURNAROUND_OUTPUT_GPIO, 1);

    /* Start listening again */
    /* NOTE:  These two lines should not be necessary */
    ns9xxx_ack_irq(TURNAROUND_INPUT_IRQ);
    ns9xxx_eoi_irq(TURNAROUND_INPUT_IRQ);

    return RT_INTR_HANDLED;
}

[-- Attachment #2: Type: text/html, Size: 2388 bytes --]

Re: [Xenomai-help] Interrupt only runs once

[Philippe Gerum]

On Tue, 2009-09-15 at 10:27 -0500, James Kilts wrote:
> I'm porting Xenomai/I-pipe to the NS921x (an arm9-based) platform, but
> I'm having problems getting the interrupts to re-enable after the
> first interrupt triggers.
> 
> A kernel driver module is being used to test the interrupt latency
> using an input GPIO pin which triggers a dedicated external IRQ, to
> which the ISR responds by toggling a different GPIO pin.  I realize
> that there are test applications which do very similar things, and
> that the RTDM skin is preferable over the native API.  Still, I would
> like to understand why the interrupt is not being properly
> acknowledged and reset.
> 
> If the ISR manually performs the ACK and EOI using platform specific
> calls, subsequent interrupts are handled properly.  My understanding
> was that Xenomai should re-enable the interrupt for processing without
> such intervention.  How do I force Xenomai to clear and re-enable the
> interrupt to handle subsequent interrupts?

It looks like an I-pipe issue, not a Xenomai one. Xenomai asks the
I-pipe to re-enable the interrupt line via the ipipe_end() handler, and
for some reason, that handler does not seem to do the right thing on
your board.

Which I-pipe patch are you using (kernel version and I-pipe release)?

> 
> Thanks,
> James
> 
> 
> 
> static int __init turnaround_irq_measure_init(void)
> {
>     ....
> 
>     retval = rt_intr_create(&irq_response_desc,
> "ns9xxx_measure_irq_rt_response",
>                             TURNAROUND_INPUT_IRQ,
> turnaround_irq_measure_response,
>                             NULL, NULL);
> 
>     if (retval == 0)  // 0 is success
>     {
>         set_irq_type(TURNAROUND_INPUT_IRQ, IRQ_TYPE_EDGE_FALLING);
>         retval = rt_intr_enable(&irq_response_desc);
> 
>         if (retval != 0)  // 0 is success
>         {
>             console_print("Turnaround test driver rt interrupt enable:
> FAILED\n");
>         }
>     }
>     else
>     {
>         console_print("Turnaround test driver rt interrupt create:
> FAILED\n");
>     }
> 
>     return 0;
> }
> 
> 
> static int turnaround_irq_measure_response(struct xnintr *intr)
> {
>     /* Set GPIO pin low */
>     gpio_set_value(TURNAROUND_OUTPUT_GPIO, 0);
> 
>     /* Wait 50 microseconds */
>     rt_timer_spin(50000);
> 
>     /* Set GPIO pin high */
>     gpio_set_value(TURNAROUND_OUTPUT_GPIO, 1);
> 
>     /* Start listening again */
>     /* NOTE:  These two lines should not be necessary */
>     ns9xxx_ack_irq(TURNAROUND_INPUT_IRQ);
>     ns9xxx_eoi_irq(TURNAROUND_INPUT_IRQ);
> 
>     return RT_INTR_HANDLED;
> }
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Interrupt only runs once

[James Kilts]

[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]

Philippe,

Indeed it was a problem with __set_irq_handler() not assigning appropriate
handlers, since this board doesn't fall into any of the existing handler
categories.

Thanks for your help.

James


On Wed, Sep 16, 2009 at 10:47 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On Tue, 2009-09-15 at 10:27 -0500, James Kilts wrote:
> > I'm porting Xenomai/I-pipe to the NS921x (an arm9-based) platform, but
> > I'm having problems getting the interrupts to re-enable after the
> > first interrupt triggers.
> >
> > A kernel driver module is being used to test the interrupt latency
> > using an input GPIO pin which triggers a dedicated external IRQ, to
> > which the ISR responds by toggling a different GPIO pin.  I realize
> > that there are test applications which do very similar things, and
> > that the RTDM skin is preferable over the native API.  Still, I would
> > like to understand why the interrupt is not being properly
> > acknowledged and reset.
> >
> > If the ISR manually performs the ACK and EOI using platform specific
> > calls, subsequent interrupts are handled properly.  My understanding
> > was that Xenomai should re-enable the interrupt for processing without
> > such intervention.  How do I force Xenomai to clear and re-enable the
> > interrupt to handle subsequent interrupts?
>
> It looks like an I-pipe issue, not a Xenomai one. Xenomai asks the
> I-pipe to re-enable the interrupt line via the ipipe_end() handler, and
> for some reason, that handler does not seem to do the right thing on
> your board.
>
> Which I-pipe patch are you using (kernel version and I-pipe release)?
>
> >
> > Thanks,
> > James
> >
> >
> >
> > static int __init turnaround_irq_measure_init(void)
> > {
> >     ....
> >
> >     retval = rt_intr_create(&irq_response_desc,
> > "ns9xxx_measure_irq_rt_response",
> >                             TURNAROUND_INPUT_IRQ,
> > turnaround_irq_measure_response,
> >                             NULL, NULL);
> >
> >     if (retval == 0)  // 0 is success
> >     {
> >         set_irq_type(TURNAROUND_INPUT_IRQ, IRQ_TYPE_EDGE_FALLING);
> >         retval = rt_intr_enable(&irq_response_desc);
> >
> >         if (retval != 0)  // 0 is success
> >         {
> >             console_print("Turnaround test driver rt interrupt enable:
> > FAILED\n");
> >         }
> >     }
> >     else
> >     {
> >         console_print("Turnaround test driver rt interrupt create:
> > FAILED\n");
> >     }
> >
> >     return 0;
> > }
> >
> >
> > static int turnaround_irq_measure_response(struct xnintr *intr)
> > {
> >     /* Set GPIO pin low */
> >     gpio_set_value(TURNAROUND_OUTPUT_GPIO, 0);
> >
> >     /* Wait 50 microseconds */
> >     rt_timer_spin(50000);
> >
> >     /* Set GPIO pin high */
> >     gpio_set_value(TURNAROUND_OUTPUT_GPIO, 1);
> >
> >     /* Start listening again */
> >     /* NOTE:  These two lines should not be necessary */
> >     ns9xxx_ack_irq(TURNAROUND_INPUT_IRQ);
> >     ns9xxx_eoi_irq(TURNAROUND_INPUT_IRQ);
> >
> >     return RT_INTR_HANDLED;
> > }
> >
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> --
> Philippe.
>
>
>

[-- Attachment #2: Type: text/html, Size: 4270 bytes --]

Re: [Xenomai-help] Interrupt only runs once

[Gilles Chanteperdrix]

James Kilts wrote:
> Philippe,
> 
> Indeed it was a problem with __set_irq_handler() not assigning appropriate
> handlers, since this board doesn't fall into any of the existing handler
> categories.

If your PIC needs an EOI, you can define the irq_finish macro in
include/mach/irqs.h like the AT91, and use the level handler. The I-pipe
should handled that, since it already does for AT91.

-- 
					    Gilles.

Re: [Xenomai-help] Interrupt only runs once

[Gilles Chanteperdrix]

James Kilts wrote:
> Philippe,
> 
> Indeed it was a problem with __set_irq_handler() not assigning appropriate
> handlers, since this board doesn't fall into any of the existing handler
> categories.

Ok. I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What
this irq handler does is bad, really bad. If you care about interrupt
latencies, you should really use handle_level_irq. That is, replace the
#if 0 with a #if 1.

This issue has already been discussed (in a slightly different form) on
both Xenomai and Linux-arm-kernel mailing lists.

By the way: do you plan to publish your patch?

-- 
					    Gilles.

Re: [Xenomai-help] Interrupt only runs once

[James Kilts]

> If your PIC needs an EOI, you can define the irq_finish macro in
> include/mach/irqs.h like the AT91, and use the level handler.

Thanks for the suggestion.  I'll give it a try when I have a moment.


> Ok. I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What
> this irq handler does is bad, really bad. If you care about interrupt
> latencies, you should really use handle_level_irq. That is, replace the
> #if 0 with a #if 1.

There is a newer version of handle_prio_irq() that is very similar to
handle_fasteoi_irq(), which is not checked into mainline Linux yet.
And yes, the old version is quite bad.

In any case, I thought handle_prio_irq should only be called when the
Linux domain is passed the interrupt by I-pipe.  Should I-pipe be
calling handle_prio_irq() or handle_level_irq() even when Linux is not
registered to receive the IRQ?


> By the way: do you plan to publish your patch?

It would be desirable to have the patch published, although our
current platform is Linux kernel version 2.6.28.9 with Xenomai 2.4.8
and may require some work to get working on the latest branch.


- James

Re: [Xenomai-help] Interrupt only runs once

[Gilles Chanteperdrix]

James Kilts wrote:
>> If your PIC needs an EOI, you can define the irq_finish macro in
>> include/mach/irqs.h like the AT91, and use the level handler.
> 
> Thanks for the suggestion.  I'll give it a try when I have a moment.
> 
> 
>> Ok. I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What
>> this irq handler does is bad, really bad. If you care about interrupt
>> latencies, you should really use handle_level_irq. That is, replace the
>> #if 0 with a #if 1.
> 
> There is a newer version of handle_prio_irq() that is very similar to
> handle_fasteoi_irq(), which is not checked into mainline Linux yet.
> And yes, the old version is quite bad.
> 
> In any case, I thought handle_prio_irq should only be called when the
> Linux domain is passed the interrupt by I-pipe.  Should I-pipe be
> calling handle_prio_irq() or handle_level_irq() even when Linux is not
> registered to receive the IRQ?

What happens is that the I-pipe acks and masks the irq in
__ipipe_handle_irq. And if it is a Linux interrupt, the Linux irq
handler is called so should not mask or ack the interrupt.

> 
> 
>> By the way: do you plan to publish your patch?
> 
> It would be desirable to have the patch published, although our
> current platform is Linux kernel version 2.6.28.9 with Xenomai 2.4.8
> and may require some work to get working on the latest branch.

Ok. Please be careful the I-pipe patch which comes with Xenomai 2.4.8
has a bug which we discovered with Xenomai 2.4.9, and was fixed with
2.4.9.1. So, you should really upgrade to 2.4.9.1. It should be
painless, since no ABI change ever take place in the same branch (2.4.x
for instance).

As for including your patch, we could include it starting with I-pipe
patch for Linux 2.6.28.

-- 
					    Gilles.

Re: [Xenomai-help] Interrupt only runs once

[James Kilts]

> you should really upgrade to 2.4.9.1.

I'm now running Xenomai 2.4.9.1 on Linux 2.6.28.9.


>>> I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What
>>> this irq handler does is bad, really bad. If you care about interrupt
>>> latencies, you should really use handle_level_irq. That is, replace the
>>> #if 0 with a #if 1.

Interrupt latency in the Linux kernel is not important to me, but
Xenomai interrupt latency is critical.  Just for the fun of it, I
tried switching to handle_level_irq() and then adding an irq_finish()
function similar to the AT91, but Linux locks up during the boot
sequence while initializing the Ethernet stack.  The timing of ACK/EOI
on this chip is sensitive.

Currently the problem is that a Xenomai ISR on this system needs to
respond to interrupts consistently under 50 microseconds.  When the
system is running idle or when running "dd if=/dev/zero of=/dev/zero",
it's able to respond to an IRQ trigger by toggling a GPIO within 35
microseconds.  But if I run "top" and then flood the serial input
buffer with carriage returns (holding down the enter key) the oscope
occasionally shows a large delay, in about 1 out of every 30 ISR calls
the GPIO toggles late on the order of 100-300 microseconds.  The
timing is worse when I flood the system with pings, upwards of 3
milliseconds to respond, although the majority remain under 35
microseconds.

These tests have been run using a LeCroy 1 GHz Oscilloscope.

I've been through the Troubleshooting and verified that all power
management, frequency modulation, etc. are disabled.  The serial port
driver does not appear to be masking the interrupts.  Any ideas as to
what could be causing these delays?


Thanks for your help.

- James

Re: [Xenomai-help] Interrupt only runs once

[Gilles Chanteperdrix]

James Kilts wrote:
>> you should really upgrade to 2.4.9.1.
> 
> I'm now running Xenomai 2.4.9.1 on Linux 2.6.28.9.
> 
> 
>>>> I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What
>>>> this irq handler does is bad, really bad. If you care about interrupt
>>>> latencies, you should really use handle_level_irq. That is, replace the
>>>> #if 0 with a #if 1.
> 
> Interrupt latency in the Linux kernel is not important to me, but
> Xenomai interrupt latency is critical.  Just for the fun of it, I
> tried switching to handle_level_irq() and then adding an irq_finish()
> function similar to the AT91, but Linux locks up during the boot
> sequence while initializing the Ethernet stack.  The timing of ACK/EOI
> on this chip is sensitive.

Using irq_finish was a bad advice, handle_level_irq should be ok.
Anyway, the point is that the interrupt handler which does the
acknowledge after the invocation of the ISR also delays the real-time
interrupts, which is why you should not use it.

> 
> Currently the problem is that a Xenomai ISR on this system needs to
> respond to interrupts consistently under 50 microseconds.  When the
> system is running idle or when running "dd if=/dev/zero of=/dev/zero",
> it's able to respond to an IRQ trigger by toggling a GPIO within 35
> microseconds.  But if I run "top" and then flood the serial input
> buffer with carriage returns (holding down the enter key) the oscope
> occasionally shows a large delay, in about 1 out of every 30 ISR calls
> the GPIO toggles late on the order of 100-300 microseconds.  The
> timing is worse when I flood the system with pings, upwards of 3
> milliseconds to respond, although the majority remain under 35
> microseconds.
> 
> These tests have been run using a LeCroy 1 GHz Oscilloscope.
> 
> I've been through the Troubleshooting and verified that all power
> management, frequency modulation, etc. are disabled.  The serial port
> driver does not appear to be masking the interrupts.  Any ideas as to
> what could be causing these delays?

To improve things, you should either enable FCSE in guaranteed mode, or
use Xenomai head, and enable unlocked context switches. What latency do
you get with the klatency test?

-- 
					    Gilles.