Re: OMAP3EVM not booting on l-o master

[Tero Kristo <t-kristo@ti.com>]

On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
> Hi Tero,
> 
> Tero Kristo <t-kristo@ti.com> 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@ti.com>
> > 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@ti.com>
> 
> 
> Doesn't this mean that even on a !PM kernel that IO events might still
> be firing for nothing?

I actually disabled the IO handler in !PM kernel, as I thought this
would be a problem there.

> Seems like it would be better to ensure that these interrupts are just
> disabled until the PM core initializes and can enable them.

I thought about this but I couldn't figure out a clean way to do this.
If I do irq_request, it automatically enables the interrupt, and if
there is an interrupt pending it will fire immediately and get stuck. I
can of course do some really nasty hackery for disabling all interrupts
when requesting it and then manually disabling it before enabling
interrupts again... but this does not look too nice imo.

-Tero