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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29/4/2019 3:17 AM, Dmitry Torokhov wrote:
> 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.

Ah, of course. Okay, let's just have a mutex for this then. I'll send a v3.

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

It's a PXA3xx platform, and their interrupt controller lacks such a feature.


Thanks,
Daniel



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux