A method for sharing interrupts under Linux

When debugging a chip in the previous time, encountered a strange problem: as long as the board to insert a PS2 keyboard, boot the kernel system may enter the serial interrupt function to execute, after a while the system will panic not down to continue execution. Later after analysis of the problem when the panic stack, with the help of Ejtag tools, read this time the serial port interrupt status bit, unexpectedly found that the serial port did not really interrupt. Then, the serial port itself is not interrupted, how the kernel will run to the serial Port Interrupt service function to execute it?

We know that Linux interrupts can be divided into I/O interrupts, clock interrupts, and processor-to-core interrupts. Where I/O interrupts are an important way for Linux systems to respond to external IO events. Although different platforms and architectures are implemented differently, they support different devices sharing the same interrupt vector. For example, in a PCI bus structure, several devices can share the same IRQ line, that is, they share an interrupt number, and their interrupt service routines hang on the interrupt number. When the CPU responds to this IRQ, it checks the routines that hang on the interrupt vector one at a time, and executes those routines that are actually interrupted. But the serial port obviously does not belong to the PCI, cannot use the PCI interrupt line and the interrupt pin register, that is what causes kernel panic?

With these questions, and hardware engineers and chip design colleagues in-depth discussion of the various possibilities, finally combined with the chip board schematic diagram, found that the low-speed equipment on the board is integrated in the chip, these low-speed devices include serial, LPC is only controller, SPI control, I²C Controller, NAND controller, etc. Where the CPU UART and LPC interrupt signals are routed to the interrupt pin of the same CPU. The specific connection diagram is shown below:

The left-most part can be seen, CPU UART and CPU LPC Controller interrupt request signal after logic or, output to the CPU chip interrupt Pending Bit2. Once the CPU detects that any one of the interrupt Pending bits is set, it queries each interrupt Pending bit according to the order of the contract and executes the interrupt service routines that are driven by the device on the bit to the bits.

In the old version of the board design, the CPU LPC did not pick up any devices, then did not encounter the problem mentioned earlier. Later, due to customer demand, the board on the CPU LPC port can be connected to the PS2 keyboard and mouse, the problem is also exposed. Therefore, I guess the root cause of the problem is that there is no processing of interrupts for shared IP2 connected to a device on LPC. According to this idea, the previous interrupt distribution processing function was checked, and it was found that only DO_IRQ (58) was called when processing IP2. Refer to the serial port driver code in the kernel to know that the first CPU UART interrupt number by default is 58. So in this case, once the PS2 keyboard or mouse is connected to the interrupt signal, the existing code will be executed indiscriminately to execute DO_IRQ (58). Obviously, this is not the desired behavior, and it is necessary to query the respective interrupt status bit to detect the interruption of that device in the end. In the latest Linux 4.2 kernel Trunk branch, we can still find this part of the code that needs to be perfected: arch/mips/loongson64/loongson-3/irq.c:

void Mach_irq_dispatch (unsigned int pending)

{

if (Pending & CAUSEF_IP7)

DO_IRQ (LOONGSON_TIMER_IRQ);

#if defined (CONFIG_SMP)

else if (Pending & CAUSEF_IP6)

Loongson3_ipi_interrupt (NULL);

#endif

else if (Pending & CAUSEF_IP3)

Ht_irqdispatch ();

else if (Pending & Causef_ip2)

DO_IRQ (LOONGSON_UART_IRQ);

else {

Pr_err ("%s:spurious interrupt\n", __func__);

Spurious_interrupt ();

}

}

Additionally, the interrupt signal on the LPC in the chip is level-triggered, according to the definition of the LPC configuration register, when the interrupt is complete, the LPC SIRQ needs to be cleared, which requires adding functions such as interrupt ack and EOI for the response. In contrast, the interrupt on the serial port compatible with NS16550A is an edge trigger and does not require the program to clear: when the transmit save register is empty, the bit 1 of the serial port ISR will be set up, and once the data is written to the transfer save register, the bit will be cleared out; When the number of characters in the receive FIFO reaches the trigger level, the ISR bit 2 is set up until the program reads the receive FIFO.

According to the above two points of thinking, modified the code of the response, recompile the kernel, re-done a lot of tests, did not reproduce the problem mentioned earlier. In this example, we can see that, in addition to the mechanism of sharing interrupt vectors with PCI interrupts, there are cases where interrupt signals from different physical devices are routed to the same interrupt pin but use different interrupt numbers. In response to this situation. Engineers need a comprehensive chip structure, hardware connectivity, in-circuit and core interrupt processing process, comprehensively consider a variety of situations, give a perfect, robust solution. But comparing the similarities and differences between the two, it is not difficult to find that the essence is still the same: regardless of whether the interrupt number is the same, any route to the CPU internal interrupt or external interrupt controller on the device, should enjoy the opportunity to be served, can not be omitted.

This article is from the "Store Chef" blog, so be sure to keep this source http://xiamachao.blog.51cto.com/10580956/1690309

A method for sharing interrupts under Linux