Paul Walmsley <p...@pwsan.com> writes: > On Mon, 30 Jan 2012, Kevin Hilman wrote: > >> Grazvydas Ignotas <nota...@gmail.com> writes: >> >> > On Mon, Jan 30, 2012 at 9:36 PM, Kevin Hilman <khil...@ti.com> wrote: >> >> Grazvydas Ignotas <nota...@gmail.com> writes: >> >> >> >>> On 3.2 (I think some earlier versions too), with CONFIG_CPU_IDLE >> >>> enabled GPIO based buttons are not working properly on OMAP3 pandora, >> >>> button presses are almost never registered. The buttons are connected >> >>> GPIO bank4 and have hardware debounce feature enabled. >> >>> >> >>> Doing either of the following solves (or hides) the problem: >> >>> - disabling CPU_IDLE in kernel config >> >>> - disabling debounce for the buttons >> >>> - running a program spinning a loop on the CPU >> >>> >> >>> From what I can see in the code debounce clock is disabled when >> >>> entering idle, can those GPIOs work without debounce clock? >> >> >> >> Yes, the clock is only for the debounce feature, but the GPIOs are >> >> capable of wakeups and interrupts with the debounce clock disabled. >> > >> > Hmm but it doesn't work here (OMAP3530 ES2.1), /proc/interrupts >> > doesn't increase when I hit buttons unless something else is happening >> > at the same time. I wonder if I'm missing something here, does it all >> > work for you with debounce on? >> >> Yes. >> >> Specifically, I tested on a n900 which has several GPIOs in the board >> file (board-rx51.c) with debounce enabled. >> >> When I push the button (or slide the switch in this case), I see >> /proc/interrupts incrementing on an idle system with CPUidle enabled. >> >> The same GPIOs can also bring the system out of suspend (debounce clocks >> are disabled on suspend also.) > > That's probably I/O ring/pad wakeups happening there, not GPIO wakeups. > GraÅžvydas, you are referring to the case where the CORE powerdomain is on, > but the GPIO IP block is idle?
Right good point. If CORE is powerdomain is staying on, you might also have a look at the "GPIO module-level wakeups not always working" item in the "Known problems" section of the OMAP PM wiki: http://elinux.org/OMAP_Power_Management#Known_Problems It might be the case that haven't done a request_irq() + enable_irq_wake() for those GPIOs. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html