linux-interrupt-process

 when an IRQ is raised, the kernel executes some assembler code in order to save  the current state and jumps to the arch-specific handler, handle_arch_irq. For ARM architectures, this handler is 

set with the value of the handle_irq field in struct machine_desc of the platform in the setup_arch() function implemented in arch/arm/kernel/setup.c. The assignation is done as follows:


Shared IRQ:

https://stackoverflow.com/questions/14371513/for-a-shared-interrupt-line-how-do-i-find-which-interrupt-handler-to-use

The kernel will sequentially invoke all the handlers for that particular shared line.


Exactly. Say Dev1 and Dev2 shares the IRQ10. When an interrupt is generated for IRQ10, all ISRs registered with this line will be invoked one by one.


In our scenario, say Dev2 was the one that generated the interrupt. If Dev1's ISR is registered first, than its ISR (i.e Dev1's ISR) only called first. In that ISR, the interrupt status register will be verified for interrupt. If no interrupt bit is set (which is the case, cause Dev2 raised the interrupt) then we can confirm that interrupt was not generated by Dev1 - so Dev1's ISR should return to the kernel IRQ_NONE - which means:"I did not handled that interrupt", so on the kernel continues to the next ISR (i.e Dev2's ISR), which in turn, will indeed verify that its corresponding device generated the interrupt, thus, this handler should handle it and eventually return IRQ_HANDLED - which means:"I handled this one".


See the return values IRQ_NONE/IRQ_HANDLED for more information.


How does the handler know that the corresponding device issued the interrupt or not ?


By reading the Interrupt status register only.


Is this information relayed through the interrupt controller that is between the devices and the processor interrupt line ??


I'm not sure about this. But the OS will take care of calling ISRs based on the return values from ISR.



For irq shared, each isr checks its registers for irq

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i2c/tda9950.c#L455

https://elixir.bootlin.com/linux/latest/source/arch/sh/drivers/dma/dma-sh.c#L118

----------------------------------------------------------------------------------------------------------------------------



https://www.cnblogs.com/LoyenWang/p/12996812.html


https://blog.csdn.net/a935854743/article/details/134913122?spm=1001.2101.3001.6650.14&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-14-134913122-blog-119561223.235%5Ev43%5Epc_blog_bottom_relevance_base1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-14-134913122-blog-119561223.235%5Ev43%5Epc_blog_bottom_relevance_base1


After configuring according to the above, when the key interrupt is generated, the interrupt controller will pass the interrupt to cpu0. 

After CPU0 finishes executing the current instruction, it detects that the IRQ interrupt is generated, so it automatically switches 

the operating mode to the IRQ interrupt mode (copy the CPSR to SPSR_IRQ, then modify the CPSR to enter the IRQ interrupt mode), 

then point the PC pointer to the IRQ interrupt vector table, and start processing the interrupt by the software; the software can know 

the hardware interrupt number of the interrupt by reading the register of the interrupt controller, thus I know it is a key interrupt.


--------------------------------------------------------------------------------------------------------------------------

armv8 interrupt and exception forwarding

https://developer.arm.com/documentation/102142/0100/Virtualizing-exceptionss

Comments

Popular posts from this blog

dev_get_platdata understanding

Getting started with pinctrl subsystem linux

How to take systrace in android