ARCv2 public interrupt handling.
ARCv2 kernel interrupt handling interface. Included by arc/arch.h.
| #define ARCH_IRQ_DIRECT_CONNECT |
( |
| irq_p, |
|
|
| priority_p, |
|
|
| isr_p, |
|
|
| flags_p ) |
Value:{ \
BUILD_ASSERT(priority_p || !
IS_ENABLED(CONFIG_ARC_FIRQ) || \
"irq priority cannot be set to 0 when CONFIG_ARC_FIRQ_STACK" \
"is not configured or CONFIG_ARC_FIRQ_STACK " \
"and CONFIG_ARC_STACK_CHECKING are configured together"); \
z_irq_priority_set(irq_p, priority_p, flags_p); \
}
#define IS_ENABLED(config_macro)
Check for macro definition in compiler-visible expressions.
Definition util_macro.h:154
#define ISR_FLAG_DIRECT
This interrupt gets put directly in the vector table.
Definition sw_isr_table.h:192
Configure a 'direct' static interrupt.
When firq has no separate stack(CONFIG_ARC_FIRQ_STACK=N), it's not safe to call C ISR handlers because sp will be switched to bank1's sp which is undefined value. So for this case, the priority cannot be set to 0 but next level 1
When firq has separate stack (CONFIG_ARC_FIRQ_STACK=y) but at the same time stack checking is enabled (CONFIG_ARC_STACK_CHECKING=y) the stack checking can raise stack check exception as sp is switched to firq's stack (bank1's sp). So for this case, the priority cannot be set to 0 but next level 1.
Note that for the above cases, if application still wants to use firq by setting priority to 0. Application can call z_irq_priority_set again. Then it's left to application to handle the details of firq
See include/irq.h for details. All arguments must be computable at build time.
| ALWAYS_INLINE unsigned int arch_irq_lock |
( |
void | | ) |
|
|
static |
Disable all interrupts on the local CPU.
This routine disables interrupts. It can be called from either interrupt or thread level. This routine returns an architecture-dependent lock-out key representing the "interrupt disable state" prior to the call; this key can be passed to irq_unlock() to re-enable interrupts.
The lock-out key should only be used as the argument to the irq_unlock() API. It should never be used to manually re-enable interrupts or to inspect or manipulate the contents of the source register.
This function can be called recursively: it will return a key to return the state of interrupt locking to the previous level.
WARNINGS Invoking a kernel routine with interrupts locked may result in interrupts being re-enabled for an unspecified period of time. If the called routine blocks, interrupts will be re-enabled while another thread executes, or while the system is idle.
The "interrupt disable state" is an attribute of a thread. Thus, if a thread disables interrupts and subsequently invokes a kernel routine that causes the calling thread to block, the interrupt disable state will be restored when the thread is later rescheduled for execution.
- Returns
- An architecture-dependent lock-out key representing the "interrupt disable state" prior to the call.