On 14/5/2019 5:12 AM, Dmitry Torokhov wrote:
> Hi Daniel,
>
> On Mon, May 06, 2019 at 04:52:19PM +0200, Daniel Mack wrote:
>> Hi Dmitry,
>>
>> Is this one good to go in? WDYT?
>
> I wonder if we should combine the 2 and have something like below.
Sure, looks fine to me, except for one small yet important thing - see
below.
> Input: eeti_ts - read hardware state once after wakeup
>
> From: Daniel Mack <daniel@xxxxxxxxxx>
>
> For systems in which the touch IRQ is acting as wakeup source, and that do
> not support level-driven interrupts, 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, check for the assertion of the attn gpio, and read form the
> controller once in the resume path to read the hardware status and
> to arm the IRQ again.
>
> Introduce a mutex to guard eeti_ts_read() against parallel invocations
> from different contexts.
>
> Signed-off-by: Daniel Mack <daniel@xxxxxxxxxx>
> Reported-by: Sven Neumann <Sven.Neumann@xxxxxxxxx>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
> ---
> drivers/input/touchscreen/eeti_ts.c | 71 ++++++++++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 15 deletions(-)
[...]
> static void eeti_ts_start(struct eeti_ts *eeti)
> {
> + mutex_lock(&eeti->mutex);
> +
> eeti->running = true;
> - wmb();
> enable_irq(eeti->client->irq);
> +
> + /*
> + * Kick the controller in case we are using edge interrupt and
> + * we missed our edge while interrupt was disabled. We expect
> + * the attention GPIO to be wired in this case.
> + */
> + if (eeti->attn_gpio && gpiod_get_value_cansleep(eeti->attn_gpio))
> + eeti_ts_read(eeti);
> +
> + mutex_lock(&eeti->mutex);
If you turn the above into a mutex_unlock(), I'm happy :)
Thanks,
Daniel
