Hi Oleksij, On Tue, Jul 14, 2015 at 08:40:47AM +0200, external.Oleksij.Rempel wrote: > Hi Dmitry, > > On 13.07.2015 19:07, Dmitry Torokhov wrote: > >On Mon, Jul 13, 2015 at 02:49:38PM +0200, Dirk Behme wrote: > >>From: Oleksij Rempel <external.Oleksij.Rempel@xxxxxxxxxxxx> > >> > >>If zforce is not ready to process the interrupt, the touchscreen will > >>be lost forever. Make sure we enable the interrupt only if processing > >>is ready. > >> > >>Signed-off-by: Oleksij Rempel <external.Oleksij.Rempel@xxxxxxxxxxxx> > >>Signed-off-by: Dirk Behme <dirk.behme@xxxxxxxxxxxx> > >>--- > >> drivers/input/touchscreen/zforce_ts.c | 7 ++++++- > >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> > >>diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c > >>index 19dc297..a1889e5 100644 > >>--- a/drivers/input/touchscreen/zforce_ts.c > >>+++ b/drivers/input/touchscreen/zforce_ts.c > >>@@ -22,6 +22,7 @@ > >> #include <linux/slab.h> > >> #include <linux/input.h> > >> #include <linux/interrupt.h> > >>+#include <linux/irq.h> > >> #include <linux/i2c.h> > >> #include <linux/delay.h> > >> #include <linux/gpio/consumer.h> > >>@@ -741,6 +742,7 @@ static int zforce_probe(struct i2c_client *client, > >> struct zforce_ts *ts; > >> struct input_dev *input_dev; > >> int ret; > >>+ unsigned int irq; > >> if (!pdata) { > >> pdata = zforce_parse_dt(&client->dev); > >>@@ -835,6 +837,7 @@ static int zforce_probe(struct i2c_client *client, > >> init_completion(&ts->command_done); > >>+ irq = client->irq; > >> /* > >> * The zforce pulls the interrupt low when it has data ready. > >> * After it is triggered the isr thread runs until all the available > >>@@ -842,7 +845,8 @@ static int zforce_probe(struct i2c_client *client, > >> * Therefore we can trigger the interrupt anytime it is low and do > >> * not need to limit it to the interrupt edge. > >> */ > >>- ret = devm_request_threaded_irq(&client->dev, client->irq, > >>+ irq_set_status_flags(irq, IRQ_NOAUTOEN); > >Instead of playing with the flags should we simply request irq after we > >release the reset pin? > > Because we should be able to process the interrupt. If i put > request_irq after reset, some times the interrupt can be missed. OK, I see that enabling after reset is racy. But I am still confused why having IRQ enabled while reste pin is asserted results in lost touchscreen. Can you walk me through the sequence of events? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html