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?
Supposedly when the GPIO blocks enter idle with the debounce clock off,
they enter a state that basically links the input pad to the GPIO block's
SWAKEUP line. Pure combinational logic, no clocks. The TRM references,
in the 34xx TRM Rev. ZT [SWPU223T], are Figure 25-7 "Asynchronous Path",
Figure 25-9 "Wake-Up Request Generation", and Section 25.4.1.2
"Asynchronous Path: Wake-Up Request Generation".
So apparently, looking at these references, the following registers should
be configured:
1. at least one of GPIO_LEVELDETECT{0,1} or GPIO_{RISING,FALLING}DETECT
2. GPIO_WAKEUPENABLE
3. GPIO_IRQENABLE1
It seems highly suspicious to me that nothing in
set_24xx_gpio_triggering() in our GPIO code seems to touch the
WAKEUPENABLE register.
- Paul
