Linux interrupt sharing (use of dev_id)

Article Title: linux interrupt sharing (use of dev_id ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

In my personal understanding, the Linux2.6 kernel can now process interrupt handlers in two modes: the old one mentioned above (non-shared disconnection ), A new mode that uses SHARED disconnection. It is analyzed from the functions used to register the interrupt handler. The function prototype is as follows:

Int request_irq (unsigned int irq,

Irqreturn_t (* handler) (int, void *, struct pt_regs *),

Unsigned long irqflags,

Const char * devname,

Void * dev_id );

Parameter 1: interrupt line number

Parameter 2: interrupt handler function pointer

Parameter 3: Flag mask (SA_INTERRUPT, SA_SAMPLE_RANDOM, SA_SHIRQ)

Parameter 4: When parameter 3 is SA_SHIRQ (shared disconnection), the other value is NULL.

When there are few computer devices, a possible disconnection may correspond to an interrupt processing program (non-shared disconnection). At this time, parameter 4 is NULL and is useless, however, with the increase of computer devices, it is unrealistic to have an interrupt line number corresponding to an interrupt processing program. At this time, a shared interrupt line number is used, and multiple devices use the same interrupt line number, all the handlers of the same Interrupt Device line number are linked to a linked list. In this way, when the next interrupt is generated by sharing the interrupt line number, the corresponding linked list of the handler will be traversed, however, this interrupt is generated between multiple devices that use the same interrupt line number. It is impossible to call all the processing programs in the linked list, this is the fourth parameter.

Because multiple devices share the same interrupt line number, when the interruption occurs, it depends on the fourth parameter dev_id, which must be unique, that is to say, it can be distinguished from the interruption caused by the device. It can be seen from the second parameter that this parameter is passed into the interrupt handler (the second parameter, when an interrupt occurs, if it is a shared interrupt line number, all the interrupt handlers corresponding to the linked list will be called, however, in each interrupt handler, check whether the device corresponding to the interrupt handler (parameter information and hardware support) is interrupted. If not, return immediately. If yes, the processing is complete. If no one in the linked list is yes, an error occurs.

Let's talk about the interrupt handler. Let's first look at the prototype:

Static irqreturn_t intr_handler (int irq, void * dev_id, struct pt_regs * regs );

Parameter 1: interrupt line number

Parameter 2: device information, unique and deterministic

Parameter 3: Information and status of the Processor register before interruption

Through the above analysis, we can see that parameter 1 (Interrupt line number) seems a bit redundant, because if it is a non-shared disconnection, the handler is directly called through the interrupt line number, it seems useless to pass this parameter in. If it is a shared disconnection, you can directly find the corresponding linked list of the interrupt handler through the interrupt line number, and traverse them one by one, it is useless to pass in. It should not be called. It is distinguished by the second parameter. Why should this parameter be retained? The answer is the questions left over from history, which may become useless in the future. As to why is it a historical question, we may have made some effort on the first question without the second parameter, since the second parameter has been added, the role of the first parameter becomes fewer and fewer.

If it is a shared interrupt line number, all interrupt handlers corresponding to the linked list will be called, but check the parameter information and hardware support of each interrupt handler first) is it because the device corresponding to the interrupt processing program is interrupted? If not, return immediately. If yes, the process is completed. If no one in the linked list is yes, an error occurs.