On Fri, Dec 21, 2018 at 09:42:54PM +0100, Marek Vasut wrote: > On 12/21/2018 09:30 AM, Dmitry Torokhov wrote: > > On Fri, Dec 21, 2018 at 03:30:36AM +0100, Marek Vasut wrote: > >> On 12/21/2018 02:44 AM, Dmitry Torokhov wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> On Thu, Dec 20, 2018 at 09:43:00PM +0100, Marek Vasut wrote: > >>>> Get rid of the workqueue, just spawn a threaded IRQ and handle > >>> > >>> Not really... > >> > >> Fixed > >> > >>>> @@ -279,7 +275,6 @@ static int ili210x_i2c_remove(struct i2c_client *client) > >>>> struct ili210x *priv = i2c_get_clientdata(client); > >>>> > >>>> sysfs_remove_group(&client->dev.kobj, &ili210x_attr_group); > >>>> - free_irq(priv->client->irq, priv); > >>> > >>> Now this is unsafe, as interrupt is released after work is cancelled and > >>> interrupt may schedule work again. > >>> > >>> If we can prove that it works, I liked your original change better. Can > >>> you try addind sleep of let's say 5 seconds to the interrupt thread > >>> just before it returns and see if you get release events reported. The > >>> idea is to verify the sequence: > >>> > >>> - chip raises interrupt line > >>> - ISR reads chip state > >>> - in response chip makes intterrupt line inactive? > >> > >> No, the IRQ line stays active as long as there's touch event happening > >> (someone has a finger on the touch panel). > > > > Sorry for asking the same question over and over, but have you verified > > that the touch controller definitely does not raise interrupt on release > > (the procedure that I outlined above should help determining that)? > > No problem. I had a scope connected to the IRQ line, the line goes LOW > on touch-down and high on touch-release. OK, so we definitely need a work or a timer to handle release. Thanks. -- Dmitry
