Possible driver bug?
Fernando
New Member Posts: 22 ✭
Hi.
After some researching trying to figure out why touchscreen driver for small displays (ads7846 and ads7846_device) does not work well on Up board, I am starting to think there could be some sort of bug in the current GPIO driver, regarding interrupts. The full description of the original problem could be find here. Basically, the problems is that after a falling edge, multiple interrupts are fired (hundreds of them en few seconds) until the entire driver crash.
Now, this driver seems to make use of the interrupts in a way, closedly adjusted of the examples I could find in Internet (this lines are not successive):
There is not much reference to the Interrupt API besides this code.
So my question is if someone has tested GPIO interrupts on Up board without an issue?.
Thanks.
After some researching trying to figure out why touchscreen driver for small displays (ads7846 and ads7846_device) does not work well on Up board, I am starting to think there could be some sort of bug in the current GPIO driver, regarding interrupts. The full description of the original problem could be find here. Basically, the problems is that after a falling edge, multiple interrupts are fired (hundreds of them en few seconds) until the entire driver crash.
Now, this driver seems to make use of the interrupts in a way, closedly adjusted of the examples I could find in Internet (this lines are not successive):
// Request a GPIO pin from the driver err = gpio_request_one(pdata->gpio_pendown, GPIOF_IN, "ads7846_pendown");
// maps the GPIO to an IRQ irq = irq ? irq : (gpio_to_irq(gpio_pendown));
// requests an interrupt and pass a pointer to handler function err = request_threaded_irq(spi->irq, ads7846_hard_irq, ads7846_irq, irq_flags, spi->dev.driver->name, ts);
There is not much reference to the Interrupt API besides this code.
So my question is if someone has tested GPIO interrupts on Up board without an issue?.
Thanks.
Comments
-
Hi
Thanks for raising this issue. It sounds like a possible bug alright, most likely in the UP platform driver. Speculating, I'd guess that the interrupt source isn't being masked properly for some reason after the first edge is detected and before the handler gets to finish running.
I wonder if you'd see a different behaviour by passing NULL instead of ads7846_irq to request_threaded_irq().
Anyway, this is something that we need to look into. Thanks again for raising it and for the information provided.
-Dan -
Hi Dan.
Do you mean not passing a handler to the interrupt, so no code is executed when it fires? -
No, I mean not passing the threaded handler 'ads7846_irq'. This should force 'ads7846_hard_irq' to be used instead.
Anyway, its just something I'm curious about. I don't expect it to fix anything, as the bug is most likely at a lower level.