[Xenomai] GPIO Interrupts problem with RTDM

[Xenomai] GPIO Interrupts problem with RTDM

[Pierre LE COZ]

Hi all,

I have simple program to manage the GPIO of my raspberry Pi using RTDM.

I use :
"rtdm_irq_request(& irq_exemple, num_irq, exemple_handler,
RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE, "MyProgram", NULL);"
in order to detect interrupts.

After repeated presses on a pushbutton linking my input GPIO to 3,3v, I run
:
# cat /proc/xenomai/irq
IRQ CPU0
3: 1134 [timer]
108: 0 MyProgram
259: 0 [virtual]

No interrupt is taken into account.

Please, does anyone can help?




PS : Without Xenomai, I can detect interrupts with the same set-up :

# cat /proc/interrupts
CPU0
3: 14053 ARMCTRL BCM2708 Timer Tick
52: 10 ARMCTRL BCM2708 GPIO catchall handler
65: 6 ARMCTRL ARM Mailbox IRQ
66: 0 ARMCTRL VCHIQ doorbell
75: 7942676 ARMCTRL dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
77: 148 ARMCTRL bcm2708_sdhci (dma)
83: 452 ARMCTRL uart-pl011
84: 1297 ARMCTRL mmc0
108: 10 GPIO MyProgram
Err: 0

To do so I use "request_irq(gpio_to_irq(RPI_GPIO_IN), rpi_gpio_2_handler,
IRQF_SHARED | IRQF_TRIGGER_RISING, THIS_MODULE->name, THIS_MODULE->name);"

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/18/2013 04:15 PM, Pierre LE COZ wrote:

> Hi all,
> 
> I have simple program to manage the GPIO of my raspberry Pi using RTDM.
> 
> I use :
> "rtdm_irq_request(& irq_exemple, num_irq, exemple_handler,
> RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE, "MyProgram", NULL);"
> in order to detect interrupts.
> 
> After repeated presses on a pushbutton linking my input GPIO to 3,3v, I run
> :
> # cat /proc/xenomai/irq
> IRQ CPU0
> 3: 1134 [timer]
> 108: 0 MyProgram
> 259: 0 [virtual]
> 
> No interrupt is taken into account.
> 
> Please, does anyone can help?


The Raspberry PI code is not part of the I-pipe kernel maintained by 
the Xenomai project, so, basically, what it does is not really under 
the control of this list. However, I would bet you are missing the GPIO 
demuxing:

http://xenomai.org/index.php/I-pipe-core:ArmPorting#GPIOs_as_interrupt_sources

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Friday 18 January 2013, Pierre LE COZ wrote:
> I have simple program to manage the GPIO of my raspberry Pi using
> RTDM.
>
> I use :
> "rtdm_irq_request(& irq_exemple, num_irq, exemple_handler,
> RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE, "MyProgram", NULL);"
> in order to detect interrupts.

rtdm_irq_request does not explicitly enable the interrupts on a gpio pin 
with ian_cim's patch - This could probably be done, but I don't have 
the time for it. In the meantime, in kernel space, use the following 
calls in conjunction with rtdm_irq_request:

        // To enable an interrupt.
        gpio_request_one(gpio_pin, GPIOF_DIR_IN, "module name");
        irq_number = gpio_to_irq(gpio_pin);
        irq_set_irq_type(irq_number,  IRQF_TRIGGER_RISING);
        enable_irq(irq_number);


        // To disable an interrupt and clean up.
        disable_irq(irq_number);
        free_irq(irq_number, NULL);
        gpio_free(gpio_pin);

In user space, I'd suggest looking at the source code for Mike 
McCauley's bcm2835 library <http://www.open.com.au/mikem/bcm2835/>

> After repeated presses on a pushbutton linking my input GPIO to 3,3v,
> I run
>
> # cat /proc/xenomai/irq
> IRQ CPU0
> 3: 1134 [timer]
> 108: 0 MyProgram
> 259: 0 [virtual]
>
> No interrupt is taken into account.

As Gilles has already pointed out, you are missing a call to 
ipipe_handle_demuxed_irq() - See attached patch.


Regards, Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bcm2708_gpio.diff
Type: text/x-diff
Size: 605 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130118/331ef7d4/attachment.diff>

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Pierre LE COZ]

Thank you Gilles and Paul for your quick reply and your help !

I've checked my bcm2708_gpio.c, and in fact, the call to
ipipe_handle_demuxed_Igor() misses.


> In the meantime, in kernel space, use the following
> calls in conjunction with rtdm_irq_request:
>
>         // To enable an interrupt.
>         gpio_request_one(gpio_pin, GPIOF_DIR_IN, "module name");
>         irq_number = gpio_to_irq(gpio_pin);
>         irq_set_irq_type(irq_number,  IRQF_TRIGGER_RISING);
>         enable_irq(irq_number);
>
>
>         // To disable an interrupt and clean up.
>         disable_irq(irq_number);
>         free_irq(irq_number, NULL);
>         gpio_free(gpio_pin);
>

I tried it. Here is my code :

        rtdm_irq_request(& irq_exemple, num_irq, exemple_handler,
RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE,THIS_MODULE->name, NULL);

         gpio_request_one(GPIO_IN, GPIOF_DIR_IN, THIS_MODULE->name);
        irq_set_irq_type(num_irq,  IRQF_TRIGGER_RISING);
        enable_irq(num_irq);

        return 0;
}

But here is what I get :

# insmod rpi-rtdm.ko
------------[ cut here ]------------
WARNING: at kernel/irq/manage.c:421 enable_irq+0x50/0x6c()
Unbalanced enable for IRQ 108
Modules linked in: rpi_rtdm(O+)
[<c00136bc>] (unwind_backtrace+0x0/0xe4) from [<c0021c6c>]
(warn_slowpath_common+0x4c/0x64)
[<c0021c6c>] (warn_slowpath_common+0x4c/0x64) from [<c0021d04>]
(warn_slowpath_fmt+0x2c/0x3c)
[<c0021d04>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0060c50>]
(enable_irq+0x50/0x6c)
[<c0060c50>] (enable_irq+0x50/0x6c) from [<bf0020a8>]
(exemple_init+0xa8/0xbc [rpi_rtdm])
[<bf0020a8>] (exemple_init+0xa8/0xbc [rpi_rtdm]) from [<c00086a8>]
(do_one_initcall+0x9c/0x17c)
[<c00086a8>] (do_one_initcall+0x9c/0x17c) from [<c0051a5c>]
(sys_init_module+0x1658/0x1830)
[<c0051a5c>] (sys_init_module+0x1658/0x1830) from [<c000dbe0>]
(ret_fast_syscall+0x0/0x30)
---[ end trace 6358198229f2f036 ]---

So do I need to rebuild my entire system after patching my bcm2708_gpio.c ?

Or, I am doing something wrong with the lines of code that Paul gave me?

Pierre

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Friday 18 January 2013, Pierre LE COZ wrote:
> Thank you Gilles and Paul for your quick reply and your help !
>
> I've checked my bcm2708_gpio.c, and in fact, the call to
> ipipe_handle_demuxed_Igor() misses.
>
> > In the meantime, in kernel space, use the following
> > calls in conjunction with rtdm_irq_request:
> >
> >         // To enable an interrupt.
> >         gpio_request_one(gpio_pin, GPIOF_DIR_IN, "module name");
> >         irq_number = gpio_to_irq(gpio_pin);
> >         irq_set_irq_type(irq_number,  IRQF_TRIGGER_RISING);
> >         enable_irq(irq_number);
> >
> >
> >         // To disable an interrupt and clean up.
> >         disable_irq(irq_number);
> >         free_irq(irq_number, NULL);
> >         gpio_free(gpio_pin);
>
> I tried it. Here is my code :
>
>         rtdm_irq_request(& irq_exemple, num_irq, exemple_handler,
> RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE,THIS_MODULE->name, NULL);
>
>          gpio_request_one(GPIO_IN, GPIOF_DIR_IN, THIS_MODULE->name);
>         irq_set_irq_type(num_irq,  IRQF_TRIGGER_RISING);
>         enable_irq(num_irq);

Request and set up the gpio & irq before calling rtdm_irq_request() then 
enable_irq(). However.... ALWAYS check the return codes from ANY 
function that requests or enables resources - Sometimes they fail and 
then you crash & burn.

>
>         return 0;
> }
>
> But here is what I get :
>
> # insmod rpi-rtdm.ko
> ------------[ cut here ]------------
> WARNING: at kernel/irq/manage.c:421 enable_irq+0x50/0x6c()
> Unbalanced enable for IRQ 108
> Modules linked in: rpi_rtdm(O+)
> [<c00136bc>] (unwind_backtrace+0x0/0xe4) from [<c0021c6c>]
> (warn_slowpath_common+0x4c/0x64)
> [<c0021c6c>] (warn_slowpath_common+0x4c/0x64) from [<c0021d04>]
> (warn_slowpath_fmt+0x2c/0x3c)
> [<c0021d04>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0060c50>]
> (enable_irq+0x50/0x6c)
> [<c0060c50>] (enable_irq+0x50/0x6c) from [<bf0020a8>]
> (exemple_init+0xa8/0xbc [rpi_rtdm])
> [<bf0020a8>] (exemple_init+0xa8/0xbc [rpi_rtdm]) from [<c00086a8>]
> (do_one_initcall+0x9c/0x17c)
> [<c00086a8>] (do_one_initcall+0x9c/0x17c) from [<c0051a5c>]
> (sys_init_module+0x1658/0x1830)
> [<c0051a5c>] (sys_init_module+0x1658/0x1830) from [<c000dbe0>]
> (ret_fast_syscall+0x0/0x30)
> ---[ end trace 6358198229f2f036 ]---
>
> So do I need to rebuild my entire system after patching my
> bcm2708_gpio.c ?

Just the kernel & modules needs to be recompiled and installed - Don't 
forget to recompile your module in case the Module.symvers map has 
changed.

> Or, I am doing something wrong with the lines of code that Paul gave
> me?

Apart from the ordering and lack of checks on the return codes - You 
will find information about the return codes in Documentation/gpio.txt 
along with plenty of examples in numerous driver code.

Regards, Paul.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Pierre LE COZ]

Thanks Paul for suggestions.

Having patched my bcm2708_gpio.c,  I rebuild the kernel and modules.
I added the checks on the return codes and recompiled my own module.

Unfortunately it looks like I still have the same problem, except this
time, I get a return code :

# insmod rpi-rtdm.ko
insmod: can't insert 'rpi-rtdm.ko': Device or resource busy

I could not find it in Documentation/gpio.txt.
I've found someone asking for similar problems. Respondents suggested the
use of at32_select_gpio(), but it's for an other target. So I don't think
this will help.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/18/2013 11:11 PM, Paul wrote:

> On Friday 18 January 2013, Pierre LE COZ wrote:
>> I have simple program to manage the GPIO of my raspberry Pi using
>> RTDM.
>>
>> I use :
>> "rtdm_irq_request(& irq_exemple, num_irq, exemple_handler,
>> RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE, "MyProgram", NULL);"
>> in order to detect interrupts.
> 
> rtdm_irq_request does not explicitly enable the interrupts on a gpio pin 
> with ian_cim's patch


This may be a generic issue, which I thought was fixed, but may not be.
Could you try the following patch?

http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed82267560c7bf26d628ef4d39f5b7

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Saturday 19 January 2013, Pierre LE COZ wrote:
> Unfortunately it looks like I still have the same problem, except
> this time, I get a return code :
>
> # insmod rpi-rtdm.ko
> insmod: can't insert 'rpi-rtdm.ko': Device or resource busy

Add some debug messages in the areas you request resources and then use 
dmesg - The most likely source of error is either attempting to use a 
resource that has been claimed or not releasing when you have finished 
with it.

Went through the same exercise last week and generated a simple kernel 
module to demonstrate the use of interrupts with Xenomai native & rtdm 
skins.

> I could not find it in Documentation/gpio.txt.
> I've found someone asking for similar problems. Respondents suggested
> the use of at32_select_gpio(), but it's for an other target. So I
> don't think this will help.

The response is wrong on several levels, aside from using a function 
that is not exported, it relies on an architecture dependant call. Use 
the standard gpio lib (see Documentation/gpio.text).


Regards, Paul

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Pierre LE COZ]

> Add some debug messages in the areas you request resources and then use
> dmesg - The most likely source of error is either attempting to use a
> resource that has been claimed or not releasing when you have finished
> with it.
>

Here's my entire init :

static int __init exemple_init (void)
{
        int err;

        printk(KERN_INFO "Requesting GPIO %d\n",GPIO_IN);
                if((err = gpio_request_one(GPIO_IN, GPIOF_DIR_IN,
THIS_MODULE->name)) !=0) {
                printk(KERN_INFO "error %d: could not request gpio: %d\n",
err, GPIO_IN);
                return err;
        }

        printk(KERN_INFO "Setting the irq type to trigger rising\n");
        irq_set_irq_type(BUTTON_IRQ,  IRQF_TRIGGER_RISING);


        printk(KERN_INFO "Requesting irq %d\n", BUTTON_IRQ);
        if((err = rtdm_irq_request(& irq_exemple, BUTTON_IRQ,
exemple_handler, 0, THIS_MODULE->name,  NULL)) !=0) {
                printk(KERN_INFO "error %d: could not request irq: %d\n",
err, GPIO_IN);
                gpio_free(GPIO_IN);
                return err;
        }

        printk(KERN_INFO "Enabling irq %d\n", BUTTON_IRQ);

        // enable_irq(BUTTON_IRQ);
        rtdm_irq_enable(& irq_exemple);
        return 0;
}

The module is running well, but still no interrupt detected  :
# insmod rpi-rtdm.ko

Requesting GPIO 23
Setting the irq type to trigger rising
Requesting irq 108
Enabling irq 108
/MyDEV/06_GPIO_rtdm_livre # cat /proc/xenomai/irq
IRQ         CPU0
  3:        3491         [timer]
108:           0         rpi_rtdm
259:           0         [virtual]
/MyDEV/06_GPIO_rtdm_livre #

When replacing "rtdm_irq_enable(& irq_exemple);" with
"enable_irq(BUTTON_IRQ);" to try to enable the irq, the module fails :
# insmod rpi-rtdm.ko
Requesting GPIO 23
Setting the irq type to trigger rising
Requesting irq 108
Enabling irq 108
------------[ cut here ]------------
WARNING: at kernel/irq/manage.c:421 enable_irq+0x50/0x6c()
Unbalanced enable for IRQ 108
Modules linked in: rpi_rtdm(O+)
[<c00136bc>] (unwind_backtrace+0x0/0xe4) from [<c0021c6c>]
(warn_slowpath_common+0x4c/0x64)
[<c0021c6c>] (warn_slowpath_common+0x4c/0x64) from [<c0021d04>]
(warn_slowpath_fmt+0x2c/0x3c)
[<c0021d04>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0060c50>]
(enable_irq+0x50/0x6c)
[<c0060c50>] (enable_irq+0x50/0x6c) from [<bf0020b4>]
(exemple_init+0xb4/0xe0 [rpi_rtdm])
[<bf0020b4>] (exemple_init+0xb4/0xe0 [rpi_rtdm]) from [<c00086a8>]
(do_one_initcall+0x9c/0x17c)
[<c00086a8>] (do_one_initcall+0x9c/0x17c) from [<c0051a5c>]
(sys_init_module+0x1658/0x1830)
[<c0051a5c>] (sys_init_module+0x1658/0x1830) from [<c000dbe0>]
(ret_fast_syscall+0x0/0x30)
---[ end trace d3f5d198ddeaf1cf ]---


 About the fact that interrupts are not detected :

This may be a generic issue, which I thought was fixed, but may not be.
> Could you try the following patch?
>

http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed82267560c7bf26d628ef4d39f5b7


Thank you Gilles for the patch. I tried it but I could not rebuild my
kernel :

  CC      arch/arm/kernel/ipipe.o
arch/arm/kernel/ipipe.c: In function ‘ipipe_get_sysinfo’:
arch/arm/kernel/ipipe.c:226:23: error: ‘__ipipe_hrclock_freq’ undeclared
(first use in this function)
arch/arm/kernel/ipipe.c:226:23: note: each undeclared identifier is
reported only once for each function it appears in
arch/arm/kernel/ipipe.c: In function ‘__switch_mm_inner’:
arch/arm/kernel/ipipe.c:450:3: error: ‘active_mm’ undeclared (first use in
this function)
arch/arm/kernel/ipipe.c:456:3: error: implicit declaration of function
‘__do_switch_mm’
arch/arm/kernel/ipipe.c: In function ‘deferred_switch_mm’:
arch/arm/kernel/ipipe.c:486:3: error: ‘active_mm’ undeclared (first use in
this function)
arch/arm/kernel/ipipe.c:492:3: error: implicit declaration of function
‘__deferred_switch_mm’
arch/arm/kernel/ipipe.c: At top level:
arch/arm/kernel/ipipe.c:564:1: error: ‘cpu_set_reserved_ttbr0’ undeclared
here (not in a function)
arch/arm/kernel/ipipe.c:564:1: warning: type defaults to ‘int’ in
declaration of ‘cpu_set_reserved_ttbr0’
make[1]: *** [arch/arm/kernel/ipipe.o] Error 1
make: *** [arch/arm/kernel] Error 2

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/19/2013 04:46 PM, Pierre LE COZ wrote:

>> Add some debug messages in the areas you request resources and then use
>> dmesg - The most likely source of error is either attempting to use a
>> resource that has been claimed or not releasing when you have finished
>> with it.
>>
> 
> Here's my entire init :
> 
> static int __init exemple_init (void)
> {
>         int err;
> 
>         printk(KERN_INFO "Requesting GPIO %d\n",GPIO_IN);
>                 if((err = gpio_request_one(GPIO_IN, GPIOF_DIR_IN,
> THIS_MODULE->name)) !=0) {
>                 printk(KERN_INFO "error %d: could not request gpio: %d\n",
> err, GPIO_IN);
>                 return err;
>         }
> 
>         printk(KERN_INFO "Setting the irq type to trigger rising\n");
>         irq_set_irq_type(BUTTON_IRQ,  IRQF_TRIGGER_RISING);
> 
> 
>         printk(KERN_INFO "Requesting irq %d\n", BUTTON_IRQ);
>         if((err = rtdm_irq_request(& irq_exemple, BUTTON_IRQ,
> exemple_handler, 0, THIS_MODULE->name,  NULL)) !=0) {
>                 printk(KERN_INFO "error %d: could not request irq: %d\n",
> err, GPIO_IN);
>                 gpio_free(GPIO_IN);
>                 return err;
>         }
> 
>         printk(KERN_INFO "Enabling irq %d\n", BUTTON_IRQ);
> 
>         // enable_irq(BUTTON_IRQ);
>         rtdm_irq_enable(& irq_exemple);
>         return 0;
> }
> 
> The module is running well, but still no interrupt detected  :
> # insmod rpi-rtdm.ko
> 
> Requesting GPIO 23
> Setting the irq type to trigger rising
> Requesting irq 108
> Enabling irq 108
> /MyDEV/06_GPIO_rtdm_livre # cat /proc/xenomai/irq
> IRQ         CPU0
>   3:        3491         [timer]
> 108:           0         rpi_rtdm
> 259:           0         [virtual]
> /MyDEV/06_GPIO_rtdm_livre #
> 
> When replacing "rtdm_irq_enable(& irq_exemple);" with
> "enable_irq(BUTTON_IRQ);" to try to enable the irq, the module fails :
> # insmod rpi-rtdm.ko
> Requesting GPIO 23
> Setting the irq type to trigger rising
> Requesting irq 108
> Enabling irq 108
> ------------[ cut here ]------------
> WARNING: at kernel/irq/manage.c:421 enable_irq+0x50/0x6c()
> Unbalanced enable for IRQ 108
> Modules linked in: rpi_rtdm(O+)
> [<c00136bc>] (unwind_backtrace+0x0/0xe4) from [<c0021c6c>]
> (warn_slowpath_common+0x4c/0x64)
> [<c0021c6c>] (warn_slowpath_common+0x4c/0x64) from [<c0021d04>]
> (warn_slowpath_fmt+0x2c/0x3c)
> [<c0021d04>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0060c50>]
> (enable_irq+0x50/0x6c)
> [<c0060c50>] (enable_irq+0x50/0x6c) from [<bf0020b4>]
> (exemple_init+0xb4/0xe0 [rpi_rtdm])
> [<bf0020b4>] (exemple_init+0xb4/0xe0 [rpi_rtdm]) from [<c00086a8>]
> (do_one_initcall+0x9c/0x17c)
> [<c00086a8>] (do_one_initcall+0x9c/0x17c) from [<c0051a5c>]
> (sys_init_module+0x1658/0x1830)
> [<c0051a5c>] (sys_init_module+0x1658/0x1830) from [<c000dbe0>]
> (ret_fast_syscall+0x0/0x30)
> ---[ end trace d3f5d198ddeaf1cf ]---
> 
> 
>  About the fact that interrupts are not detected :
> 
> This may be a generic issue, which I thought was fixed, but may not be.
>> Could you try the following patch?
>>
> 
> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed82267560c7bf26d628ef4d39f5b7
> 
> 
> Thank you Gilles for the patch. I tried it but I could not rebuild my
> kernel :


I do not know what you took. What you were supposed to apply is this diff:

http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=c14c79d29fed82267560c7bf26d628ef4d39f5b7;hp=3b3b1d3969106b561ec5fee6c0006eff2f1bc1bb

Which should not cause any such issue.

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Saturday 19 January 2013, Pierre LE COZ wrote:
> > Add some debug messages in the areas you request resources and then
> > use dmesg - The most likely source of error is either attempting to
> > use a resource that has been claimed or not releasing when you have
> > finished with it.
>
> Here's my entire init :
>
> static int __init exemple_init (void)
> {
>         int err;
>
>         printk(KERN_INFO "Requesting GPIO %d\n",GPIO_IN);
>                 if((err = gpio_request_one(GPIO_IN, GPIOF_DIR_IN,
> THIS_MODULE->name)) !=0) {
>                 printk(KERN_INFO "error %d: could not request gpio:
> %d\n", err, GPIO_IN);
>                 return err;
>         }
>
>         printk(KERN_INFO "Setting the irq type to trigger rising\n");
>         irq_set_irq_type(BUTTON_IRQ,  IRQF_TRIGGER_RISING);
>
>
>         printk(KERN_INFO "Requesting irq %d\n", BUTTON_IRQ);
>         if((err = rtdm_irq_request(& irq_exemple, BUTTON_IRQ,
> exemple_handler, 0, THIS_MODULE->name,  NULL)) !=0) {
>                 printk(KERN_INFO "error %d: could not request irq:
> %d\n", err, GPIO_IN);
>                 gpio_free(GPIO_IN);
>                 return err;
>         }
>
>         printk(KERN_INFO "Enabling irq %d\n", BUTTON_IRQ);
>
>         // enable_irq(BUTTON_IRQ);
>         rtdm_irq_enable(& irq_exemple);
>         return 0;
> }

static int irq_func(rtdm_irq_t *arg) { /* Do stuff */ }
static rtdm_irq_t gpio_reset;

static int __init module_init(void)
{
        irq_number = gpio_to_irq(gpio_pin);
        if (gpio > 31 || irq_number < 0 || !gpio_is_valid(gpio))
                return -EINVAL;

        if (gpio_request_one(gpio_pin, GPIOF_DIR_IN, 
THIS_MODULE->name) != 0)
                return -EIO;

        if (rtdm_irq_request(&gpio_reset,irq_number, irq_func, 
RTDM_IRQTYPE_EDGE, "MODULE", NULL) ) {
                gpio_free(gpio_pin);
                return -EIO;
        }
        rtdm_irq_enable(&gpio_reset); // Should check return code.
        return 0;
}

Tested & works on my 3.2.27 kernel - Looks like I might have been 
getting mixed up with a similar module using the xeno-native API.

> The module is running well, but still no interrupt detected  :
> # insmod rpi-rtdm.ko
>  About the fact that interrupts are not detected :
>
> This may be a generic issue, which I thought was fixed, but may not
> be.
>
> > Could you try the following patch?
>
> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed822675
>60c7bf26d628ef4d39f5b7

Gilles: Looked at the patch and got as far as the changes in 
kernel/ipipe/timer.c:ipipe_timer_stop() - Correct me if I'm wrong, but 
this patch is based on a 3.5.7 parent without GENERIC_CLOCKEVENTS ?


Regards, Paul.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/20/2013 01:13 AM, Paul wrote:

> On Saturday 19 January 2013, Pierre LE COZ wrote:
>>> Add some debug messages in the areas you request resources and then
>>> use dmesg - The most likely source of error is either attempting to
>>> use a resource that has been claimed or not releasing when you have
>>> finished with it.
>>
>> Here's my entire init :
>>
>> static int __init exemple_init (void)
>> {
>>         int err;
>>
>>         printk(KERN_INFO "Requesting GPIO %d\n",GPIO_IN);
>>                 if((err = gpio_request_one(GPIO_IN, GPIOF_DIR_IN,
>> THIS_MODULE->name)) !=0) {
>>                 printk(KERN_INFO "error %d: could not request gpio:
>> %d\n", err, GPIO_IN);
>>                 return err;
>>         }
>>
>>         printk(KERN_INFO "Setting the irq type to trigger rising\n");
>>         irq_set_irq_type(BUTTON_IRQ,  IRQF_TRIGGER_RISING);
>>
>>
>>         printk(KERN_INFO "Requesting irq %d\n", BUTTON_IRQ);
>>         if((err = rtdm_irq_request(& irq_exemple, BUTTON_IRQ,
>> exemple_handler, 0, THIS_MODULE->name,  NULL)) !=0) {
>>                 printk(KERN_INFO "error %d: could not request irq:
>> %d\n", err, GPIO_IN);
>>                 gpio_free(GPIO_IN);
>>                 return err;
>>         }
>>
>>         printk(KERN_INFO "Enabling irq %d\n", BUTTON_IRQ);
>>
>>         // enable_irq(BUTTON_IRQ);
>>         rtdm_irq_enable(& irq_exemple);
>>         return 0;
>> }
> 
> static int irq_func(rtdm_irq_t *arg) { /* Do stuff */ }
> static rtdm_irq_t gpio_reset;
> 
> static int __init module_init(void)
> {
>         irq_number = gpio_to_irq(gpio_pin);
>         if (gpio > 31 || irq_number < 0 || !gpio_is_valid(gpio))
>                 return -EINVAL;
> 
>         if (gpio_request_one(gpio_pin, GPIOF_DIR_IN, 
> THIS_MODULE->name) != 0)
>                 return -EIO;
> 
>         if (rtdm_irq_request(&gpio_reset,irq_number, irq_func, 
> RTDM_IRQTYPE_EDGE, "MODULE", NULL) ) {
>                 gpio_free(gpio_pin);
>                 return -EIO;
>         }
>         rtdm_irq_enable(&gpio_reset); // Should check return code.
>         return 0;
> }
> 
> Tested & works on my 3.2.27 kernel - Looks like I might have been 
> getting mixed up with a similar module using the xeno-native API.
> 
>> The module is running well, but still no interrupt detected  :
>> # insmod rpi-rtdm.ko
>>  About the fact that interrupts are not detected :
>>
>> This may be a generic issue, which I thought was fixed, but may not
>> be.
>>
>>> Could you try the following patch?
>>
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed822675
>> 60c7bf26d628ef4d39f5b7
> 
> Gilles: Looked at the patch and got as far as the changes in 
> kernel/ipipe/timer.c:ipipe_timer_stop() - Correct me if I'm wrong, but 
> this patch is based on a 3.5.7 parent without GENERIC_CLOCKEVENTS ?


Yes, this patch is based on 3.5.7 and is used with and without
GENERIC_CLOCKEVENTS.

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
> On 01/20/2013 01:13 AM, Paul wrote:

> >>  About the fact that interrupts are not detected :
> >>
> >> This may be a generic issue, which I thought was fixed, but may
> >> not be.
> >>
> >>> Could you try the following patch?
> >>
> >> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed822
> >>675 60c7bf26d628ef4d39f5b7
> >
> > Gilles: Looked at the patch and got as far as the changes in
> > kernel/ipipe/timer.c:ipipe_timer_stop() - Correct me if I'm wrong,
> > but this patch is based on a 3.5.7 parent without
> > GENERIC_CLOCKEVENTS ?
>
> Yes, this patch is based on 3.5.7 and is used with and without
> GENERIC_CLOCKEVENTS.

Short version: Updated my kernel to 3.5.7 and backported the Raspberry 
Pi changes from 3.6.11 and added in the ipipe support. Interrupts are 
not being recognised unless irq_set_irq_type() is called. Digging 
through the rtdm, nucleus, and ipipe code, at no point is 
irq_chip->irq_set_type() called - Also have a problem that none of the 
ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() & friends 
do nothing.

Noticed XN_ISR_EDGE equates to a falling edge trigger - 
irq_set_irq_type() allows for rising, level, or falling edge triggers. 
At some point, it may be advantageous to be able to select one of the 
three.

Will continue digging and add a routine in bcm2708_gpio.c to set the 
ipipe_pic_muter fields in the morning.


Regards, Paul.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/22/2013 04:06 AM, Paul wrote:

> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>> On 01/20/2013 01:13 AM, Paul wrote:
> 
>>>>  About the fact that interrupts are not detected :
>>>>
>>>> This may be a generic issue, which I thought was fixed, but may
>>>> not be.
>>>>
>>>>> Could you try the following patch?
>>>>
>>>> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed822
>>>> 675 60c7bf26d628ef4d39f5b7
>>>
>>> Gilles: Looked at the patch and got as far as the changes in
>>> kernel/ipipe/timer.c:ipipe_timer_stop() - Correct me if I'm wrong,
>>> but this patch is based on a 3.5.7 parent without
>>> GENERIC_CLOCKEVENTS ?
>>
>> Yes, this patch is based on 3.5.7 and is used with and without
>> GENERIC_CLOCKEVENTS.
> 
> Short version: Updated my kernel to 3.5.7 and backported the Raspberry 
> Pi changes from 3.6.11 and added in the ipipe support. Interrupts are 
> not being recognised unless irq_set_irq_type() is called. Digging 
> through the rtdm, nucleus, and ipipe code, at no point is 
> irq_chip->irq_set_type() called - Also have a problem that none of the 
> ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() & friends 
> do nothing.
> 
> Noticed XN_ISR_EDGE equates to a falling edge trigger - 
> irq_set_irq_type() allows for rising, level, or falling edge triggers. 
> At some point, it may be advantageous to be able to select one of the 
> three.
> 
> Will continue digging and add a routine in bcm2708_gpio.c to set the 
> ipipe_pic_muter fields in the morning.


PIC muting is not mandatory, I am not sure why you would need it.

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/22/2013 08:51 AM, Gilles Chanteperdrix wrote:

> On 01/22/2013 04:06 AM, Paul wrote:
> 
>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>>> On 01/20/2013 01:13 AM, Paul wrote:
>>
>>>>>  About the fact that interrupts are not detected :
>>>>>
>>>>> This may be a generic issue, which I thought was fixed, but may
>>>>> not be.
>>>>>
>>>>>> Could you try the following patch?
>>>>>
>>>>> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed822
>>>>> 675 60c7bf26d628ef4d39f5b7
>>>>
>>>> Gilles: Looked at the patch and got as far as the changes in
>>>> kernel/ipipe/timer.c:ipipe_timer_stop() - Correct me if I'm wrong,
>>>> but this patch is based on a 3.5.7 parent without
>>>> GENERIC_CLOCKEVENTS ?
>>>
>>> Yes, this patch is based on 3.5.7 and is used with and without
>>> GENERIC_CLOCKEVENTS.
>>
>> Short version: Updated my kernel to 3.5.7 and backported the Raspberry 
>> Pi changes from 3.6.11 and added in the ipipe support. Interrupts are 
>> not being recognised unless irq_set_irq_type() is called. Digging 
>> through the rtdm, nucleus, and ipipe code, at no point is 
>> irq_chip->irq_set_type() called - Also have a problem that none of the 
>> ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() & friends 
>> do nothing.
>>
>> Noticed XN_ISR_EDGE equates to a falling edge trigger - 
>> irq_set_irq_type() allows for rising, level, or falling edge triggers. 
>> At some point, it may be advantageous to be able to select one of the 
>> three.
>>
>> Will continue digging and add a routine in bcm2708_gpio.c to set the 
>> ipipe_pic_muter fields in the morning.
> 
> 
> PIC muting is not mandatory, I am not sure why you would need it.
> 

If you decide to implement it anyway, you may find some information here:
http://xenomai.org/index.php/I-pipe-core:ArmPorting#Interrupt_Controller_muting

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/22/2013 04:06 AM, Paul wrote:

> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>> On 01/20/2013 01:13 AM, Paul wrote:
> 
>>>>  About the fact that interrupts are not detected :
>>>>
>>>> This may be a generic issue, which I thought was fixed, but may
>>>> not be.
>>>>
>>>>> Could you try the following patch?
>>>>
>>>> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=c14c79d29fed822
>>>> 675 60c7bf26d628ef4d39f5b7
>>>
>>> Gilles: Looked at the patch and got as far as the changes in
>>> kernel/ipipe/timer.c:ipipe_timer_stop() - Correct me if I'm wrong,
>>> but this patch is based on a 3.5.7 parent without
>>> GENERIC_CLOCKEVENTS ?
>>
>> Yes, this patch is based on 3.5.7 and is used with and without
>> GENERIC_CLOCKEVENTS.
> 
> Short version: Updated my kernel to 3.5.7 and backported the Raspberry 
> Pi changes from 3.6.11 and added in the ipipe support. Interrupts are 
> not being recognised unless irq_set_irq_type() is called. Digging 
> through the rtdm, nucleus, and ipipe code, at no point is 
> irq_chip->irq_set_type() called - 


The problem is that in Xenomai 2.x branch, it is valid to call
rtdm_irq_request from primary domain, and irq_set_irq_type can not be
called from primary domain. This will be simplified in Xenomai 3.0, but
for the time being, it is much simpler if drivers call it separately.

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Christophe Blaess]

On 22/01/2013 04:06, Paul wrote:
> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>> Yes, this patch is based on 3.5.7 and is used with and without
>> GENERIC_CLOCKEVENTS.
> Short version: Updated my kernel to 3.5.7 and backported the Raspberry
> Pi changes from 3.6.11 and added in the ipipe support. Interrupts are
> not being recognised unless irq_set_irq_type() is called. Digging
> through the rtdm, nucleus, and ipipe code, at no point is
> irq_chip->irq_set_type() called - Also have a problem that none of the
> ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() & friends
> do nothing.

I'm trying to follow the same steps as you but I still have some 
compilation errors while porting
R-Pi modifications to 3.5.7. (especially arm timer code).

Do you have any available patch against 3.5.7 vanilla kernel ?

I have a working GPIO interrupt rtdm driver with 3.2.21 kernel (Xenomai 
2.6.2) but the interrupt latencies seems terrible (about 20us and 
jiterring up to 150us without any load). To compare with the 7us latency 
I see on a vanilla Linux GPIO interrupt handler.


Regards,

-- 
Christophe

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Thursday 24 January 2013, Christophe Blaess wrote:
> On 22/01/2013 04:06, Paul wrote:
> > On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
> >> Yes, this patch is based on 3.5.7 and is used with and without
> >> GENERIC_CLOCKEVENTS.
> >
> > Short version: Updated my kernel to 3.5.7 and backported the
> > Raspberry Pi changes from 3.6.11 and added in the ipipe support.
> > Interrupts are not being recognised unless irq_set_irq_type() is
> > called. Digging through the rtdm, nucleus, and ipipe code, at no
> > point is
> > irq_chip->irq_set_type() called - Also have a problem that none of
> > the ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() &
> > friends do nothing.
>
> I'm trying to follow the same steps as you but I still have some
> compilation errors while porting
> R-Pi modifications to 3.5.7. (especially arm timer code).
>
> Do you have any available patch against 3.5.7 vanilla kernel ?

Funny that you should ask - I am in the middle of generating a patch set 
against 3.5.7 with the Raspberry Pi additions. This will include the 
ipipe modifications along with a fix to the gpio interrupt handler.

> I have a working GPIO interrupt rtdm driver with 3.2.21 kernel
> (Xenomai 2.6.2) but the interrupt latencies seems terrible (about
> 20us and jiterring up to 150us without any load). To compare with the
> 7us latency I see on a vanilla Linux GPIO interrupt handler.

Should be better than that - Did you make any changes to the interrupt 
handler in bcm207_gpio.c ?

Regards, Paul.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Christophe Blaess]

On 24/01/2013 18:12, Paul wrote:
> On Thursday 24 January 2013, Christophe Blaess wrote:
>> On 22/01/2013 04:06, Paul wrote:
>>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>>>> Yes, this patch is based on 3.5.7 and is used with and without
>>>> GENERIC_CLOCKEVENTS.
>>> Short version: Updated my kernel to 3.5.7 and backported the
>>> Raspberry Pi changes from 3.6.11 and added in the ipipe support.
>>> Interrupts are not being recognised unless irq_set_irq_type() is
>>> called. Digging through the rtdm, nucleus, and ipipe code, at no
>>> point is
>>> irq_chip->irq_set_type() called - Also have a problem that none of
>>> the ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() &
>>> friends do nothing.
>> I'm trying to follow the same steps as you but I still have some
>> compilation errors while porting
>> R-Pi modifications to 3.5.7. (especially arm timer code).
>>
>> Do you have any available patch against 3.5.7 vanilla kernel ?
> Funny that you should ask - I am in the middle of generating a patch set
> against 3.5.7 with the Raspberry Pi additions. This will include the
> ipipe modifications along with a fix to the gpio interrupt handler.

Great.

>
>> I have a working GPIO interrupt rtdm driver with 3.2.21 kernel
>> (Xenomai 2.6.2) but the interrupt latencies seems terrible (about
>> 20us and jiterring up to 150us without any load). To compare with the
>> 7us latency I see on a vanilla Linux GPIO interrupt handler.
> Should be better than that - Did you make any changes to the interrupt
> handler in bcm207_gpio.c ?

I replaced generic_handle_irq() by ipipe_handle_demuxed_irq().


My interrupt handler toggle an ouput GPIO pin :

static int handler_irq(rtdm_irq_t * irq)
{
         static int value = 0;
         gpio_set_value(GPIO_OUT, value);
         value = 1 - value;
         return RTDM_IRQ_HANDLED;
}

I think that gpio_set_value() doesn't call any Linux services, but I may 
be wrong.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/24/2013 06:12 PM, Paul wrote:

> On Thursday 24 January 2013, Christophe Blaess wrote:
>> On 22/01/2013 04:06, Paul wrote:
>>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>>>> Yes, this patch is based on 3.5.7 and is used with and without
>>>> GENERIC_CLOCKEVENTS.
>>>
>>> Short version: Updated my kernel to 3.5.7 and backported the
>>> Raspberry Pi changes from 3.6.11 and added in the ipipe support.
>>> Interrupts are not being recognised unless irq_set_irq_type() is
>>> called. Digging through the rtdm, nucleus, and ipipe code, at no
>>> point is
>>> irq_chip->irq_set_type() called - Also have a problem that none of
>>> the ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() &
>>> friends do nothing.
>>
>> I'm trying to follow the same steps as you but I still have some
>> compilation errors while porting
>> R-Pi modifications to 3.5.7. (especially arm timer code).
>>
>> Do you have any available patch against 3.5.7 vanilla kernel ?
> 
> Funny that you should ask - I am in the middle of generating a patch set 
> against 3.5.7 with the Raspberry Pi additions. This will include the 
> ipipe modifications along with a fix to the gpio interrupt handler.


If you generate this patch as a diff agains the I-pipe kernel, the patch
could be shipped with Xenomai, or even merged in the I-pipe kernel.

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/24/2013 06:38 PM, Christophe Blaess wrote:

> On 24/01/2013 18:12, Paul wrote:
>> On Thursday 24 January 2013, Christophe Blaess wrote:
>>> On 22/01/2013 04:06, Paul wrote:
>>>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>>>>> Yes, this patch is based on 3.5.7 and is used with and without
>>>>> GENERIC_CLOCKEVENTS.
>>>> Short version: Updated my kernel to 3.5.7 and backported the
>>>> Raspberry Pi changes from 3.6.11 and added in the ipipe support.
>>>> Interrupts are not being recognised unless irq_set_irq_type() is
>>>> called. Digging through the rtdm, nucleus, and ipipe code, at no
>>>> point is
>>>> irq_chip->irq_set_type() called - Also have a problem that none of
>>>> the ipipe_pic_muter fields are set, so __ipipe_enable_irqdesc() &
>>>> friends do nothing.
>>> I'm trying to follow the same steps as you but I still have some
>>> compilation errors while porting
>>> R-Pi modifications to 3.5.7. (especially arm timer code).
>>>
>>> Do you have any available patch against 3.5.7 vanilla kernel ?
>> Funny that you should ask - I am in the middle of generating a patch set
>> against 3.5.7 with the Raspberry Pi additions. This will include the
>> ipipe modifications along with a fix to the gpio interrupt handler.
> 
> Great.
> 
>>
>>> I have a working GPIO interrupt rtdm driver with 3.2.21 kernel
>>> (Xenomai 2.6.2) but the interrupt latencies seems terrible (about
>>> 20us and jiterring up to 150us without any load). To compare with the
>>> 7us latency I see on a vanilla Linux GPIO interrupt handler.
>> Should be better than that - Did you make any changes to the interrupt
>> handler in bcm207_gpio.c ?
> 
> I replaced generic_handle_irq() by ipipe_handle_demuxed_irq().
> 
> 
> My interrupt handler toggle an ouput GPIO pin :
> 
> static int handler_irq(rtdm_irq_t * irq)
> {
>          static int value = 0;
>          gpio_set_value(GPIO_OUT, value);
>          value = 1 - value;
>          return RTDM_IRQ_HANDLED;
> }
> 
> I think that gpio_set_value() doesn't call any Linux services, but I may 
> be wrong.


Two things to check then:
http://xenomai.org/index.php/I-pipe-core:ArmPorting#GPIOs_in_real-time_drivers

And the second I forgot in the porting guide is the idle loop. The
processor dependent idle routine is called by the I-pipe kernel with
hardware irqs on, this could result in an interrupt being handled with
part of the processor still prepared for sleeping. For instance, on
arm926ejs, this could result in interrupts being handled with I-cache
off, which resulted in high latencies.

As a first step  to check that it is not the issue you observe, boot
with the "nohlt" kernel option. If the latencies improve, then something
needs to be done about the idle loop.

If that is your issue, there are two ways around:
- call hard_local_irq_disable() at the beginning of the processor
dependent idle routine
- if this results in to high latencies (due to the time it takes to
execute the handler), then simply disable this idle routine.

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Friday 25 January 2013, Gilles Chanteperdrix wrote:
> On 01/24/2013 06:12 PM, Paul wrote:
> > On Thursday 24 January 2013, Christophe Blaess wrote:
> >> On 22/01/2013 04:06, Paul wrote:
> >>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
> >>>> Yes, this patch is based on 3.5.7 and is used with and without
> >>>> GENERIC_CLOCKEVENTS.
> >>>
> >>> Short version: Updated my kernel to 3.5.7 and backported the
> >>> Raspberry Pi changes from 3.6.11 and added in the ipipe support.
> >>> Interrupts are not being recognised unless irq_set_irq_type() is
> >>> called. Digging through the rtdm, nucleus, and ipipe code, at no
> >>> point is
> >>> irq_chip->irq_set_type() called - Also have a problem that none
> >>> of the ipipe_pic_muter fields are set, so
> >>> __ipipe_enable_irqdesc() & friends do nothing.
> >>
> >> I'm trying to follow the same steps as you but I still have some
> >> compilation errors while porting
> >> R-Pi modifications to 3.5.7. (especially arm timer code).
> >>
> >> Do you have any available patch against 3.5.7 vanilla kernel ?
> >
> > Funny that you should ask - I am in the middle of generating a
> > patch set against 3.5.7 with the Raspberry Pi additions. This will
> > include the ipipe modifications along with a fix to the gpio
> > interrupt handler.
>
> If you generate this patch as a diff agains the I-pipe kernel, the
> patch could be shipped with Xenomai, or even merged in the I-pipe
> kernel.

Generated three patches which Christophe is trying out. At some 91,000 
lines, it touches on several core kernel sources including mmc, dma, 
and skbuff as well as adding a dwc_otg driver on top of the 
BCM2835/2708 support. Not sure that you'd want to merge the changes 
that affect some (estimated) sixty 3.5.7 files. Shipping as an optional 
add-on patch is possible, but it currently generates a couple of 
rejects when applied to a vanilla 3.5.7-stable.

Work is under way by the Raspberry Pi team to get the required support 
integrated with the mainline kernel. By the time 3.10.y gets released, 
we might see it in stable.


Regards, Paul.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/28/2013 01:29 PM, Paul wrote:

> On Friday 25 January 2013, Gilles Chanteperdrix wrote:
>> On 01/24/2013 06:12 PM, Paul wrote:
>>> On Thursday 24 January 2013, Christophe Blaess wrote:
>>>> On 22/01/2013 04:06, Paul wrote:
>>>>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>>>>>> Yes, this patch is based on 3.5.7 and is used with and without
>>>>>> GENERIC_CLOCKEVENTS.
>>>>>
>>>>> Short version: Updated my kernel to 3.5.7 and backported the
>>>>> Raspberry Pi changes from 3.6.11 and added in the ipipe support.
>>>>> Interrupts are not being recognised unless irq_set_irq_type() is
>>>>> called. Digging through the rtdm, nucleus, and ipipe code, at no
>>>>> point is
>>>>> irq_chip->irq_set_type() called - Also have a problem that none
>>>>> of the ipipe_pic_muter fields are set, so
>>>>> __ipipe_enable_irqdesc() & friends do nothing.
>>>>
>>>> I'm trying to follow the same steps as you but I still have some
>>>> compilation errors while porting
>>>> R-Pi modifications to 3.5.7. (especially arm timer code).
>>>>
>>>> Do you have any available patch against 3.5.7 vanilla kernel ?
>>>
>>> Funny that you should ask - I am in the middle of generating a
>>> patch set against 3.5.7 with the Raspberry Pi additions. This will
>>> include the ipipe modifications along with a fix to the gpio
>>> interrupt handler.
>>
>> If you generate this patch as a diff agains the I-pipe kernel, the
>> patch could be shipped with Xenomai, or even merged in the I-pipe
>> kernel.
> 
> Generated three patches which Christophe is trying out. At some 91,000 
> lines, it touches on several core kernel sources including mmc, dma, 
> and skbuff as well as adding a dwc_otg driver on top of the 
> BCM2835/2708 support. Not sure that you'd want to merge the changes 
> that affect some (estimated) sixty 3.5.7 files. Shipping as an optional 
> add-on patch is possible, but it currently generates a couple of 
> rejects when applied to a vanilla 3.5.7-stable.
> 
> Work is under way by the Raspberry Pi team to get the required support 
> integrated with the mainline kernel. By the time 3.10.y gets released, 
> we might see it in stable.


Right, we can wait for mainline, or, ship the jumbo patch with Xenomai,
but separated, and with every I-pipe release, you would merge the
changes from the I-pipe branch.

> 
> 
> Regards, Paul.
> 



-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Friday 25 January 2013, Gilles Chanteperdrix wrote:
> On 01/24/2013 06:38 PM, Christophe Blaess wrote:
> > On 24/01/2013 18:12, Paul wrote:
> >> On Thursday 24 January 2013, Christophe Blaess wrote:
> >>> On 22/01/2013 04:06, Paul wrote:
> >>>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
> >>>>> Yes, this patch is based on 3.5.7 and is used with and without
> >>>>> GENERIC_CLOCKEVENTS.
> >>>>
> >>>> Short version: Updated my kernel to 3.5.7 and backported the
> >>>> Raspberry Pi changes from 3.6.11 and added in the ipipe support.
> >>>> Interrupts are not being recognised unless irq_set_irq_type() is
> >>>> called. Digging through the rtdm, nucleus, and ipipe code, at no
> >>>> point is
> >>>> irq_chip->irq_set_type() called - Also have a problem that none
> >>>> of the ipipe_pic_muter fields are set, so
> >>>> __ipipe_enable_irqdesc() & friends do nothing.
> >>>
> >>> I'm trying to follow the same steps as you but I still have some
> >>> compilation errors while porting
> >>> R-Pi modifications to 3.5.7. (especially arm timer code).
> >>>
> >>> Do you have any available patch against 3.5.7 vanilla kernel ?
> >>
> >> Funny that you should ask - I am in the middle of generating a
> >> patch set against 3.5.7 with the Raspberry Pi additions. This will
> >> include the ipipe modifications along with a fix to the gpio
> >> interrupt handler.
> >
> > Great.
> >
> >>> I have a working GPIO interrupt rtdm driver with 3.2.21 kernel
> >>> (Xenomai 2.6.2) but the interrupt latencies seems terrible (about
> >>> 20us and jiterring up to 150us without any load). To compare with
> >>> the 7us latency I see on a vanilla Linux GPIO interrupt handler.
> >>
> >> Should be better than that - Did you make any changes to the
> >> interrupt handler in bcm207_gpio.c ?
> >
> > I replaced generic_handle_irq() by ipipe_handle_demuxed_irq().
> >
> >
> > My interrupt handler toggle an ouput GPIO pin :
> >
> > static int handler_irq(rtdm_irq_t * irq)
> > {
> >          static int value = 0;
> >          gpio_set_value(GPIO_OUT, value);
> >          value = 1 - value;
> >          return RTDM_IRQ_HANDLED;
> > }
> >
> > I think that gpio_set_value() doesn't call any Linux services, but
> > I may be wrong.
>
> Two things to check then:
> http://xenomai.org/index.php/I-pipe-core:ArmPorting#GPIOs_in_real-tim
>e_drivers
>
> And the second I forgot in the porting guide is the idle loop. The
> processor dependent idle routine is called by the I-pipe kernel with
> hardware irqs on, this could result in an interrupt being handled
> with part of the processor still prepared for sleeping. For instance,
> on arm926ejs, this could result in interrupts being handled with
> I-cache off, which resulted in high latencies.
>
> As a first step  to check that it is not the issue you observe, boot
> with the "nohlt" kernel option. If the latencies improve, then
> something needs to be done about the idle loop.
>
> If that is your issue, there are two ways around:
> - call hard_local_irq_disable() at the beginning of the processor
> dependent idle routine
> - if this results in to high latencies (due to the time it takes to
> execute the handler), then simply disable this idle routine.

Booting with "dwc_otg.fiq_fix_enable=0" in cmdline.txt improves matters 
considerably - The problem is in the FIQ handler and/or the dwc_otg 
driver.

This will have to wait until the weekend and hopefully I can get time to 
dig further. One option is to route the timer through the FIQ which may 
improve latency a little, another is to disable it altogether.


Regards, Paul.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Gilles Chanteperdrix]

On 01/31/2013 03:11 AM, Paul wrote:

> On Friday 25 January 2013, Gilles Chanteperdrix wrote:
>> On 01/24/2013 06:38 PM, Christophe Blaess wrote:
>>> On 24/01/2013 18:12, Paul wrote:
>>>> On Thursday 24 January 2013, Christophe Blaess wrote:
>>>>> On 22/01/2013 04:06, Paul wrote:
>>>>>> On Sunday 20 January 2013, Gilles Chanteperdrix wrote:
>>>>>>> Yes, this patch is based on 3.5.7 and is used with and without
>>>>>>> GENERIC_CLOCKEVENTS.
>>>>>>
>>>>>> Short version: Updated my kernel to 3.5.7 and backported the
>>>>>> Raspberry Pi changes from 3.6.11 and added in the ipipe support.
>>>>>> Interrupts are not being recognised unless irq_set_irq_type() is
>>>>>> called. Digging through the rtdm, nucleus, and ipipe code, at no
>>>>>> point is
>>>>>> irq_chip->irq_set_type() called - Also have a problem that none
>>>>>> of the ipipe_pic_muter fields are set, so
>>>>>> __ipipe_enable_irqdesc() & friends do nothing.
>>>>>
>>>>> I'm trying to follow the same steps as you but I still have some
>>>>> compilation errors while porting
>>>>> R-Pi modifications to 3.5.7. (especially arm timer code).
>>>>>
>>>>> Do you have any available patch against 3.5.7 vanilla kernel ?
>>>>
>>>> Funny that you should ask - I am in the middle of generating a
>>>> patch set against 3.5.7 with the Raspberry Pi additions. This will
>>>> include the ipipe modifications along with a fix to the gpio
>>>> interrupt handler.
>>>
>>> Great.
>>>
>>>>> I have a working GPIO interrupt rtdm driver with 3.2.21 kernel
>>>>> (Xenomai 2.6.2) but the interrupt latencies seems terrible (about
>>>>> 20us and jiterring up to 150us without any load). To compare with
>>>>> the 7us latency I see on a vanilla Linux GPIO interrupt handler.
>>>>
>>>> Should be better than that - Did you make any changes to the
>>>> interrupt handler in bcm207_gpio.c ?
>>>
>>> I replaced generic_handle_irq() by ipipe_handle_demuxed_irq().
>>>
>>>
>>> My interrupt handler toggle an ouput GPIO pin :
>>>
>>> static int handler_irq(rtdm_irq_t * irq)
>>> {
>>>          static int value = 0;
>>>          gpio_set_value(GPIO_OUT, value);
>>>          value = 1 - value;
>>>          return RTDM_IRQ_HANDLED;
>>> }
>>>
>>> I think that gpio_set_value() doesn't call any Linux services, but
>>> I may be wrong.
>>
>> Two things to check then:
>> http://xenomai.org/index.php/I-pipe-core:ArmPorting#GPIOs_in_real-tim
>> e_drivers
>>
>> And the second I forgot in the porting guide is the idle loop. The
>> processor dependent idle routine is called by the I-pipe kernel with
>> hardware irqs on, this could result in an interrupt being handled
>> with part of the processor still prepared for sleeping. For instance,
>> on arm926ejs, this could result in interrupts being handled with
>> I-cache off, which resulted in high latencies.
>>
>> As a first step  to check that it is not the issue you observe, boot
>> with the "nohlt" kernel option. If the latencies improve, then
>> something needs to be done about the idle loop.
>>
>> If that is your issue, there are two ways around:
>> - call hard_local_irq_disable() at the beginning of the processor
>> dependent idle routine
>> - if this results in to high latencies (due to the time it takes to
>> execute the handler), then simply disable this idle routine.
> 
> Booting with "dwc_otg.fiq_fix_enable=0" in cmdline.txt improves matters 
> considerably - The problem is in the FIQ handler and/or the dwc_otg 
> driver.

>

> This will have to wait until the weekend and hopefully I can get time to 
> dig further. One option is to route the timer through the FIQ which may 
> improve latency a little, another is to disable it altogether.


You can not really execute the timer irq handler in FIQ mode, if that is
what you mean.

-- 
                                                                Gilles.

Re: [Xenomai] GPIO Interrupts problem with RTDM

[Paul]

On Thursday 31 January 2013, Gilles Chanteperdrix wrote:
> On 01/31/2013 03:11 AM, Paul wrote:
> > Booting with "dwc_otg.fiq_fix_enable=0" in cmdline.txt improves
> > matters considerably - The problem is in the FIQ handler and/or the
> > dwc_otg driver.

Hvaving spent some time going over some of the code, the FIQ handler is 
not at the root of the problem.

> > This will have to wait until the weekend and hopefully I can get
> > time to dig further. One option is to route the timer through the
> > FIQ which may improve latency a little, another is to disable it
> > altogether.
> You can not really execute the timer irq handler in FIQ mode, if that
> is what you mean.

I had indeed thought the timer irq handler could be run in FIQ mode. 
Didn't take long to rule that idea out as a nonstarter.

Upshot of the last couple of weeks is I finally have GPIO interrupt 
latencies down to a more respectable 12-30uS delay - This is with the 
ipipe tracer enabled, so there is scope to reduce it further.

Once I've cleaned up my hacks and run on a fully loaded box with the 
tracer disabled, I'll generate a patch for the Raspberry Pi and post it 
somewhere.


Regards, Paul.