Re: [PATCH 2/3] Input: zforce - enable irq only if we are ready to process it

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

 



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



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux