Re: [RFC PATCH] Input: gpio_keys: Fix suspend/resume press event lost

["ivan.khoronzhuk" <ivan.khoronzhuk@ti.com>]

On 01/22/2013 07:24 AM, NeilBrown wrote:
> On Mon, 21 Jan 2013 15:57:18 -0800 Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>
>> Hi Ivan,
>>
>> On Mon, Jan 21, 2013 at 03:15:14PM +0200, Ivan Khoronzhuk wrote:
>>> Rebased on linux_omap/master.
>>>
>>> During suspend/resume the key press can be lost if time of resume
>>> sequence is significant.
>>>
>>> If press event cannot be remembered then the driver can read the
>>> current button state only in time of interrupt handling. But in some
>>> cases when time between IRQ and IRQ handler is significant we can
>>> read incorrect state. As a particular case, when device is in suspend
>>> we press wakupable key and up it back in a jiffy, the interrupt
>>> handler read the state of up but the interrupt source is press indeed.
>>> As a result, in a OS like android, we resume then suspend right away
>>> because the key state is not changed.
>>>
>>> This patch add to gpio_keys framework opportunity to recover lost of
>>> press key event at resuming. The variable "key_pressed" from
>>> gpio_button_data structure is not used for gpio keys, it is only used
>>> for gpio irq keys, so it is logically used to remember press lost
>>> while resuming.
>> The same could happen if you delay processing of interrupt long enough
>> during normal operation. If key is released by the time you get around
>> to reading it you will not see a key press.
>>
>> To me this sounds like you need to speed up your resume process so that
>> you can start serving interrupts quicker.
>>
> Agreed.  When I was looking at this I found that any genuine button press
> would have at least 70msec between press and release, while the device could
> wake up to the point of being able to handle interrupts in about 14msec.
> That is enough of a gap to make it pointless to try to 'fix' the code.
>
> With enough verbose debugging enabled that 14msec can easily grow to
> hundreds, but then if  you have debugging enabled to can discipline yourself
> to hold the button for longer.
>
> Ivan: What sort of delay are you seeing between the button press and the
> interrupt routine running?  And can you measure how long the button is
> typically down for?
>
> NeilBrown

In my case I have the delay between the button press and the ISR
about 145ms. If the button down for 120ms the IRQ press event is
lost and if 160ms event is captured. I cannot speed up resume
process enough to guarantee correct work, so I wrote this fix.

-- 
Regards,
Ivan Khoronzhuk