- Overview: The system must be aware of the state of the hardware in a timely manner, usually in two ways: one is polling. One is by responding to hardware interrupts. The former will waste processor time, while the latter will not.
- Prepare the and the mouth
- The same port is not interrupted until no section is set to produce an interrupt
- The standard setting of the Port2 (px37a, 0x27a, or other port) will enable interrupt reporting for the 4th bit. 0x10
- When the interrupt state is enabled. Whenever the level of pin 10 is changed from low to high. The same port will produce an interrupt.
- Pin 9 is the highest bit in the data byte of the same port
- Install Interrupt handling Routines
- Interrupt signal line is a valuable and limited resource
- The kernel maintains a register of interrupt signal lines. The register is similar to the I/oport registration form
- The module requests an interrupt channel before using the interrupt, and then releases the channel after use
- <linux/sched.h>
- int REQUEST_IRQ (unsigned int IRQ, irqreturn_t (*handler) (int, void *, struct pt_regs *), unsigned long flags, const char *dev_name, void *dev_id);
- Return 0 indicates successful application
- Flags
- Sa_interrupt
- Indicates that this is a "high speed" interrupt processing routine
- Sa_shirq
- Indicates that interrupts can be shared between devices
- Sa_sample_random
- Indicates that the resulting interrupt can contribute to the entropy pool (entropy pools) used by/dev/random devices and/dev/urandom devices
- void Free_irq (unsigned int irq, void *dev_id);
- int CAN_REQUEST_IRQ (unsigned int IRQ, unsigned long flags);
- The correct location for using REQUEST_IRQ should be before the device is first opened, and the hardware is told to produce an interrupt
- The location of the call to Free_irq is the last time the device was shut down and the hardware was told not to interrupt the processor
- /proc interface
- /proc/interrupts
- Not dependent on architecture
- /proc/stat
- The number of interrupts defined on the current x86 architecture is 224 and can be explained from the Include/asm-386/irq.h file
- Self-actively detects IRQ numbers
- Probes with the help of the kernel
- <linux/interrupt.h>
- unsigned long probe_irq_on (void);
- int Probe_irq_off (unsigned long);
- DIY Probes
- High-speed and slow-processing routines
- High-speed interrupt run time. All other interrupts on the current processor are disabled
- Inside of interrupt processing on x86 platform
- Arch/i386/kernel/irq.c
- Arch/i386/kernel/apic.c
- Arch/i386/kernel/entry. S
- Arch/i386/kernel/i8259.c
- Include/asm-i386/hw_irq.h
- The IRQ is measured by setting the irq_waiting status bit for each IRQ that lacks an interrupt handler routine.
- Implementing an interrupt processing routine
- The interrupt processing routine is executed within the break time, so its behavior is subject to some limitations
- Cannot send or receive data to user space
- Can not be contrived regardless of what might happen to hibernate operation
- Cannot call Schdule function
- Receive feedback about interrupts to the device and read or write the data according to the different meanings of the interrupt being served
- Usually do clear a bit on the interface card. Most hardware devices do not incur additional interrupts until their "interrupt-pending (interrupt suspend)" bit is cleared
- A typical task for an interrupt processing routine is to assume that the event that the interrupt notification process waits for has occurred. For example, new data arrives. Will wake up the dormant process on that device.
- Parameters and return values for processing routines
- An int IRQ is an interrupt number
- Void *dev_id is a type of customer data (that is, private data that is available to the driver)
- struct Pt_reg *regs are very rarely used. It holds the processor context snapshot before the processor enters the interrupt code
- The interrupt processing routine should return a value. Used to indicate whether an interrupt was actually handled. If the processing routine finds that its device does need to be processed, it should return irq_handled. Otherwise. The return value should be Irq_none
- Enable and disable interrupts
- sometimes device drivers must block interrupts during a time period, such as blocking interrupts when owning a spin lock
- Disable single interrupt
- <asm/irq.h>
- void Disable_irq (int IRQ);
- void Disable_irq_nosync (int IRQ);
- void Enable_irq (int IRQ);
The
- DIABLES_IRQ not only disables the given interrupt, but also waits for the currently running interrupt handler to complete
- assuming that the thread that calls DISABLE_IRQ has the resources (for example, spin locks) that are required for any interrupt processing routines The system will deadlock
- Disable all interrupts
- <asm/system.h>
- void Local_irq_save (Unsig Ned long FALSG);
- void local_irq_disable (void);
- void Local_irq_restore (unsigned long flags);
- void local_irq_enable (void)
- top half and bottom half
- top half. is the actual response interrupt routine. That is, the interrupt routine with the REQUEST_IRQ register
- The bottom half of the section, is a top half of the dispatch. Routines that run in a later, more secure time
- when the bottom half of the processing routine runs, all interrupts are open
- Typically, the top half holds the device's data to a device-specific buffer and dispatches its bottom half
- tasklet
- Tasklet can be dispatched more than once, but the Tasklet schedule does not accumulate
- assuming that the driver has multiple tasklet. You must use some kind of locking mechanism to avoid conflicts with each other
- Tasklet ensures that the functions that dispatch them for the first time are executed on the same CPU
- must use the macro Declare_tasklet declaration Tasklet
- Declare_tasklet (name, function, data);
- void Do_tasklet (unsigned long);
- Declare_tasklet (Test_tasklet, Do_tasklet, 0);
- Tasklet_schedule ($test _tasklet);
- Work Column
- Task Force column function executes in the context of the process, so it can hibernate if necessary
- cannot copy data from the working queue to user space
/li>
- Interrupt sharing
- the IRQ Beacon line on the PC cannot serve more than one device
- modern hardware has been able to 谲诈 broken shares. PCI bus requires peripherals to share interrupts
- install shared processing routines
- shared interrupts are also installed through REQUEST_IRQ. But there are two different
- request interrupts, you must specify the SA_SHIRQ bit in the flags parameter
- dev_id The parameters must be unique, no matter what pointers to the module address space can be used, but dev_id cannot be set to Nu LL
- When requesting a sharing interrupt, assume that one of the following conditions is met. Then REQUEST_IRQ will succeed.
- Interrupt signal line spare
- No matter what has been registered the processing routine of the interrupt signal line also identifies that the IRQ is shared
- Drivers using shared processing routines need to be careful about one thing: You cannot use ENABLE_IRQ and Disable_irq
- to perform a processing routine
- when the kernel receives an interrupt, all the registered processing routines are called /li>
- a shared interrupt processing routine must be able to differentiate between interrupts to be processed and interrupts generated by other devices
- /proc interface and shared interrupts
- installing shared interrupt processing routines on the system does not /proc/stat impact. It doesn't even know which processing routines are shared, but/proc/interrupts changes the
slightly
- Interrupt-driven I/O
- Assuming that the transfer data between the hardware and the driver management is delayed for some reason, the driver author should implement buffering
- Data buffers help to separate the delivery and reception of data from the system call write and read, thereby improving the overall performance of the system
- A good buffering mechanism requires interrupt-driven I/O
- To properly interrupt-driven transmission data, the hardware should be able to generate interrupts according to the following semantics
- For input. The device interrupts the processor when the new data has arrived and the processor is ready to receive it
- For output, interrupts are emitted when the device is ready to receive new data or respond to a successful data transfer
The tenth chapter of Linux Device Drivers interrupts processing--note
