[Xenomai-help] PIOX irq problems with at91sam9260

[Xenomai-help] PIOX irq problems with at91sam9260

[Juan Antonio Garcia Redondo]

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

Hello list,

I'm testing xenomai 2.4.0 (kernel 2.6.20, adeos-ipipe-2.6.20-arm-1.8-02) 
over a at91sam9260 based board. The initial tests runs OK but I've problems 
with the PIOX interrupts. It seems that, to work properly with the
interrupt, I need to install first the interrupt on the linux side.

Environment:
	o A sligtly modified user_irq.c from the xenomai
	documentation.
	o A normal linux kernel module which does nothing except 
	catching the irq received as parameter.
	o PIB_11 y PIOB_10 in short circuit.
 

Test 1:
	o External gpio programming as input(PIOB_11)
	# test_irq 75
		Waiting for irq 75 ...
	
	o Nothing occurs although I've set and reset the PIOB_10. The
	first thing I see is that the PIOB_IMR is 0x000000 when I'll expect
	0x00000800.

Test 2:
	o External gpio programming as input(PIOB_11)
	# insmod irqena.ko gpio_in=75
	0 Now the PIOB_IMR is 0x00000800
	# rmmod irqena
	# test_irq 75
	    Waiting for irq 75
	o External gpio PIOB_10 set and reset.
	#  ..........
	   Waiting for irq 75
           Arrives irq -> 1
	   Arrives irq -> 1
	   ..................

I've attached the tests programs.

Any hints ?

Regards,
	Juan Antonio
	
	


[-- Attachment #2: test_irq.c --]
[-- Type: text/x-csrc, Size: 1304 bytes --]

#include <sys/mman.h>
#include <native/task.h>
#include <native/intr.h>

#define IRQ_NUMBER 89  /* Intercept interrupt #7 */
#define TASK_PRIO  99  /* Highest RT priority */
#define TASK_MODE  0   /* No flags */
#define TASK_STKSZ 0   /* Stack size (use default one) */

RT_INTR intr_desc;

RT_TASK server_desc;

static int irq_number = IRQ_NUMBER;

void irq_server (void *cookie)

{
    int ret;
    printf("Waiting for irq %d\n", irq_number);

    for (;;) {

       /* Wait for the next interrupt. */
       ret = rt_intr_wait(&intr_desc,TM_INFINITE);

       if (ret > 0) {
           /* Process interrupt. */
           printf("Arrives irq ->%d\n", ret);
       } else {
           printf("Error %d\n", ret);
       }
    }
}

int main (int argc, char *argv[])

{
    int err;

    if (argc > 1)
        irq_number = atoi(argv[1]);

    mlockall(MCL_CURRENT|MCL_FUTURE);

    err = rt_intr_create(&intr_desc,"MyIrq",irq_number,0);

    err = rt_task_create(&server_desc,
                         "MyIrqServer",
                         TASK_STKSZ,
                         TASK_PRIO,
                         TASK_MODE);
    if (!err)
        rt_task_start(&server_desc,&irq_server,NULL);

    pause();

}

void cleanup (void)

{
    rt_intr_delete(&intr_desc);
    rt_task_delete(&server_desc);
}


[-- Attachment #3: irqena.c --]
[-- Type: text/x-csrc, Size: 884 bytes --]

#include <linux/module.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/interrupt.h>
#include <asm/arch/gpio.h>

#define MODULE_NAME "irqena"

static uint gpio_in = 0;
static uint irq;

irqreturn_t
irqtest_irq_handler(int irq, void *dev_id)
{
        return IRQ_HANDLED;
}


static int __init irqtest_init(void)
{
        irq = irq_canonicalize(gpio_in);

        if (request_irq(irq,
                        irqtest_irq_handler, IRQF_DISABLED, MODULE_NAME, NULL))
        {
                printk(KERN_ERR "I can't use irq %d\n", irq);
                return -EINVAL;
        }
        return 0;
}

module_init(irqtest_init);

static void __exit irqtest_exit(void)
{
        free_irq(irq, NULL);
}
module_exit(irqtest_exit);

module_param(gpio_in, uint, 0444);
MODULE_PARM_DESC(gpio_in, "Input pin");


MODULE_DESCRIPTION("Irq Enable");
MODULE_LICENSE("GPL");

Re: [Xenomai-help] PIOX irq problems with at91sam9260

[Gilles Chanteperdrix]

On Dec 19, 2007 4:06 PM, Juan Antonio Garcia Redondo
<juan-antonio.garcia@domain.hid> wrote:
> Hello list,
>
> I'm testing xenomai 2.4.0 (kernel 2.6.20, adeos-ipipe-2.6.20-arm-1.8-02)
> over a at91sam9260 based board. The initial tests runs OK but I've problems
> with the PIOX interrupts. It seems that, to work properly with the
> interrupt, I need to install first the interrupt on the linux side.
>
> Environment:
>         o A sligtly modified user_irq.c from the xenomai
>         documentation.
>         o A normal linux kernel module which does nothing except
>         catching the irq received as parameter.
>         o PIB_11 y PIOB_10 in short circuit.
>
>
> Test 1:
>         o External gpio programming as input(PIOB_11)
>         # test_irq 75
>                 Waiting for irq 75 ...
>
>         o Nothing occurs although I've set and reset the PIOB_10. The
>         first thing I see is that the PIOB_IMR is 0x000000 when I'll expect
>         0x00000800.
>
> Test 2:
>         o External gpio programming as input(PIOB_11)
>         # insmod irqena.ko gpio_in=75
>         0 Now the PIOB_IMR is 0x00000800
>         # rmmod irqena
>         # test_irq 75
>             Waiting for irq 75
>         o External gpio PIOB_10 set and reset.
>         #  ..........
>            Waiting for irq 75
>            Arrives irq -> 1
>            Arrives irq -> 1
>            ..................
>
> I've attached the tests programs.
>
> Any hints ?

There is probably a difference (in term of the irq chip callbacks
called) between request_irq, used by the Linux driver, and
ipipe_virtualize_irq, used by Xenomai interrupts management routines.
The problem is to find this difference; at first sight, it is not
obvious

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] PIOX irq problems with at91sam9260

[Juan Antonio Garcia Redondo]

I've found a workaround for my problem, but I'm not sure if is the
correct solution.

First, my test program test_irq.c had an error, after request the irq,
it have be enabled; anyway the problem persists because the
__ipipe_mach_demux_irq find the irq disabled (gpio->depth = 1).

My workaround:
+++ wrappers.h	2007-12-21 08:19:19.000000000 +0100
@@ -74,8 +74,15 @@
 #define rthal_irq_chip_disable(irq)  ({
rthal_irq_descp(irq)->chip->disable(irq); 0; })
 #define rthal_irq_chip_end(irq)      ({
rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq)); 0; })
 typedef irq_handler_t rthal_irq_host_handler_t;
-#define rthal_mark_irq_disabled(irq) (rthal_irq_desc_status(irq) |=
IRQ_DISABLED)
-#define rthal_mark_irq_enabled(irq) (rthal_irq_desc_status(irq) &=
~IRQ_DISABLED)
+#define rthal_mark_irq_disabled(irq) do {              \
+            rthal_irq_desc_status(irq) |= IRQ_DISABLED; \
+            rthal_irq_descp(irq)->depth = 1;            \
+        } while(0);
+#define rthal_mark_irq_enabled(irq) do {                 \
+            rthal_irq_desc_status(irq) &= ~IRQ_DISABLED; \
+            rthal_irq_descp(irq)->depth = 0;             \
+        } while(0);
+#endif

Regards,
	Juan Antonio

Re: [Xenomai-help] PIOX irq problems with at91sam9260

[Gilles Chanteperdrix]

Juan Antonio Garcia Redondo wrote:
 > I've found a workaround for my problem, but I'm not sure if is the
 > correct solution.
 > 
 > First, my test program test_irq.c had an error, after request the irq,
 > it have be enabled; anyway the problem persists because the
 > __ipipe_mach_demux_irq find the irq disabled (gpio->depth = 1).

You should not have to enable irqs, this should be done automatically
when requesting the irq. Which irq did you have to enable, the gpio irq
? Or the multiplexed one ?

 > 
 > My workaround:
 > +++ wrappers.h	2007-12-21 08:19:19.000000000 +0100
 > @@ -74,8 +74,15 @@
 >  #define rthal_irq_chip_disable(irq)  ({
 > rthal_irq_descp(irq)->chip->disable(irq); 0; })
 >  #define rthal_irq_chip_end(irq)      ({
 > rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq)); 0; })
 >  typedef irq_handler_t rthal_irq_host_handler_t;
 > -#define rthal_mark_irq_disabled(irq) (rthal_irq_desc_status(irq) |=
 > IRQ_DISABLED)
 > -#define rthal_mark_irq_enabled(irq) (rthal_irq_desc_status(irq) &=
 > ~IRQ_DISABLED)
 > +#define rthal_mark_irq_disabled(irq) do {              \
 > +            rthal_irq_desc_status(irq) |= IRQ_DISABLED; \
 > +            rthal_irq_descp(irq)->depth = 1;            \
 > +        } while(0);
 > +#define rthal_mark_irq_enabled(irq) do {                 \
 > +            rthal_irq_desc_status(irq) &= ~IRQ_DISABLED; \
 > +            rthal_irq_descp(irq)->depth = 0;             \
 > +        } while(0);
 > +#endif

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] PIOX irq problems with at91sam9260

[Juan Antonio Garcia Redondo]

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

On 26/12/07 22:51, Gilles Chanteperdrix wrote:
> Juan Antonio Garcia Redondo wrote:
>  > I've found a workaround for my problem, but I'm not sure if is the
>  > correct solution.
>  > 
>  > First, my test program test_irq.c had an error, after request the irq,
>  > it have be enabled; anyway the problem persists because the
>  > __ipipe_mach_demux_irq find the irq disabled (gpio->depth = 1).
> 
> You should not have to enable irqs, this should be done automatically
> when requesting the irq. Which irq did you have to enable, the gpio irq
> ? Or the multiplexed one ?

I'm using the PIOB_11 as gpio and programming it as input before run the
test_irq.
I have to enable the irq by mean of rt_intr_enable, otherwise the
correspondent bit of IMR (Interrupt Mask Register) is disabled. Moreover
the rt_intr_create documentation says:

Note:
    	The interrupt source associated to the interrupt descriptor remains
	masked upon creation. rt_intr_enable() should be called for the new
	interrupt object to unmask it.

Anyway, I would like to know your opinion about my patch. As I said in
my previous mail, althought the irq is enabled, the correspondent
handler is not called because the __ipipe_mach_demux_irq function
(arch/arm/mach-at91rm9200/gpio.c) asks for the depth field of the struct irq_desc.

	if (isr & 1) {
		if (unlikely(gpio->depth)) {
			/*
			 * The core ARM interrupt
			 * handler lazily disables IRQs
			 * so
			 * another IRQ must be generated
			 * before it actually gets
			 * here to be disabled on the
			 * GPIO controller.
			 */
			gpio_irq_mask(pin);
			}
		else
			__ipipe_handle_irq(pin, regs);
		}

I've attached the patch again because the previous patch had an error.

Regards,
	Juan Antonio


[-- Attachment #2: patch_xenomai_wrappers.patch --]
[-- Type: text/x-diff, Size: 1137 bytes --]


#
# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
#

--- xenomai-2.4.0_cpu_siv_0C/include/asm-arm/wrappers.h~patch_xenomai_wrappers
+++ xenomai-2.4.0_cpu_siv_0C/include/asm-arm/wrappers.h
@@ -74,9 +74,14 @@
 #define rthal_irq_chip_disable(irq)  ({ rthal_irq_descp(irq)->chip->disable(irq); 0; })
 #define rthal_irq_chip_end(irq)      ({ rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq)); 0; })
 typedef irq_handler_t rthal_irq_host_handler_t;
-#define rthal_mark_irq_disabled(irq) (rthal_irq_desc_status(irq) |= IRQ_DISABLED)
-#define rthal_mark_irq_enabled(irq) (rthal_irq_desc_status(irq) &= ~IRQ_DISABLED)
-
+#define rthal_mark_irq_disabled(irq) do {              \
+            rthal_irq_desc_status(irq) |= IRQ_DISABLED; \
+            rthal_irq_descp(irq)->depth = 1;            \
+        } while(0);
+#define rthal_mark_irq_enabled(irq) do {                 \
+            rthal_irq_desc_status(irq) &= ~IRQ_DISABLED; \
+            rthal_irq_descp(irq)->depth = 0;             \
+        } while(0);
 static inline void fp_init(union fp_state *state)
 {
     /* FIXME: This is insufficient. */

Re: [Xenomai-help] PIOX irq problems with at91sam9260

[Gilles Chanteperdrix]

On Dec 28, 2007 9:29 AM, Juan Antonio Garcia Redondo
<juan-antonio.garcia@domain.hid> wrote:
> On 26/12/07 22:51, Gilles Chanteperdrix wrote:
> > Juan Antonio Garcia Redondo wrote:
> >  > I've found a workaround for my problem, but I'm not sure if is the
> >  > correct solution.
> >  >
> >  > First, my test program test_irq.c had an error, after request the irq,
> >  > it have be enabled; anyway the problem persists because the
> >  > __ipipe_mach_demux_irq find the irq disabled (gpio->depth = 1).
> >
> > You should not have to enable irqs, this should be done automatically
> > when requesting the irq. Which irq did you have to enable, the gpio irq
> > ? Or the multiplexed one ?
>
> I'm using the PIOB_11 as gpio and programming it as input before run the
> test_irq.
> I have to enable the irq by mean of rt_intr_enable,

You say "the irq", but there are really two irqs involved: the
multiplexed irq, and the decoded irq, which one are you talking about
?

> otherwise the
> correspondent bit of IMR (Interrupt Mask Register) is disabled. Moreover
> the rt_intr_create documentation says:
>
> Note:
>         The interrupt source associated to the interrupt descriptor remains
>         masked upon creation. rt_intr_enable() should be called for the new
>         interrupt object to unmask it.

It seems that when requesting an interrupt with the RTDM skin, it is
not necessary to enable it, but it is still necessary with the native
skin.

>
> Anyway, I would like to know your opinion about my patch. As I said in
> my previous mail, althought the irq is enabled, the correspondent
> handler is not called because the __ipipe_mach_demux_irq function
> (arch/arm/mach-at91rm9200/gpio.c) asks for the depth field of the struct irq_desc.
>
>         if (isr & 1) {
>                 if (unlikely(gpio->depth)) {
>                         /*
>                          * The core ARM interrupt
>                          * handler lazily disables IRQs
>                          * so
>                          * another IRQ must be generated
>                          * before it actually gets
>                          * here to be disabled on the
>                          * GPIO controller.
>                          */
>                         gpio_irq_mask(pin);
>                         }
>                 else
>                         __ipipe_handle_irq(pin, regs);
>                 }
>
> I've attached the patch again because the previous patch had an error.

I will look at your patch.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] PIOX irq problems with at91sam9260

[Juan Antonio Garcia Redondo]

On 28/12/07 11:02, Gilles Chanteperdrix wrote:
> On Dec 28, 2007 9:29 AM, Juan Antonio Garcia Redondo
> <juan-antonio.garcia@domain.hid> wrote:
> > On 26/12/07 22:51, Gilles Chanteperdrix wrote:
> > > Juan Antonio Garcia Redondo wrote:
> > >  > I've found a workaround for my problem, but I'm not sure if is the
> > >  > correct solution.
> > >  >
> > >  > First, my test program test_irq.c had an error, after request the irq,
> > >  > it have be enabled; anyway the problem persists because the
> > >  > __ipipe_mach_demux_irq find the irq disabled (gpio->depth = 1).
> > >
> > > You should not have to enable irqs, this should be done automatically
> > > when requesting the irq. Which irq did you have to enable, the gpio irq
> > > ? Or the multiplexed one ?
> >
> > I'm using the PIOB_11 as gpio and programming it as input before run the
> > test_irq.
> > I have to enable the irq by mean of rt_intr_enable,
> 
> You say "the irq", but there are really two irqs involved: the
> multiplexed irq, and the decoded irq, which one are you talking about
> ?
OK, when I say "the irq" I'm talking about the irq number associated to
the gpio, not the irq associated to the port. That's to say, from linux side:

	request_irq(75, testlat_irq_handler, IRQF_DISABLED, "testlat", &testlat);

>From xenomai side:
    	rt_intr_create(&intr_desc,"MyIrq",75,0);
    	rt_intr_enable(&intr_desc);

The 75 number comes from AT91_PIN_PB11 = NR_AIC_IRQS(32) + 0x20(Port B) + 11


> > otherwise the
> > correspondent bit of IMR (Interrupt Mask Register) is disabled. Moreover
> > the rt_intr_create documentation says:
> >
> > Note:
> >         The interrupt source associated to the interrupt descriptor remains
> >         masked upon creation. rt_intr_enable() should be called for the new
> >         interrupt object to unmask it.
> 
> It seems that when requesting an interrupt with the RTDM skin, it is
> not necessary to enable it, but it is still necessary with the native
> skin.
> 
> >
> > Anyway, I would like to know your opinion about my patch. As I said in
> > my previous mail, althought the irq is enabled, the correspondent
> > handler is not called because the __ipipe_mach_demux_irq function
> > (arch/arm/mach-at91rm9200/gpio.c) asks for the depth field of the struct irq_desc.
> >
> >         if (isr & 1) {
> >                 if (unlikely(gpio->depth)) {
> >                         /*
> >                          * The core ARM interrupt
> >                          * handler lazily disables IRQs
> >                          * so
> >                          * another IRQ must be generated
> >                          * before it actually gets
> >                          * here to be disabled on the
> >                          * GPIO controller.
> >                          */
> >                         gpio_irq_mask(pin);
> >                         }
> >                 else
> >                         __ipipe_handle_irq(pin, regs);
> >                 }
> >
> > I've attached the patch again because the previous patch had an error.
> 
> I will look at your patch.
> 

Regards,
	Juan Antonio

Re: [Xenomai-help] PIOX irq problems with at91sam9260

[Gilles Chanteperdrix]

Juan Antonio Garcia Redondo wrote:
 > On 26/12/07 22:51, Gilles Chanteperdrix wrote:
 > > Juan Antonio Garcia Redondo wrote:
 > >  > I've found a workaround for my problem, but I'm not sure if is the
 > >  > correct solution.
 > >  > 
 > >  > First, my test program test_irq.c had an error, after request the irq,
 > >  > it have be enabled; anyway the problem persists because the
 > >  > __ipipe_mach_demux_irq find the irq disabled (gpio->depth = 1).
 > > 
 > > You should not have to enable irqs, this should be done automatically
 > > when requesting the irq. Which irq did you have to enable, the gpio irq
 > > ? Or the multiplexed one ?
 > 
 > I'm using the PIOB_11 as gpio and programming it as input before run the
 > test_irq.
 > I have to enable the irq by mean of rt_intr_enable, otherwise the
 > correspondent bit of IMR (Interrupt Mask Register) is disabled. Moreover
 > the rt_intr_create documentation says:
 > 
 > Note:
 >     	The interrupt source associated to the interrupt descriptor remains
 > 	masked upon creation. rt_intr_enable() should be called for the new
 > 	interrupt object to unmask it.
 > 
 > Anyway, I would like to know your opinion about my patch. As I said in
 > my previous mail, althought the irq is enabled, the correspondent
 > handler is not called because the __ipipe_mach_demux_irq function
 > (arch/arm/mach-at91rm9200/gpio.c) asks for the depth field of the struct irq_desc.

I merged this patch in the v2.3.x, v2.4.x branches and trunk. I think
however that it is the I-pipe patch that should be fixed to avoid using
the "depth" member: Xenomai does not disable lazily the interrupt so
the mechanism looking at "depth" in __ipipe_mach_demux_irq could be
removed. However, if we want xenomai to run with older revisions of the
I-pipe patch, we need your patch.

-- 


					    Gilles Chanteperdrix.