For the ARMv7 architecture, can a FIQ exception pre-empt a currently executing IRQ handler (in IRQ context of course)
Thanks
Yes (that is arguably its primary purpose), unless the IRQ handler has for some crazy reason manually masked FIQs.
IRQs are automatically masked by the core when taking an FIQ exception, but FIQs are not automatically masked by the core when taking an IRQ.
Some, but not all, ARMv6+ processors also support disabling the ability to manually mask FIQs.
Related
I am trying to write a bare metal application on an ARMv8 board. When I signal a SGI, the exception type of the SGI is synchronous while I am expecting it to be either FIQ or IRQ. Can I config it to be an IRQ? Or could someone explain to me why it is synchronous?
Does interrupt handler is running like user programs in the meaning of virtual memory (TLB miss - load page descriptor) or there are on any CPU difference solution?
The interrupt service routine (ISR) is going to execute in kernel mode. The jump table that the processor uses to figure out what routine to run on the interrupt itself cannot be swapped out, because the page fault handler would also be found there. I don't know for sure what would happen if the handler address pointed to an unmapped region of memory. Virtual memory can be supported in kernel mode, at least on x86. Maybe some architectures could handle an access fault for an ISR address, but an OS would never implement that, because the latency for entering the ISR would be totally unacceptable.
My problem is:
Interrupt handler get triggered when free_irq is called. I noticed in kernel messages that handler is invoked but since our device hasn't requested interrupt it prompted that no interrupt has received.
Is it expected behavior ? Can anybody please help ?
When you are registering a handler for a (possibly) shared interrupt (with IRQF_SHARED), the interrupt can be triggered by other devices over which your driver has no control, so your driver must be prepared to receive an interrupt at any time.
To help with debugging drivers, the kernel will (when CONFIG_DEBUG_SHIRQ is set) fake some interrupts to check that your driver works correctly.
[source code]
If I understood your post right - you must turn off issuing interrupts in your hardware before you call free_irq() then you won't receive interrupts while free_irq().
I am trying to understand Asynchronous Interrupt handling in kernel, ofcourse through the legendary Understanding the Linux Kernel.
In this process how and who will trigger Kernel Interrupt Handler?
I would like some one to help me correcting this and to clarify my question on
1)How and Who trigger Kernel Interrupt Handler?
2)How to define new or change existing hardware interrupt handlers?
Thank you in Advance!
This picture from Robert Love's "Linux Kernel Development" pretty well describes path of interrupt. Processor interrupts the kernel in the predefined enty point do_IRQ(). If there is corresponding interrupt handler, it will get executed.
To handle interrupt, you should register your interrupt handler with request_irq().
I have a Windows XP application that is using a driver called TVicHW32 which allows me to create an interrupt handler for OS interrupts. Currently I am using a custom ISA card in an industrial chassis with IRQ 5
The interrupt handler code is working and I can see a variable being incremented so the code that sets up and handles the interrupt is working.
The issue I have is that an IO access call fails to generate any IO activity on the ISA bus. I have an address at 0x308 that is used to trigger a start pulse on the ISA bus interface board.
If I trigger this pulse from the main code, for example, from a timer, the pulse is detected on the ISA bus and the card responds.
If I call the exact same function call to access that IO address from within the interrupt handler, nothing appears on the ISA bus. A logic analyser confirms this.
I have emailed the supplier of the driver but that can't help so I was wondering if anyone here has come across this situation and can offer a solution. This is critical to getting this project working and the only solution I can think of is to develop a custom driver with the DDK but as this requires a steep learning curve, I would hope to find an alternative solution.
Thanks
Dave...