(resending wrapped message) Russell, > -----Original Message----- > From: Shilimkar, Santosh > Sent: Saturday, June 20, 2009 8:55 PM > To: 'Tony Lindgren'; 'linux-omap@xxxxxxxxxxxxxxx' > Cc: 'Russell King - ARM Linux' > Subject: [ARM][OMAP] TWL4030 IRQ > > Just to brief you all, I came across a dead lock scenario on > the arm-smp kernel. After discussing with Russell on mailing > list, the actual bug seems be located in twl4030 IRQ implementation. > > Initially I was suspecting the arm-generic area and hence > didn't include linux-omap list in the mail thread > > For more information on this issue, please read this email thread. > http://marc.info/?l=linux-arm-kernel&m=124550947525299&w=2 > > I will create a patch for "twl4030" and also would be > correcting upcoming "twl6030" accordingly. > > If anyone on this mailing list has any other opinion, please > react to the email thread. After digging a bit, the proposed twl_irq change would need some major changes. 1. All the T2(TWL)drivers ( rtc, madc, bci, gpio, keypad, usb, mmc)needs modification.Currently twl_irq fw implements kind of "twl4030_irq_chip" which allows all the T2 drivers to get virtual interrupt numbers and can make use of standard "request_irq" linux api. 2.Above also helps to have useful entries like /proc/interrupts/rtc etc. With proposed change this also won't be available. 3. Register/unregister irq handlers to T2 from all the drivers On the reported lock-up issue, I tried alternative to call mask/unmask functions with disabling local cpu interrupts. This worked for me but not sure whether it is entirely correct. Something like this: static void handle_twl4030_pih(unsigned int irq, irq_desc_t *desc) { + unsigned long flags; + /* Acknowledge, clear *AND* mask the interrupt... */ + local_irq_save(flags); desc->chip->ack(irq); + local_irq_restore(flags); complete(&irq_event); } Do you think above approach is fine to get around the spin-lock lockup issue ? Regards, Santosh-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
