[Gta04-owner] Can't suspend: was Rfkill devices needed before suspend?

[NeilBrown]

I noticed just now that it often takes several attempts for my phone to
suspend - as I mentioned I don't notice unless I watch.  But I've been
watching.

So I hacked together something to report which interrupts are handled
immediately on resume:


diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 1fef061..8ff1f47 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -198,6 +199,7 @@ void __init ti81xx_init_irq(void)
 	omap_init_irq(OMAP34XX_IC_BASE, 128);
 }
 
+extern int foobar;
 static inline void omap_intc_handle_irq(void __iomem *base_addr, struct pt_regs *regs)
 {
 	u32 irqnr;
@@ -225,9 +227,15 @@ out:
 		irqnr = readl_relaxed(base_addr + INTCPS_SIR_IRQ_OFFSET);
 		irqnr &= ACTIVEIRQ_MASK;
 
+		if (irqnr == 7) printk("TWL IRQ triggered\n");
+		if (foobar) printk("foobar: %d\n", irqnr);
 		if (irqnr)
 			handle_IRQ(irqnr, regs);
 	} while (irqnr);
+	if (foobar) {
+		printk("foobar done\n");
+		foobar = 0;
+	}
 }
 
 asmlinkage void __exception_irq_entry omap2_intc_handle_irq(struct pt_regs *regs)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..939ef49 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -479,6 +479,7 @@ restore:
 	return ret;
 }
 
+int foobar = 0;
 static int omap3_pm_enter(suspend_state_t unused)
 {
 	int ret = 0;
@@ -491,7 +492,7 @@ static int omap3_pm_enter(suspend_state_t unused)
 	default:
 		ret = -EINVAL;
 	}
-
+	foobar = 1;
 	return ret;
 }
 


And collected results.

On 13 resumes (most were not expected) each one reports 2 interrupts.
One of the interrupts is always '95' - the 'gp timer' interrupt - not really
surprising.  I'm sure that isn't waking from suspend.

The others were:
  count IRQ
      5 11
      2 29
      1 74
      5 92

Looking these up in the OMAP3 TRM - pages 2419,2420 of my copy 
table 12-4:  Interrupt Mapping to the MPU Subsystem

I find:
  11 == PRCM module IRQ  (Power, Reset, Clock Management)
  29 == GPIO modules 1   (there are 6 GPIO modules, each with 32 GPIOs, so
                          this must be 0-31 I suppose)
  74 == UART module 3    (serial console)
  92 == High-Speed USB OTG controler.

The '29' is the AUX button which I used to wake-and-keep-awake the device
once it stopped spinning, so we can discount that.
The '74' is a one-off, so maybe that was an experimental error (maybe I
bumped a key?)

So I unplugged the USB cable and tried again.
Now the only unexpected interrupt I get is '11' - PRCM.

This is a nested interrupt. and can be anything listed in
   grep PRCM /proc/interrupts

In every case, both of these  (96 and 105) a triggered, and this is about the
only time that 105 is called.
105 is something to do with "IO Pads".  When the MPU is 'off' activity on the
various pads which are normally GPIOs or UART lines or whatever is routed to
the PRCM as simple 'IO Pad' signals so the device can be woken up.
So this could be almost anythingy....

However,
   grep WAKEUP /sys/kernel/debug/omap_max/*
shows that only mcspi1_cs2 has wakeup enabled.

# cat /sys/kernel/debug/omap_mux/mcspi1_cs2
name: mcspi1_cs2.gpio_176 (0x480021d2/0x1a2 = 0x4104), b ab1, t NA
mode: OMAP_PIN_INPUT | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4
signals: mcspi1_cs2 | NA | NA | sdmmc3_clk | gpio_176 | NA | NA | safe_mode


So this is the 3G wakeup GPIO.  However 
  grep wake_3G /proc/interrupts
shows that this has never fired.

I guess I could disable the WAKEUPENABLE on that and see what happens....
But not tonight.


This might not be the same as you problem of course, but the patch above
might be useful in confirming exactly what interrupt is keeping you from
going to sleep.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120406/90309574/attachment.bin>