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. Thanks. -- Dmitry
