Hi Tero, Tero Kristo <t-kristo@xxxxxx> writes: > On Fri, 2012-04-06 at 07:52 +0000, Mohammed, Afzal wrote: >> Hi Paul, >> >> On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: >> > Perhaps you might be willing to add some debugging to omap_mux_late_init() >> > to find out what part of that function is causing it to hang? >> >> It is getting hung as interrupt handler "omap_hwmod_mux_handle_irq" >> is being repeatedly called. >> > > Hi Afzal, > > can you try the attached patch with this branch and omap3evm board? I > don't have the board myself so I can't test it myself (I tested this > with omap3beagle and it works with that one.) Thanks for digging into this problem and coming up with a proposed solution. Some questions below... > > -Tero > > > From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001 > From: Tero Kristo <t-kristo@xxxxxx> > Date: Mon, 23 Apr 2012 12:14:46 +0300 > Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler > > PRCM IO interrupts are handled with a shared interrupt handler logic. > Currently hwmod_io is processing the actual event, but the acking > of the IO wakeups is done from the PM code with a separate handler. > If a wakeup event is detected during init before the PM code is in > place, the interrupt handler can hang in an infinite loop. Fix this > by removing the pm_io handler, and calling its functionality from > within the hwmod_io handler. This fix applies only to OMAP3, as > OMAP4 does not have similar wakeup handling logic. > > Signed-off-by: Tero Kristo <t-kristo@xxxxxx> Doesn't this mean that even on a !PM kernel that IO events might still be firing for nothing? Seems like it would be better to ensure that these interrupts are just disabled until the PM core initializes and can enable them. Kevin -- 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
