Re: OMAP3EVM not booting on l-o master

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

On Fri, 2012-04-27 at 16:15 -0700, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > On Tue, 2012-04-24 at 10:07 -0700, Kevin Hilman wrote:
> 
> [...]
> 
> >> > 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.
> 
> OK
> 
> >> 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. 
> 
> hmm, I thought there was a flag for disabling the auto-enable feature...
> /me looks
> 
> Yup, from <linux/irq.h>
> 
>  * IRQ_NOAUTOEN			- Interrupt is not automatically enabled in
>  *				  request/setup_irq()
> 
> With that, we can just set all the PRCM IRQs to be disabled until
> explicitly enabled using enable_irq().  The following patch (only boot
> tested on OMAP3530/Overo and OMAP4430/Panda) should take care of it.
> 
> Do you think that should solve this problem?

Yea that works. However your patch implements the disable for all PRCM
interrupts, and this is only needed for the IO event on OMAP3. How about
something like this:

--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -691,6 +691,8 @@ static int __init omap3_pm_init(void)
                goto err2;
        }
 
+       enable_irq(omap_prcm_event_to_irq("io"));
+
        ret = pwrdm_for_each(pwrdms_setup, NULL);
        if (ret) {
                pr_err("Failed to setup powerdomains\n");
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index b8962fe..2b12bb9 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -15,6 +15,7 @@
 #include <linux/errno.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/irq.h>
 
 #include "common.h"
 #include <plat/cpu.h>
@@ -339,9 +340,13 @@ static void __init omap3_enable_io_wakeup(void)
 
 static int __init omap3xxx_prcm_init(void)
 {
+       int ret = 0;
+
        if (cpu_is_omap34xx()) {
                omap3_enable_io_wakeup();
-               return
omap_prcm_register_chain_handler(&omap3_prcm_irq_setup);
+               ret =
omap_prcm_register_chain_handler(&omap3_prcm_irq_setup);
+               irq_set_status_flags(omap_prcm_event_to_irq("io"),
+                       IRQ_NOAUTOEN);
        }
-       return 0;
+       return ret;
 }