Request threaded-only irqs with irrent_oneshot

Gitweb:

Http://git.kernel.org/linus/;a=commit;h=9b7e31bbf4bb58b12e11a7f24b7c3e48bbd2f4da

Commit: 9b7e31bbf4bb58b12e11a7f24b7c3e48bbd2f4da
Parent: 1cecc5cc0658e128bcad0b29edb96f286066571d
Author: Lars-Peter krasen <Lars <at> metafoo.de>
Authordate: Wed Jul 4 13:02:56 2012-0700
Committer: Dmitry torokhov <Dmitry. torokhov <at> gmail.com>
Commitdate: Wed Jul 4 13:12:19 2012-0700

Input: Request threaded-only irqs with ir1__oneshot

Since commit 1c6c69525b ("genirq: reject bogus threaded IRQ requests ")
Threaded irqs without a primary handler need to be requested
Irqf_oneshot, otherwise the request will fail.

.......

 

In Linux, interrupt processing is divided into top half (top half) and bottom half (bottom half). In the top half, it processes tasks with a higher priority and requires that the interruption time be as short as possible, after the processing is completed, the bottom half is activated and the remaining tasks are processed. There are three main processing methods: soft_irq, tasklet, and workqueue. They are used in different ways and applicable situations. Soft_irq is mainly used for subsystems where the minimum half execution time is urgent or important. Generally, it is not used for driver. Tasklet and work queue are usually used in common drivers. The main difference is that tasklet interrupts context execution while work
Queue is in the process context, so you can perform operations that may be sleep.
In 2.6.30, there was a period of Interrupt thread in the RT tree of Ingo Molnar and finally merge to mainline. In this case, if the request_threaded_irq application is interrupted, the handler is not executed in the interrupt context, but in the newly created thread. In this way, the handler is like executing workqueue, it has all the features of work queue, but saves the trouble of creating, initializing, and scheduling workqueue. Processing is very simple. Let's take a look at this interface:

Int trim (unsigned int IRQ, irq_handler_t handler, irq_handler_t thread_fn, unsigned long irqflags, const char * devname, void * dev_id) and request_irq are very similar, IRQ is the interrupt number, handler is the first code to be executed in the event of an interruption. It is very similar to the top half. This function returns irq_wake_thread to wake up the interrupt thread. It is generally set to null, use the default processing provided by the system. Thread_fn is the handler to be executed in the thread, which is very similar to the bottom half. The last three parameters are basically the same as request_irq. Irqsflags adds a new identifier, irqf_oneshot, to indicate that the interrupt is enabled after the interrupted thread is executed. This identifier is very useful; otherwise, the interrupt may always be executed at the top half, the thread cannot be interrupted. For example, if the gpio level is interrupted, if this bit is not set, the interrupt will be opened after the top half of the execution is complete. At this time, the execution is interrupted immediately because the level does not change, and there is no chance to process the thread. The following is an example to describe its application. On the mobile phone platform, the monitoring plug-in usually changes the baseband gpio level through a mechanical change in the plug-in hole of the headset. The plug-in process is performed during the interrupt of the gpio. However, there is usually a jitter process during earphone insertion, which requires dejitters. The simplest way is to delay a period of time (for example, 200 ms) after the interruption occurs, and then check whether the gpio status is stable to determine whether the insertion is effective. If you have to use workqueue in the old interrupt mode, you need to activate a workqueue of delay ms in the top half, and then check it in workqueue. With the thread-based processing method, you only need to sleep 200 ms in thread_fn, and then check it. Look, it's that simple!