Re: [Xenomai] GPIO Interrupts problem with RTDM
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.
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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.
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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.
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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.
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] GPIO Interrupts problem with RTDM
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
