Possible driver bug?

Options
Fernando
Fernando New Member Posts: 22 ✭
in UP Board Linux
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):
// 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.
· Share on FacebookShare on Twitter

Comments

  • Dan O'Donovan
    Dan O'Donovan Administrator, Moderator, Emutex Posts: 241 admin
    Options
    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
    · Share on FacebookShare on Twitter
  • Fernando
    Fernando New Member Posts: 22 ✭
    Options
    Hi Dan.

    Do you mean not passing a handler to the interrupt, so no code is executed when it fires?
    · Share on FacebookShare on Twitter
  • Dan O'Donovan
    Dan O'Donovan Administrator, Moderator, Emutex Posts: 241 admin
    Options
    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.
    · Share on FacebookShare on Twitter

Categories