On Tue, Jan 31, 2012 at 1:34 AM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> On Mon, 30 Jan 2012, Kevin Hilman wrote:
>
>> Grazvydas Ignotas <notasas@xxxxxxxxx> writes:
>>
>> > 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?
>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
