Detailed analysis of Linux device driver interrupts

First, the preface

There are two types of Linux interrupts: soft interrupts and hard interrupts. To make a statement, the soft and hard meaning here refers to software-related and hardware-related, rather than interruption of software implementations or hardware implementations.

Soft interrupts are "signaling mechanisms." Soft is not software interruption. Linux through the signal to generate a variety of interrupt operations on the process, we now know a total of 31 signals, the details of which are skipped here, interested readers can refer to the relevant reference [1]. In general, soft interrupts are caused by the triggering events of kernel mechanisms (such as process timeouts), but it is important not to overlook the large number of soft interrupts that are also due to hardware-related interrupts, such as hardware-related hard interrupts that are notified when a hardware interrupt is generated on the printer port. A hard interrupt creates a soft interrupt and is sent to the operating system kernel, which wakes up the process of sleep in the printer task queue based on this soft interrupt.

A hard interrupt is the usual "interrupt handler," which deals directly with the interrupt signal sent by the hardware. When a hard interrupt receives the interrupt signal it should handle, go back to the device's own device and look at the status register to see what's going on and do the appropriate action. For soft interrupts, we do not discuss, that is the process scheduling to consider things. Because we are talking about the interruption of the device driver, the focus is on the hard interrupt. What we're talking about here is a hard interrupt, a hardware-related outage.

Ii. Interruption of production

To be interrupted because the peripherals need to notify the operating system something happened to her there, but the interrupt function is just a device alarm light, when the light is on the interrupt handler only know that something has happened, but what happened to the device to see it in person. That is, when an interrupt handler learns that a device has been interrupted, it does not know what happened to the device, and only when it accesses some status registers on the device can it know what exactly happened and how to deal with it.

The device sends a high level to the interrupt controller by breaking the line tells the operating system that it produces an interruption, and the operating system knows from the state of the interrupt controller which interrupt line has been interrupted. The interrupt controller used on the PC is 8259, each of which can manage the disconnection of 8 lines, while the two 8,259 cascade can control the disconnection of 15 bars altogether. The break line here is a real circuit that connects to a device controller outside the CPU through a hardware interface.

Third, IRQ

Not every device can interrupt the signal to the interrupt line, only a certain break line Yong has control, you can send a signal to this interrupt line. Since the computer's external devices are more and more, so 15 broken line is not enough, the disconnection is a very valuable resource. To use the break line, you have to interrupt the application of the wire, that is, IRQ (Interrupt requirement), we also often apply a break line to become an IRQ or request an interrupt number.

IRQ is invaluable, so we recommend that you only request an IRQ when the device needs to be interrupted, or use a shared interrupt when applying for an IRQ, so that more devices can be interrupted.

Regardless of whether the use of IRQ is exclusive or shared, the process of applying for an IRQ is the same, divided into 3 steps:

1. Probe through all the interrupt lines to see which interrupts are not being used. Select an IRQ as the device from these interrupts that have not been occupied.

2. Request the selected IRQ by interrupting the request function, which specifies whether the request is exclusive or shared.

3. Decide what to do according to the return value of the interrupt Request function: If the success is all right, if not successful, either reapply or discard the application and return an error.

The process of applying for an IRQ is described in detail in the source code of the reference book, which can be understood by the reader by carefully reading the short case of the source.