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. > Just want to understand exactly the controller behavior. Sure > Thanks. > -- Best regards, Marek Vasut
