Russell,
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 ?
> -----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.
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
