Comments inline...

On 7/20/2010 10:24 PM, Gilles Chanteperdrix wrote:

... snipped ...

However, I had trouble with this code on 2.6.33 generating spurious i2c
interrupts, which lead me to the following patch:
http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=cdc72520c88b329fa785b0e1f45392cdfff10ec6;hp=e52fee515be7c5b914c201c19604cd700afbc44f

which I backported to 2.6.31 without testing it. Could you try and
revert it?

Sure. I'll start tomorrow.

The easiest way to test the twl4030 interrupt handling may be to use the 
SD Card for a removable file system (not root). If the file system 
automounts when the SD Card is plugged in, that would indicate that the 
twl4030 interrupts are being handled correctly. From the available 
documentation, the micro-SD card slot on the IGEPv2 should be able to be 
used for this testing.

I tested reads and writes on the sd card on IGEPv2, it works, generating
interrupts.

Reading and writing is all done via IRQ 83 (for MMC1) and IRQ 86 (for MMC2). It would not exercise IRQ 384.

The /proc/interrupts that you posted showed...
83: 66 INTC mmc0 86: 12 INTC mmc1 92: 1 INTC musb_hdrc 336: 809 GPIO eth0 378: 0 twl4030 twl4030_usb 384: 0 twl4030 mmc0

IRQ 378 is a USB power system interrupt of some sort. The twl4030 family power interrupts for OMAP3 are in the range of IRQ 376 (TWL4030_PWR_IRQ_BASE) to IRQ 383 (TWL4030_PWR_IRQ_END).

IRQ 384 is the first GPIO pin on the twl4030. On the BeagleBoard, it's connected to the SD Card Detect circuit. I believe that is also true for the IGEPv2. The Level 2 GPIO interrupts (from the twl4030 family chip, not OMAP chip GPIO pins) are in the range of IRQ 384 (TWL4030_GPIO_IRQ_BASE) to IRQ 383 (TWL4030_GPIO_IRQ_END).

Note that the above ranges apply to all boards that use an OMAP3 chip. Of course future changes to the kernel's interrupt handlers can reassign any IRQ above 95. (OMAP3 chip hardware IRQs stop at 95. The rest are software assigned.)

My current dilemma is to figure out how to move the pieces of Angstrom 
that I want from the 2.6.32 kernel system to the 2.6.33 kernel ahead of 
the Angstrom train. :-(

We probably can get 2.6.31 to work, we just have to figure out what is
wrong.

Thanks for your willingness to help.

Regards,
Bob Feretich