Re: [PATCH 2/2] input: touch: eeti: read hardware state once after wakeup

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Sun, Apr 28, 2019 at 09:50:35PM +0200, Daniel Mack wrote:
> On 28/4/2019 7:36 PM, Dmitry Torokhov wrote:
> > On Sun, Apr 28, 2019 at 09:18:46AM +0200, Daniel Mack wrote:
> >> On 23/4/2019 10:41 AM, Dmitry Torokhov wrote:
> >>> On Tue, Apr 23, 2019 at 06:51:32AM +0200, Daniel Mack wrote:
> >>>> Hi Dmitry,
> >>>>
> >>>> On 23/4/2019 5:17 AM, Dmitry Torokhov wrote:
> >>>>> On Mon, Apr 22, 2019 at 10:35:40AM +0200, Daniel Mack wrote:
> >>>>>> For systems in which the touch IRQ is acting as wakeup source, the interrupt
> >>>>>> controller might not latch the GPIO IRQ during sleep. In such cases, the
> >>>>>> interrupt will never occur again after resume, hence the touch screen
> >>>>>> appears dead.
> >>>>>>
> >>>>>> To fix this, call into eeti_ts_read() once to read the hardware status and
> >>>>>> to arm the IRQ again.
> >>>>>
> >>>>> Can you instead make the interrupt level-triggered?
> >>>>
> >>>> The hardware I'm working on doesn't support that unfortunately.
> >>>>
> >>>> In fact, the whole attn-gpio dance is there because of that, and the
> >>>> GPIO descriptor maps to the same pin that also causes the IRQ in my case.
> >>>
> >>> OK, if the interrupt controller is incapable of dealing with level
> >>> interrupts then we have to do what you propose.
> >>
> >> So you consider these patches for inclusion then? I'm just asking
> >> because I can't see them in your tree yet.
> > 
> > I was about to, but now I wonder if we need a mutex in the isr code now,
> > otherwise there is a chance it will be running concurrently when we are
> > resuming if interrupt does latch.
> 
> Actually, to address that, all we need to do is call into eeti_ts_read()
> before enable_irq(). See my v2.

This is still a bit racy as interrupt may come after you attempted to
read but before enable_irq() and then we need interrupt replaying code
to work reliably, which, as far as I understand, is not always the case.
I suppose we need at least add a comment that we rely on replays.

What kind of hardware is that? Is there no chance of making interrupt
controller handle level interrupts?

Thanks.

-- 
Dmitry