Re: GPIO debounce problems on 3.2

[Kevin Hilman <khilman@ti.com>]

Paul Walmsley <paul@pwsan.com> writes:

> On Mon, 30 Jan 2012, Kevin Hilman wrote:
>
>> Grazvydas Ignotas <notasas@gmail.com> writes:
>> 
>> > On Mon, Jan 30, 2012 at 9:36 PM, Kevin Hilman <khilman@ti.com> wrote:
>> >> Grazvydas Ignotas <notasas@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html