Must the kernel interrupt number be the same as the hardware interrupt number?

First, the answer is no, the kernel interrupt number can be inconsistent with the hardware interrupt number, but this is a boring problem. Practical value is small. However, it can cause the consideration of the relationship between the kernel software interrupt number and the hardware interrupt number.
the relationship between the two I think can be from the initialization and distribution of interrupts to explore the process.
from the core code framework of the arm PPC MIPS 3 Mainstream embedded processor architecture, this section analyzes the initialization and distribution of their interrupts.

initialization of an interrupt
for interrupt initialization, in the system boot process, the 3 processor architectures in the Kernel software framework will have the corresponding interrupt initialization function.

the kernel startup function Start_kernel calls INIT_IRQ for interrupt initialization, which is implemented differently on different processor platform code. Implemented in the ARCH/XXX/KERNEL/IRQ.C.
for ARM processors, INIT_IRQ calls the INIT_IRQ of the corresponding device descriptor Machine_desc.
for PPC processors, INIT_IRQ calls the INIT_IRQ of the corresponding device descriptor machdep_calls.
for MIPS processors, INIT_IRQ calls ARCH_INIT_IRQ.
the final invocation of the interrupt initialization function is implemented in the Board support package because the interrupt controller is part of the processor core peripheral.

So it can be seen that the invocation relationship of the interrupt initialization:
General function Start_kernel-----> Processor Platform-level functions INIT_IRQ-----> board-level interrupt initialization function INIT_IRQ, etc.

The board-level interrupt initialization function completes 2 things, one of which interrupts the initialization of the controller. The second is the initialization of the interrupt descriptor Irq_desc.
Interrupt controller initialization is not a detail. Here we are primarily concerned with the processing of interrupt descriptors on the software.

Kernel for interrupt management, the most critical data structure is IRQ_DESC, in the KERNEL/IRQ/IRQDESC.C:

struct Irq_desc Irq_desc[nr_irqs] __cacheline_aligned_in_smp = {    [0 ... Nr_irqs-1] = {        . Handle_irq = Handle_bad_irq,        . Depth      = 1,        . Lock       = __raw_spin_lock_unlocked (irq_ Desc->lock),    }};

The NR_IRQS is defined by a board-level support package for different processor platforms, and the IRQ_DESC array member represents each of the interrupt numbers and corresponding processing functions.
so Irq_desc[nr_irqs] is the hardware interrupt Controller interrupt number table in the kernel characterization.

There is a premise that, in the case where the CONFIG_SPARSE_IRQ kernel option is not configured, Irq_desc[nr_irqs] allocates the interrupt descriptor statically in an array form, which determines the size of the IRQ_DESC array at compile time.
If you configure CONFIG_SPARSE_IRQ, Irq_desc is dynamically allocated to conserve memory. This is another set of mechanisms, and this is not the case.

The board-level interrupt initialization function completes the initialization of the IRQ_DESC that corresponds to all the interrupt numbers used, primarily the first-level processing function that sets the interrupt. It is generally HANDLE_LEVEL_IRQ. The function is implemented in the KERNEL/IRQ/CHIP.C.
HANDLE_LEVEL_IRQ iterates through the Irq_desc's action list and executes its action->handler sequentially.

The interrupt handler that calls REQUEST_IRQ registration in each driver is the handler member of each action Irq_desc. Here we also understand the implementation mechanism of shared interrupts under the kernel.

This is the initialization of the kernel interrupt. As can be seen from here, the Irq_desc[nr_irqs] kernel interrupt number table corresponds to the hardware interrupt number table.

So the problem comes, I won't let them all correspond, hardware interrupt number 35 of the processing function, I would like to put in the IRQ_DESC array of number 30th can?
From the initialization of the interrupt, it's OK to change the contents of the array members.
But we want to think about what interrupts are for, the initialization of interrupts, and the registration, all in order to be able to properly respond to interrupts.
so the key to this problem is that, when the 35th interrupt is generated, the kernel can normally find the processing function on number 30th Irq-desc.
That is, in the interrupt distribution process how the kernel determines the software interrupt number, the hardware 35th interrupt to find the No. 30th Irq_desc.

We need to look at the interrupt distribution process for the kernel.


Distribution of two interrupts
Interrupts are a processor core exception, so in the processor design, the peripheral interrupt causes the processor exception, the processor jumps to the exception vector table corresponding exception entry to refer to execution.
The exception vector table of the processor is also a very interesting combination of hardware and software, there is time to write a special article to record, here is unknown.


We mainly look at the execution process after the interrupt is generated and the processor jumps to the interrupt exception entry.

(1) For ARM processors, the following procedures are performed:
VECTOR_IRQ---> Irq_handler---> Arch_irq_handler_default---> ASM_DO_IRQ---> Handle_irq
Call Get_irqnr_and_base in Arch_irq_handler_default to get the interrupt number, passed to ASM_DO_IRQ as a parameter.
The get_irqnr_and_base is implemented by a board-level support package.

(2) for PPC processors, the execution process is as follows:
DO_IRQ---> PPC_MD.GET_IRQ---> Handle_one_irq
ppc_md.get_ IRQ is the get interrupt number function that is implemented in the Board support package for the device descriptor.

(3) for MIPS processors, the execution process is as follows:
handle_int--- > Plat_irq_dispatch---> Do_irq
plat_irq_dispatch is implemented in the class support package.


The above process is represented by the exception entry function, to the end of the call HANDLE_LEVEL_IRQ.


according to the above analysis, ARM MIPS The acquisition of the interrupt number for PPC in interrupt distribution is left to the Board support package for implementation. The board-level support package reads the relevant registers in the interrupt controller to obtain the current interrupt condition and returns the interrupt number.


so combined with the problem of the interrupt initialization section, regardless of which processor platform, If we want the interrupt handler for interrupt 35th to be placed in the number 30th Irq_desc at the time of registration (the method is REQUEST_IRQ when the interrupt number is 30).

Then in the interrupt distribution, get interrupt number function We also need to make changes, query to interrupt controller register State is generated 35th interrupt, we return the interrupt number should be number 30th!

However, this does not have practical application significance, because in the actual development is still to try to ensure that the kernel Irq_desc array and hardware interrupt number table one by one corresponding, so that the driver in the operation of the interrupt does not need to care about the relationship between the kernel interrupt number and hardware interrupt number, but directly using the hardware interrupt number to register it.

If the kernel interrupt number and hardware interrupt number do not correspond to each other, driver developers need to find the hardware interrupt number and the kernel Interrupt number mapping table when writing the driver, which makes the development more difficult.

In any case, it is worthwhile to take this boring question and figure out the initialization and distribution of the kernel interrupts.


But ask for good, MO asked the future!

Must the kernel interrupt number be the same as the hardware interrupt number?