Driver: Interrupt "2" interrupt handler, interrupt context processing delay, and some function call rules (adjustable IIC interrupt drive feeling)

interrupt handlers, interrupt context processing delay, and call rules for some functions (http://blog.csdn.net/samantha_sun/article/details/6790492 of the IIC interrupt driver)

1, the interrupt handler can not use sleep function functions, such as ioremap,kmalloc,msleep, the reason is that the interruption program is not a process, no process concept, so there is no concept of sleep;

2, the delay in the interrupt handler can be replaced with a busy wait function, such as ndelay,udelay,mdelay, these functions are essentially based on the CPU frequency of a certain number of cycles; it is best not to use mdelay because the millisecond delay is already very large for the kernel. However, using Msleep in an interrupt handler does not work. (See Linux device Driver development in detail Second Edition p210 page)

The 3,PRINTK function can be used in interrupt handling functions, but it takes more time and reduces efficiency. In the control of the IIc drive, due to the IIC read write processing must be a certain delay, when I did not use Udelay, unexpectedly use PRINTK to make IIC interrupt normal operation, at the time of commissioning, found some PRINTK plus the program is normal, remove it is not normal, At that time it was really strange, but now understand, so PRINTK occupy time is relatively large, just as the IIC delay function. Finally I removed all the PRINTK, in the need to delay the place to join Udelay, only to make the program normal operation.

4, using the for and while, such as the empty loop in the interrupt processing function to delay operation, in the actual test found that can not play the function of delay, the Linux kernel processing this cycle is very fast, and no delay effect. This is not the same as the use of the bare board program using loops to delay the usage.

Other:

1. Interrupt is an electrical signal generated by a hardware device and fed directly to the input pin of the interrupt controller. The interrupt controller then sends the corresponding signal to the processor. Once the processor detects this signal, it interrupts its current work to handle interrupts. Thereafter, the processor notifies the operating system that an interrupt has been generated so that the operating system can properly process the interrupt.

2. Different devices correspond to different interrupts, and each interrupt is identified by a unique digital ID. Interrupt values are often referred to as interrupt request (IRQ) lines. Some of the break values are specified, and some are dynamically allocated. Specific interrupts are always associated with a particular device.

3. Unlike interrupts, it must be considered synchronized with the processor clock when it is generated. Exceptions are also often referred to as synchronous interrupts. Many processor architectures handle exceptions in a similar way to interrupts, so the kernel handles them very similarly.

4. In response to a specific interrupt, the kernel executes a function called an interrupt handler or interrupt service routine. Each device that generates an outage has a corresponding interrupt handler, and if a device can produce many different interrupts, the device can correspond to multiple interrupt handlers. An interrupt handler for a device is part of its device driver.

5. The real difference between interrupt handlers and other kernel functions is that interrupt handlers are called by the kernel to respond to interrupts, and they run in a special context that we call the interrupt context .

6, interrupt processing is generally divided into two parts, the interrupt handler is the upper half-receive an interrupt to execute immediately, but only to do a strict time-bound work, all of these work is done in the case of all interruptions are prohibited. Work that can be allowed to be done later is postponed to the lower part. Typically, the lower half is executed as soon as the interrupt handler returns.

7. Interrupt handlers in Linux are not required to be re-entered. When a given interrupt handler is executing, the corresponding in-line disconnection is masked on all processors to prevent another new interrupt from being received on the same interrupt. Normally, all other interrupts are open, so the other interrupts on the different interrupt lines can be processed, but the current break is always forbidden. As you can see, the same interrupt handler is never called at the same time to handle nested interrupts.

8, the shared interrupt handler and non-shared in the registration and operation mode is similar, but the difference is mainly the following three places:

• • Register Interrupt handler function REQUEST_IRQ () The parameter flags must be set SA_SHIRQ flag.
  • The dev_id parameter must be unique for each registered interrupt handler. You cannot pass a null value to a shared handler.
  • The interrupt handler must be able to differentiate whether its device actually produces an interrupt. Otherwise it simply does not know if it was the device that sent the interrupt or the other device that shared the interrupt line.

9. When an interrupt handler or the lower half is executed, the kernel is in the interrupt context . The interrupt context and process are nothing to do with. Because there is no background for the process, the interrupt context is not able to sleep. Therefore, some functions cannot be called from the interrupt context . If a function sleeps, it cannot be used in an interrupt handler function. The interrupt context has a stricter time limit because it interrupts other code. The code in the interrupt context should be quick and concise and try not to use loops to handle heavy work. Try to separate the work from the interrupt handler and put it in the lower part. The interrupt handler does not have its own stack. Instead, it shares the kernel stack of the interrupted process. If there are no running processes, use the stack of the idle process. The interrupt handler shares someone else's stack, so it must be very economical when it gets space in the stack. The kernel stack is limited, and all kernel code should be used with caution.

10. The Linux kernel provides a set of interfaces for operating the interrupt state on the machine. These interfaces provide us with the ability to disable the interrupt system of the current processor, or to block out an interrupt line for the entire machine, which are architecture-related and can be found in <asm/system.h> and <asm/irq.h>.

11, the reason to control the interruption system is ultimately the need to provide synchronization. By prohibiting interrupts, you can ensure that an interrupt handler does not preempt the current code, and that it can suppress kernel preemption. But none of them provides any protection against concurrent access from other processors. Locks provide a protection mechanism to prevent concurrent access from other processors. Prevents interrupts from providing a protection mechanism to prevent concurrent access from other interrupt handlers.

Driver: Interrupt "2" interrupt handler, interrupt context processing delay, and some function call rules (adjustable IIC interrupt driver feeling)