Can an interrupt line shared by different drivers have different unique interrupt handlers? For example, would something like this be possible?
on driver1 : request_irq(irq, &handler1, IRQF_SHARED,"dev1", dev1);
on driver2 : request_irq(irq, &handler2, IRQF_SHARED,"dev2", dev2);
If all drivers that want to share this IRQ are requesting it with IRQF_SHARED this works - If only one of them does not set that flag, i.e. wants the IRQ exclusively, your request_irq will fail.
Another precondition is that your handler needs to be able to recognise somehow from the hardware whether it was his device that triggered the IRQ or not. This determines the return value of the handler.
The kernel will call all handlers that share the IRQ in sequence until it found one that actually handled it.
Related
I am using FreeRTOS on an ARM Cortex A9 CPU und I'm desperately trying to find out if it is possible to determin if the processor is executing a normal thread or an interrupt service routine. It is implemented in V7-a architecture.
I found some promising reference hinting the ICSR register (-> VECTACTIVE bits), but this only exist in the cortex M family. Is there a comparable register in the A family as well? I tried to read out the processor modes in the current processor status register (CPSR), but when read during an ISR I saw that the mode bits indicate supervisor mode rather than IRQ or FIQ mode.
Looks a lot like there is no way to determine in which state the processor is, but I wanted to ask anyway, maybe I missed something...
The processor has a pl390 General Interrupt Controller. Maybe it is possible to determine the if an interrupt has been triggered by reading some of it's registers?
If anybody can give me a clue I would be very greatfull!
Edit1:
The IRQ Handler of FreeRTOS switches the processor to Superviser mode:
And subsequently switches back to system mode:
Can I just check if the processor is in supervisor mode and assume that this means that the execution takes place in an ISR, or are there other situations where the kernel may switches to supervisor mode, without being in an ISR?
Edit2:
On request I'll add an overal background description of the solution that I want to achieve in the first place, by solving the problem of knowing the current execution context.
I'm writing a set of libraries for the CortexA9 and FreeRTOS that will access periphery. Amongst others I want to implement a library for the available HW timer from the processor's periphery.
In order to secure the access to the HW and to avoid multiple tasks trying to access the HW resource simultaneously I added Mutex Semaphores to the timer library implementation. The first thing the lib function does on call is to try to gain the Mutex. If it fails the function returns an error, otherwise it continouses its execution.
Lets focus on the function that starts the timer:
static ret_val_e TmrStart(tmr_ctrl_t * pCtrl)
{
ret_val_e retVal = RET_ERR_DEF;
BaseType_t retVal_os = pdFAIL;
XTtcPs * pHwTmrInstance = (XTtcPs *) pCtrl->pHwTmrInstance;
//Check status of driver
if(pCtrl == NULL)
{
return RET_ERR_TMR_CTRL_REF;
}else if(!pCtrl->bInitialized )
{
return RET_ERR_TMR_UNINITIALIZED;
}else
{
retVal_os = xSemaphoreTake(pCtrl->osSemMux_Tmr, INSTANCE_BUSY_ACCESS_DELAY_TICKS);
if(retVal_os != pdPASS)
{
return RET_ERR_OS_SEM_MUX;
}
}
//This function starts the timer
XTtcPs_Start(pHwTmrInstance);
(...)
Sometimes it can be helpful to start the timer directly inside an ISR. The problem that appears is that while the rest of function would support it, the SemaphoreTake() call MUST be changed to SemaphoreTakeFromISR() - moreover no wait ticks are supported when called from ISR in order to avoid a blocking ISR.
In order to achieve code that is suitable for both execution modes (thread mode and IRQ mode) we would need to change the function to first check the execution state and based on that invokes either SemaphoreTake() or SemaphoreTakeFromISR() before proceeding to access the HW.
That's the context of my question. As mentioned in the comments I do not want to implement this by adding a parameter that must be supplied by the user on every call which tells the function if it's been called from a thread or an ISR, as I want to keep the API as slim as possible.
I could take FreeRTOS approch and implement a copy of the TmrStart() function with the name TmrStartFromISR() which contains the the ISR specific calls to FreeRTOS's system resources. But I rather avoid that either as duplicating all my functions makes the code overall harder to maintain.
So determining the execution state by reading out some processor registers would be the only way that I can think of. But apparently the A9 does not supply this information easily unfortunately, unlike the M3 for example.
Another approch that just came to my mind could be to set a global variable in the assembler code of FreeRTOS that handles exeptions. In the portSAVE_CONTEXT it could be set and in the portRESTORE_CONTEXT it could be reset.
The downside of this solution is that the library then would not work with the official A9 port of FreeRTOS which does not sound good either. Moreover you could get problems with race conditions if the variable is changed right after it has been checked by the lib function, but I guess this would also be a problem when reading the state from a processor registers directly... Probably one would need to enclose this check in a critical section that prevents interrupts for a short period of time.
If somebody sees some other solutions that I did not think of please do not hesitate to bring them up.
Also please feel free to discuss the solutions I brought up so far.
I'd just like to find the best way to do it.
Thanks!
On a Cortex-A processor, when an interrupt handler is triggered, the processor enters IRQ mode, with interrupts disabled. This is reflected in the state field of CPSR. IRQ mode is not suitable to receive nested interrupts, because if a second interrupt happened, the return address for the first interrupt would be overwritten. So, if an interrupt handler ever needs to re-enable interrupts, it must switch to supervisor mode first.
Generally, one of the first thing that an operating system's interrupt handler does is to switch to supervisor mode. By the time the code reaches a particular driver, the processor is in supervisor mode. So the behavior you're observing is perfectly normal.
A FreeRTOS interrupt handler is a C function. It runs with interrupts enabled, in supervisor mode. If you want to know whether your code is running in the context of an interrupt handler, never call the interrupt handler function directly, and when it calls auxiliary functions that care, pass a variable that indicates who the caller is.
void code_that_wants_to_know_who_called_it(int context) {
if (context != 0)
// called from an interrupt handler
else
// called from outside an interrupt handler
}
void my_handler1(void) {
code_that_wants_to_know_who_called_it(1);
}
void my_handler2(void) {
code_that_wants_to_know_who_called_it(1);
}
int main(void) {
Install_Interrupt(EVENT1, my_handler1);
Install_Interrupt(EVENT2, my_handler1);
code_that_wants_to_know_who_called_it(0);
}
I'm writing a small OS on ARMv8 architecture with GICv3.
During device initialization, I expected an interrupt to be taken to the OS. However, it's never triggered. And it turned out I misconfigured the interrupt triggering type of the device as "level-sensitive" even though the actual interrupt triggering type is "edge-triggered". After changing the interrupt triggering type to "edge-triggered", I was able to receive the interrupt of the device.
Here's my question:
How GIC receives and forwards the asserted interrupts depends on the interrupt triggering type?
According to how GIC works (receive and forward), why was the interrupt never triggered with my wrong configuration?
What happens if I misconfigured the interrupt triggering type in the opposite way? (If I misconfigure the interrupt triggering type as "edge-triggered" but the actual one should be "level-sensitive".)
Thank you in advance.
An interrupt, in general, is just the assertion of a signal line. When the interrupt condition is present, the line is asserted; when not present the line is de-asserted.
The thing listening to a line, an interrupt controller, can interpret the signal in two ways: by transition or state. By transition means that the controller remembers it asserting itself, and retains that memory until some action is taken to clear that memory. By state means that the controller merely reflects the state of the signal line.
Transition, or Edge permits a simpler hardware controller, that can merely assert pulses indicate a change of state, whether it be carrier detected or character received. In a state or Level controller, a simple thing like carrier detected becomes a cumbersome multi-state exchange between the controller and the CPU.
State, or Level, however permits a hardware controller to insist upon attention until the underlying condition is satisfied. This is not just convenient when a single interrupt signal is shared by multiple devices, but to avoid a race between the hardware controller and the CPU. In general, Edge oriented devices need to be re-examined after processing an interrupt, to ensure the squelching of the interrupt controller didn't miss an interrupt pulse.
So, when you set the mode in something like a GIC, you need to know how the hardware device behaves, and program the GIC correspondingly. It isn't a selection of how you would like the device to behave; rather it is a configuration of how the device does behave. Mercifully, device-tree gives you that information, and if you can't believe device tree, then all is lost.
I know when an interrupt occurs the process running is put on hold, and the Interrupt Service Routine is called. The current pointer is pointing to the process that was interrupted and I was told that when an interrupt occurs it is not linked to a specific process. So my question is why only another interrupt can preempt an existing interrupt routine?
Also, when a process(p2) preempts another process(p1), who is calling the schedule() method?
the first two answers both show some significant misunderstanding about interrupts and how they work
Of particular interest,
for the CPUs that we are usually using
( 86x.., power PC, 68xxx, ARM, and many others)
each interrupt source has a priority.
sadly, there are some CPUs, for instance the 68HC11, where all the interrupts, except the reset interrupt and the NMI interrupt, have the same priority so servicing any of the other interrupt events will block all the other (same priority) interrupt events.
for our discussion purposes, a higher priority interrupt event can/ will interrupt a lower priority interrupt handler.
(a interrupt handler can modify the appropriate hardware register to disable all interrupt events or just certain interrupt events. or even enable lower priority interrupts by clearing their own interrupt pending flag (usually a bit in a register)
In general, the scheduler is invoked by a interrupt handler,
(or by a process willingly giving up the CPU)
That interrupt is normally the result of a hardware timer expiring/reloading and triggering the interrupt event.
A interrupt is really just an event where the event is waiting to be serviced.
The interrupt event, when allowed, for instance by being the highest priority interrupt that is currently pending, will cause the PC register to load the first address of the related interrupt handler.
the act of diverting the PC register to the interrupt handler will (at a minimum) push the prior PC register value and status register onto the stack. (in some CPUs, there is a special set of save areas for those registers, so they are pushed onto the special area rather than on the stack.
The act of returning from an interrupt, for instance via the RTI instruction, will 'automatically' cause the prior PC and status register values to be restored.
Note: returning from an interrupt handler does not clear the interrupt event pending indication, so the interrupt handler, before exiting needs to modify the appropriate register otherwise the flow of execution will immediately reenter the interrupt handler.
The interrupt handler has to, upon entry, push any other registers that it modifies and, when ready to exit, restore them.
Only interrupts of a lower priority are blocked by the interrupt event diverting the PC to the appropriate interrupt handler. Blocked, not disabled.
on some CPUs, for instance most DSPs, there are also software interrupts that can be triggered by an instruction execution.
This is usually used by hardware interrupt handlers to trigger the data processing after some amount of data has been input/saved in a buffer. This separates the I/O from the processing thereby enabling the hardware interrupt event handler to be quick and still have the data processed in a timely manner
The above contradicts much of what the comments and other answers state. However, those comments and answers are from the misleading view of the 'user' side of the OS, while I normally program right on the bare hardware and so am very familiar with what actually happens.
So my question is why only another interrupt can preempt an existing
interrupt routine?
A hardware interrupt usually puts the processor hardware in an interrupt state where all interrupts are disabled. The interrupt-handler can, and often does, explicitly re-enable interrupts of a higher priority. Such an interrupt can then preempt the lower-priority interrupt. That is the only mechanism that can interrupt a hardware interrupt.
Also, when a process(p2) preempts another process(p1), who is calling
the schedule() method?
That depends somewhat on whether the preemption is initiated by a syscall from a thread already running, or by a hardware interrupt that causes a handler/driver to run and subsequently enter the kernel to request a reschedule. The exact mechansims, (states, stacks etc), used are architecture-dependent.
Regarding your first question: While an interrupt is running, interrupts are disabled on that processor. Therefore, it cannot be interrupted.
Regarding your second question: A process never preempts another process, it is always the OS doing that. The OS calls the scheduler routine regularly, where it decides which process will run next. So p2 doesn't say "i want to run now", it just has some attributes like a priority, remaining time slot, etc., and the OS then decides whether p2 should run now.
I'm studying operating systems and I encountered both the terms ISR and interrupt handler. Are they two words for the same mechanism? If not, what is the difference?
There is no difference in Interrupt handler and ISR.
Wiki says that:
In computer systems programming, an interrupt handler, also known as an interrupt service routine or ISR, is a callback function [...]
ISR is callback for a specific service pertaining to a device/operation/source. There could be multiple ISRs present in a system depending on addresses available in Interrupt Vector table. Where is Interrupt handler is a common routine which is triggered whenever any interrupt comes. Its job is to understand the source of the interrupt and trigger appropriate ISR mapped in Interrupt Vector table.
When interrupt occurs,
interrupt handler performs minimal operations required to respond to the device where as updating the buffer and all other operations are taken care by ISR
In Chapter 5 of ULK the author states as follows:
"...each interrupt handler is serialized with respect to itself-that is, it cannot execute more than one concurrently. Thus, accessing the data struct does not require synchronization primitives"
I don't quite understand why interrupt handlers is "serialized" on modern CPUs with multiple cores. I'm thinking it could be possible that a same ISR can be run on different cores simultaneously, right? If that's the case, if you don't use spinlock to protect your data it can come to a race condition.
So my question is, on a modern system with multi-cpus, for every interrupt handler you are going to write that will read & write some data, is spinlock always needed?
While executing interrupt handlers, the kernel explicitly disables that particular interrupt line at the interrupt controller, so one interrupt handler cannot be executed more than once concurrently. (The handlers of other interrupts can run concurrently, though.)
Clarification: as per CL. remark below - the kernel makes sure not to fire the interrupt handler for the same interrupt but if you have multiple registrations of the same interrupt handler for multiple interrupts than the below answer is, I believe, correct.
You are right that the same interrupt handler can run concurrently on multiple cores and that shared data needs to be protected. However, a spinlock is not the only and certainly not always the recommended way to achieve this.
A multitude of other synchronization methods, from per-CPU data, accessing shared data only using atomic operations and even Read-Copy-Update variants may be used to protect the shared data.
No spinlock is not always needed in interrupt handler.
Please note one thing first -
When an interrupt of a particular device occur on interrupt controller, that interrupt is disabled at interrupt controller and hence on all the cores for that particular device. So, the interrupt of same device cannot come on all the CPU simultaneously.
So in normal case there wont be any spin lock required as the code would not be re-entrant.
Though there are 2 cases below in which spinlock is needed in interrupt handler.
Please note, when an interrupt comes from a device and IRQ line, that cores disables all other interrupt on that core and also for that device interrupt on other core also. Interrupt from other devices can comes on other core.
So there can be a case in which, same interrupt handler is registered for different devices.
for eg:-
request_irq(A,func,..);
reqest_irq(B,func,..);
for device A interrupt handler func is called.
for device B same interrupt handler func is called.
So, a spinlock should be used in this case to prevent raise condition.
When same resource is being used in interrupt handler and also some other code which runs in process context.
For eg:- there is resource A
So there can be a case in which one cores runs in interrupt mode, the interrupt handler and is modifying the resource A and other core runs in process context and is also modifying the same resource in some other place.
So to present raise condition for that resource we should use spin lock.
section 4.6 of Understanding the Linux Kernel, 3rd Edition by Marco Cesati, Daniel P. Bovet told you the answer.
Actual interrupt handler is process by handle_IRQ_event. irq_desc[irq].lock prevent concurrently access to handle_IRQ_event by any other CPU.
If the critical data is shared b/w the interrupt handler and your process (may be a kernel thread) then you need to protect your data and hence spinlock is required.A common Kernel api for spinlock is : spin_lock().
There are also variants of these api e.g. spin_lock_irqsave() which can help avoiding the deadlock problems which one can face while acquiring/holding the spin locks.Please go through the below link to find details of the subject:
http://www.linuxjournal.com/article/5833