|ARM Technical Support Knowledge Articles|
Applies to: Processor Cores
Suppose you have the following execution sequence:
The first Wait For Event (WFE) instruction puts a core in WFE state. However, the second WFE does not necessarily put the core in WFE state. Whether the second WFE puts the core in WFE state depends on the implementation of the core you use. For example:
Cortex-A72 and Cortex-A53 handle WFE instructions differently, and the following text from ARMv8 architecture explains the difference:
The WaitForEvent() pseudocode procedure optionally suspends execution until a WFE wake-up event or reset occurs, or until some earlier time if the implementation chooses. It is IMPLEMENTATION DEFINED whether restarting execution after the period of suspension causes a ClearEventRegister() to occur.
For Cortex-A72, the Event Register is cleared after the core restarts from the first WFE. That is, for Cortex-A72, after the wake-up event sets the Event Register, the ClearEventRegister() clears the Event Register when restarting from the WFE state. Therefore, for Cortex-A72, after waking up from WFE state, only one WFE is needed to put the core in WFE state again.
The following waveform for Cortex-A72 shows that the ClearEventRegister() clears the Event Register when restarting from WFE state.
Figure 2 Cortex-A72 waveform
Although different processors might handle WFE differently, you can use the following standard code of Linux to avoid such problems:
static inline void arch_spin_lock(arch_spinlock_t *lock)
unsigned int tmp;
"2: ldaxr %w0, %1\n"
" cbnz %w0, 1b\n"
" stxr %w0, %w2, %1\n"
" cbnz %w0, 2b\n"
: "=&r" (tmp), "+Q" (lock->lock)
: "r" (1)
: "cc", "memory");
Article last edited on: 2015-11-30 13:00:12
Did you find this article helpful? Yes No
How can we improve this article?