The basic framework of the interrupt subsystem of the Linux system (1)

Interrupt is the most commonly used function. Whether it is a single-chip microcomputer or a Linux system, interrupts are needed, and a deep understanding of it is very necessary.

Why do you need interrupts?

Answer: The speed of the processor is much faster than that of the peripherals, and the core must handle other tasks. Only when the peripherals are ready, the CPU turns to handle the affairs of the peripherals.

The general communication methods are: polling (polling) and interrupt (interrupt). Except for network transmission, which is suitable for polling, interrupts are generally used for other situations.

interrupt classification

Interruption means that during the normal operation of the CPU, due to internal and external events or events pre-arranged by the program, the CPU temporarily stops the running program and turns to the program that serves the internal or external pre-arranged event. Return to continue execution of the program that was temporarily interrupted.

The interrupt that is often said is actually the first type, asynchronous interrupt.

The trap is the system call, which falls from the user state to the kernel state, such as calling open, write and other system calls, which is also considered an interruption. These two are normal, so it will return to the next instruction.

The fault is that when the memory page is missing, etc., it will return to the current instruction and continue to execute to see if the kernel will be repaired. If it cannot be repaired, it will hang up. Termination means that the system hangs directly.

Interrupt Subsystem Hardware Architecture

In a complete device, the interrupt-related hardware can be divided into three categories, they are: device, interrupt controller and CPU itself.

Device : The device is the source of the interrupt. When the device needs to request a certain service, it will initiate a hardware interrupt signal. Usually, the signal will be connected to the interrupt controller for further processing. In modern mobile devices, the device that initiates the interrupt can be located outside the SoC (system-on-chip) chip or inside the chip, because most SoCs currently integrate a large number of hardware IPs, such as I2C, SPI, Display Controller, etc., are internal interrupt sources.

Interrupt controller : The interrupt controller is responsible for collecting interrupts initiated by all interrupt sources. Almost all existing interrupt controllers are programmable. By programming the interrupt controller, we can control the priority of each interrupt source, interrupt The electrical type can also turn on and off a certain interrupt source. In the smp system, it can even control which CPU a certain interrupt source is sent to for processing. For ARM-based SoCs, the most used interrupt controller is VIC (Vector Interrupt Controller). After entering the multi-core era, the application of GIC (General Interrupt Controller) has gradually increased. The interrupt controller of STM32 microcontroller is called NVIC, the interrupt controller of ARM architecture is generally GIC, and different architectures have different interrupt controllers.

CPU : The part that finally responds to interrupts. It controls and manages each interrupt in the system through the programming operation of the programmable interrupt controller. When the interrupt controller finally determines that an interrupt can be processed, it will Notify one or several cpus to process the interrupt, although the interrupt controller can notify several cpus to process a certain interrupt at the same time, in fact, only one cpu will respond to the interrupt request in the end, but the specific Which cpu responds may be random, and the interrupt controller guarantees this feature in hardware, but it also depends on the software implementation of the operating system for the interrupt system.

Why do you need an interrupt controller?

What the CPU has to do is mainly computing. A CPU has many interrupts that can be used, and there are priorities among them. Due to too many interrupts, we need to enter the interrupt controller before the interrupt enters the CPU processing, and let the interrupt controller control the interrupt priority, trigger mode, enable and disable, etc., to reduce the burden on the CPU and let the CPU focus on computing.

Cascading of Interrupt Controllers

Depending on the number of interrupts, interrupt controllers can be cascaded to meet demand. For example, the EINT interrupt controller or other interrupt controllers will be connected before the GIC interrupt controller to control different interrupts hierarchically.

There are two types of cascading of interrupt controllers:

For machine-level cascading, the cascading initialization code is of course located in the board's initialization code (arch/xxx/mach-xxx), because as long as this board or SOC device is used, this sub-controller must be used.

Cascading at the device level, because the device is not necessarily a standard device of the system, so the cascading operation of the interrupt controller should be implemented in the driver of the device.

For the cascading of machines and equipment, because the kernel can conveniently reserve the corresponding irq_desc structure and irq number for the sub-controller thanks to the knowledge of the hardware connection information of the sub-controller in advance, the processing is relatively simple.

The cascading at the device level is different, the driver must dynamically determine the irq number and irq_desc structure of each sub-device in the combined device. I only discuss cascading at the machine level, the same principle can be used for device-level association.

Interrupt Subsystem Architecture

The architecture of the entire interrupt subsystem is divided into 4 layers, the bottom layer (the fourth layer) is hardware, including CPU and interrupt controller. The third layer is the driver of the CPU and the driver of the interrupt controller, which is the responsibility of the original chip factory. The second layer is the general interrupt processing module provided by the Linux kernel. The significance of this layer is that it is hoped that the driver written by the user on the first layer will be more convenient when transplanting, keep the interface unchanged, and prevent users from using the original chip directly. API, but the API of Linux. The first layer is the driver written by the driver engineer every day.

Guess you like

Origin blog.csdn.net/weixin_41114301/article/details/130944135