On Wed, Feb 1, 2012 at 8:41 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: > On Wed, 1 Feb 2012, Grazvydas Ignotas wrote: > >> On Wed, Feb 1, 2012 at 8:06 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: >> > On Tue, 31 Jan 2012, Paul Walmsley wrote: >> > >> >> Well, whether it's in or out of idle, I'll bet the DEBOUNCENABLE >> >> bits are still set to 1 while the debounce clock is off :-( >> > >> > Along these lines, you might try patching omap2_gpio_prepare_for_idle() to >> > turn off the DEBOUNCENABLE bits? >> >> Yes that helps. I guess I'll carry this in pandora tree, at least >> we'll have debounce while more demanding programs/games are running. > > Yep definitely. When only I/O wakeups can occur on those GPIO lines (when > CORE/PER is in a low-power state), they are intrinsically debounced :-) > So it should be fine. You are re-enabling the DEBOUNCENABLE bits in > omap2_gpio_resume_after_idle() I assume? If so, that should be a good > workaround for mainline too. To follow up on this, it appears clearing DEBOUNCENABLE in omap2_gpio_prepare_for_idle (or omap_gpio_runtime_suspend in 3.4) and reenabling on resume causes some sort of irq storm, I get ~50 irqs on key press/release for given GPIO, which causes CPU usage spikes, but no duplicate input events, curiously. Obviously this is not good for UIs and games, so I have nothing left but to disable hardware debounce now :( -- Gražvydas -- 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
