Hi,

 

I was trying to upgrade my application running on Viper (2.6.16.28 kernel with xenomai 2.3.1)  to

kernel 2.6.30.10 with xenomai 2.4.10 and ran into couple of problems.

 

1. My application uses real-time hook to CPLD interrupt, which is chained interrupt.

   In Xenomai 2.4.10 for some reason general purpose interrupt handler for chained interrupt is assigned  to I-pipe  acknowledgment handler during board initialization:

 

in kernel/irq/chip.c: 

 

_set_irq_hanler(...

 

#ifdef CONFIG_IPIPE

               else if (is_chained) {

               desc->ipipe_ack = handle;

               desc->ipipe_end = &__ipipe_noend_irq;

               handle = &__ipipe_noack_irq;

#endif   

 

As a result, when CPLD interrupt happened, general purpose interrupt from Linux domain is executed as part of ipipe interrupt acknowledgment. After that my real-time interrupt handler gets executed. This is not normal, as my handler supposed to replace general purpose handler, which should not be executed at all, unless I want it to be executed.  I  fixed this problem by reassigning ipipe acknowledgment to __ipipe_ack_edge_irq, and not changing handler at all, and it worked in my case. But this probably can break some other code.

 

2. USB on Viepr is not working with I-pipe.  

 

I found the cause of this problem. Again for some reason, I-pipe patch changes type of the USB and all other multiplexed interrupts from edge to level interrupt, which they are in original Linux kernel. Of course, this breaks everything. I fixed USB by changing back interrupts type from level to edge in arch/arm/plat-pxa/gpio.c:

 

void __intit pxa_init_gpio(

               instead of

#ifndef CONFIG_IPIPE

               set_irq_handler(irq,handle_edge_irq);

#else

               set_irq_handler(irq,handle_level_irq);

#endif

 

I'm using just

               set_irq_handler(irq,handle_edge_irq);

, as it was in original Linux code and everything works fine.

 

Shouldn't changes to interrupt code in Xenomai depend on particular board and not be part of the common code?

 

I would appreciate any response regarding these issues.

 

Regards,

 

Ivan