[Samsung Galaxy Nexus] Chirality:
Just noticed something interesting while looking over the Galaxy Nexus kernel code (the release version, before volume fixes etc.) Pretty much all of the most recent commits have been attempts at fixing some kind of bug with gpio and interrupts. This is starting to sound like a software bug to me, there seems to be some pernicious problem with handling IO with the OMAP4 that Google's been trying to fix up until it was released, but it seems it wasn't ready in time.

commit e2433f2f565b58b5b30ae3059120334513d4f6af
Author: Colin Cross <ccross@android.com>
Date: Fri Nov 11 16:58:03 2011 -0800

Revert "gpio: omap: don't clear triggering values when masking an interrupt"

This reverts commit 79db3e168d42608bd057b12fd805f8f43c648c80.

commit bced3b581bfd3f8585f55d9625bd20e96ddd0f0e
Author: Colin Cross <ccross@android.com>
Date: Fri Nov 11 16:22:42 2011 -0800

ARM: omap4: gpio: abort suspend if a level wake interrupt is pending

If a level wake interrupt arrives after disable_irq has been called
but before suspend, the interrupt will be masked. The omap gpio
driver erases all triggering information when masking an interrupt.
Track the triggering state of gpio interrupts, and abort suspend
if a masked wakeup interrupt is active when suspending.

Change-Id: I117b592d21c455074796deaea8148edf0947eb35
Signed-off-by: Colin Cross <ccross@android.com>

commit 79db3e168d42608bd057b12fd805f8f43c648c80
Author: Colin Cross <ccross@android.com>
Date: Thu Nov 10 22:24:14 2011 -0800

gpio: omap: don't clear triggering values when masking an interrupt

The level/edge triggered bits should not be cleared when masking
an interrupt, they are needed during suspend to configure wakeup
interrupts. _set_gpio_triggering(IRQ_TYPE_NONE) was probably being
called because _set_gpio_irqenable(0) doesn't work correctly - it
enables the interrupt instead of disabling it.

Fix _set_gpio_irqenable(0) to properly disable the interrupt, and
remove the call to _set_gpio_triggering(IRQ_TYPE_NONE) in
gpio_mask_irq.

Change-Id: I652072dbf9a15e38b29095b153a31a3ebd37310b
Signed-off-by: Colin Cross <ccross@android.com>

commit d705e3d36fca3bf468e447badb376217fcdb0888
Author: Colin Cross <ccross@android.com>
Date: Thu Nov 10 13:27:35 2011 -0800

gpio: omap: fix gpio transitions to off mode

When transitioning to off mode, it is possible that the powerdomain
that contains the gpio block does not transition due to another
clock domain being on. In this case, we must do the same
configuration on the gpios as in the non-off mode case.

Modify omap2_gpio_set_edge_wakeup to use different variables
to save context vs. omap_save_context, and both set the edge
wakeups and call pm_runtime_put_sync when going to off mode.

Change-Id: I2890f7f3dd2c3dfe493cf748a523004a76e560c2
Signed-off-by: Colin Cross <ccross@android.com>

commit dccb15aac78a00f30b3cf77af13d9648dd6e7a75
Author: Nishanth Menon <nm@ti.com>
Date: Tue Nov 8 11:55:55 2011 -0600

OMAP4: PM: move GPIO restore before removing I/O isolation

Restore GPIO before removing the I/O isolation. Original code
restored GPIO just after removing I/O isolation. this code was modified
in 4167a91d2db65b09b74a405cafa3df2f17d55bd4
(ARM: omap2+: gpio: simplify updating gpios in off vs. retention)
to be after Smartreflex AVS re-enable, which increases the risk of
GPIO glitch.
instead, move the GPIO restore to before the I/O isolation is released
to ensure that there is no potential glitch in the system.

Change-Id: I220ed73ecb0a88cb45a2cd741cd9fe93fa4cae55
Reported-by: Aish Dubey <aish@ti.com>
Reported-by: Vinay Amancha <vinaykumar@ti.com>
Reported-by: Vinay Chaurasia <vinaych@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>