On Tue, Jan 31, 2012 at 1:34 AM, Paul Walmsley [off-list ref] wrote:

On Mon, 30 Jan 2012, Kevin Hilman wrote:

quoted

Grazvydas Ignotas [off-list ref] writes:

quoted

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.

Thanks for testing. Which kernel was that on, and what .config?

quoted

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?

I think so, it's just after boot with cpuidle enabled.
/debug/pm_debug/count seems to confirm it.

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".

ok..

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

According to some /dev/mem hacking, all these have corresponding bits
set.. And as soon as I clear corresponding bit in GPIO_DEBOUNCENABLE
(using the same /dev/mem hacking method), it starts working. When it's
set, even GPIO_DATAIN
isn't updating in realtime.


-- 
Gražvydas
--
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