I have been reading LDD and Also writing a driver for GPIO on RPI. I have managed to detect interrupt on a GPIO pin and read 8 bits that come after that interrupt.
A common suggestion in the book is to rarely disable the interrupts. But it feels tempting to just disable them and do all the work then re enable them as it is easy to work with.
So, are there really any scenarios where interrupts are disabled.
Follow up Question: If interrupts are not disabled, and deffered processing using lets say work queues is used then please point out any existing driver in linux kernel that uses this approach for studying. I want to know the practical way i.e coding wise how it is done.
Thanks
In any driver, it is not a good practice to disable the interrupts globally. Let the kernel handle it. You are free to disable the hardware interrupt for the particular GPIO line in the hardware (by writing some registers mostly) whenever you want. Make sure you have a mechanism to re enable them when you might need it again. While writing a driver, you need not use the local_irq_disable() at all. If that is what you are asking about.
If you have registered an interrupt handler for the particular IRQ, the handler will get called when there is an interrupt. The handler would be called with interrupts already disabled. And would be in an atomic context. You need to complete the work as soon as possible and return from the handler. If you need to schedule a work queue, schedule_work() needs to be used before you return. Tasklets are old and work queues are the preferred ones. If you grep for schedule_work under drivers/char (char drivers are expected to be simple) you can find some of them using the mechanism. drivers/char/sonypi.c is an example. sonypi_report_input_event() called from sonypi_irq() which is an interrupt handler calls schedule_work().