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

[ivan.khoronzhuk]

On 01/22/2013 07:24 AM, NeilBrown wrote:
> On Mon, 21 Jan 2013 15:57:18 -0800 Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/