How a core learns to sleep,
wake on cue, and delegate.

The energy floor that forces everything above it

Every primitive on this page exists to dodge one physical bill: dynamic switching energy. If you understand why a core wants to stop, every instruction and protocol above becomes inevitable rather than arbitrary.

A CMOS gate dissipates dynamic power roughly as P = α · C · V² · f — activity factor α, switched capacitance C, supply voltage squared, and clock frequency. Two terms in that equation are levers the system can pull in microseconds: if the core has nothing useful to do, you can drive α toward zero by clock-gating (freeze f locally so flip-flops stop toggling), or you can attack the whole expression by power-gating (collapse V to a retention rail or to zero).

But here is the constraint that propagates all the way up the ladder: a gated core is a deaf core. A clock-stopped pipeline cannot poll a flag. A power-collapsed core has lost its register state. So the moment you decide to save energy by stopping, you create a new problem — how does the silicon know when to start again, and who tells it? That single question is the seed of WFI, WFE, interrupts, the GIC, mailboxes, and SCMI. They are all answers to "how do I wake a core that chose to go quiet."

The two instructions that say "stop me"WFI · WFE

WFI (Wait For Interrupt) and WFE (Wait For Event) are the architectural hooks that let software request the low-power state Layer 0 made desirable. They differ in exactly one thing: what is allowed to wake you.

Both are hints, not commands. The Arm architecture permits a PE (processing element) to treat them as a NOP, or to enter a low-power standby state where the clock — and on some implementations more — is gated. The instruction is the software's permission slip; the power-management hardware decides how deep to actually go.

WFI — wake on interrupt

Execute WFI and the core enters standby until a physical interrupt becomes pending (IRQ, FIQ, or SError), or a debug/reset event arrives. The subtle and important detail: a pending interrupt wakes the core even if that interrupt is masked in PSTATE. Masking only governs whether the interrupt is taken; the wake-up is a separate signal. This is the classic idle path: the OS idle loop, with nothing runnable, executes WFI and parks the core until the next device or timer interrupt.

WFE — wake on event

WFE wakes on a strictly larger set of conditions, gated through a one-bit, sticky, per-PE Event Register. WFE first checks that bit: if it's already set, WFE clears it and falls straight through (no sleep). If it's clear, the core sleeps until any of these set it:

• another PE executes SEV (Send Event) — sets the Event Register on every PE in the system;
• the local PE executes SEVL (Send Event Local) — sets only its own, used to prime the first iteration of a wait loop and dodge a lost-wake race;
• the exclusive monitor is cleared — when some other agent's store lands on an address you were tracking with a load-exclusive. This is the mechanism that makes WFE-based spinlocks work without anyone explicitly sending an event;
• an interrupt becomes pending (same as WFI), or the architected event stream fires (the generic timer can be configured to emit periodic events so a WFE can never sleep longer than, say, 100 µs).

Why this distinction matters in real firmware: WFI is for "I have genuinely nothing to do, wake me when the world changes." WFE is for "I'm waiting for one specific, software-coordinated thing — a lock, a flag, a peer — wake me cheaply when a peer signals." A naive lock spins and burns power; the architected idiom below sleeps between contention events.

; Arm64 ticket-style spin: sleep between contention events, never busy-burn
spin:   ldaxr  w1, [x0]        ; load-exclusive: arm the monitor on the lock
        cbnz   w1, wait        ; locked? go wait for an event
        stxr   w2, w3, [x0]    ; try to take it
        cbnz   w2, spin        ; lost the race, retry
        ret                    ; got the lock
wait:   wfe                    ; SLEEP — woken when the owner's release store
        b      spin            ;   clears OUR exclusive monitor: that IS an event.
        ; unlock side:  stlr wzr,[x0]   <- the store alone wakes WFE waiters;
        ;               no explicit SEV is needed for an exclusive-based lock.

Interrupts — injecting "now" into a sequential machine

A CPU executes one instruction stream, in order. The world is asynchronous and arrives whenever it likes. An interrupt is the hardware that splices an external "something happened" into that orderly stream — and it's the very signal that wakes a WFI-parked core.

Without interrupts your only option is polling: loop, read a status register, repeat — which is exactly the energy-wasting busy-wait Layer 0 told us to avoid, and it adds latency proportional to your poll interval. An interrupt inverts the control flow: the device raises a line, and the CPU — wherever it was — saves its place and diverts to a handler. Latency becomes the hardware's signal-propagation time, not your software's loop period.

On Arm, the traffic controller is the GIC

You can't let every device yank the core's exception input directly — you'd have no prioritization, no routing across many cores, no way to mask selectively. The Generic Interrupt Controller (GICv3/v4) is the arbiter. Three pieces:

• Distributor (GICD) — the global router. Owns SPIs (Shared Peripheral Interrupts, IDs 32–1019): which core gets each one, at what priority, with what enable.
• Redistributor (GICR) — one per core. Owns the per-core PPIs (Private Peripheral Interrupts, 16–31, e.g. the per-core timer) and SGIs (Software Generated Interrupts, 0–15, used for core-to-core IPIs).
• CPU interface (ICC_* system registers) — the per-core gate that actually presents an interrupt to the PE, enforces the priority mask, and handles acknowledge and end-of-interrupt.

An interrupt walks a small state machine: Inactive → Pending (asserted) → Active (the core acknowledged it by reading ICC_IAR1_EL1, which returns the interrupt ID) → Inactive again only after the core writes ICC_EOIR1_EL1 (End Of Interrupt). Priority and the running-priority mechanism let a higher-priority interrupt preempt a lower one mid-handler.

The ISR — what actually runs when the core divertsISR

The Interrupt Service Routine is the code the hardware jumps to. Its design is dominated by one rule: you are running with the world stalled behind you, so do the minimum and get out.

When an interrupt is taken, the PE does a fixed sequence in hardware: it banks the return address into ELR_ELx, the processor state into SPSR_ELx, sets the new PSTATE (masking further interrupts), and jumps to an address computed from the Vector Base Address Register, VBAR_ELx. The Arm64 vector table is 16 entries of 0x80 bytes, indexed by exception type (Sync / IRQ / FIQ / SError) crossed with where it came from (same EL with SP0, same EL with SPx, lower EL in AArch64, lower EL in AArch32).

The entry stub then saves context (the general-purpose registers the handler will clobber), runs the handler body, restores context, and executes ERET to atomically restore PC and PSTATE. Because all of this happens with interrupts masked and a task frozen underneath, the discipline is universal:

• Top half (the ISR proper): acknowledge the device, clear the interrupt source, grab the minimum data, schedule the real work. Microseconds.
• Bottom half / deferred work: the heavy lifting — softirqs, tasklets, threaded IRQs (Linux), or DPCs (Windows) — runs later with interrupts re-enabled, so it can't extend worst-case latency for everyone else.

Callback handlers — turning one ISR into many behaviours

A callback handler is a function you hand to a lower layer ahead of time, to be invoked later when a condition occurs. It's the software hinge that decouples "an interrupt happened" from "here is the specific thing to do about it."

The vector table gives you a handful of fixed entry points, but a real system has hundreds of interrupt sources. The bridge is a registration table: a software array mapping interrupt ID → function pointer (plus an opaque void *context). The generic top-half ISR reads the acknowledged interrupt ID from the GIC, indexes the table, and calls back into whichever driver registered for that ID. The driver never touches the vector table; it just says "call me when IRQ 47 fires."

/* Registration: a driver hands the framework a callback ahead of time */
typedef void (*irq_cb_t)(unsigned id, void *ctx);
struct { irq_cb_t fn; void *ctx; } table[1020];

void register_handler(unsigned id, irq_cb_t fn, void *ctx) {
    table[id].fn = fn; table[id].ctx = ctx;   /* store the hook */
}

/* The single generic ISR — dispatches to whoever registered */
void gic_top_half(void) {
    unsigned id = read_iar();           /* ack: who fired? */
    if (table[id].fn) table[id].fn(id, table[id].ctx);  /* CALLBACK */
    write_eoir(id);                    /* end of interrupt */
}

The same pattern recurs everywhere above the metal — a timer subsystem invokes your callback when a timeout expires; a mailbox driver (next layer) invokes your callback when a message lands; an SCMI stack invokes your callback when an asynchronous notification arrives. Callbacks are how each layer says "I'll handle the plumbing and the timing; you give me the policy." Inversion of control is the load-bearing idea: the lower layer owns when, you own what.

Mailbox & doorbell — how two processors talk

A modern SoC is not one CPU; it's a federation — application cores plus a small System Control Processor and other microcontrollers. A mailbox is the hardware that lets one ring a bell on another. The payload rides in shared memory; the mailbox just delivers the "go look" signal — which arrives as an interrupt.

Decompose the problem. Two processors share DRAM/SRAM, so passing data is easy: writer stores it in an agreed buffer. The hard part is notification with synchronization — the reader must learn the data is ready, and the two sides must not stomp each other. Polling shared memory works but reintroduces the Layer-0 energy waste. So hardware gives you a doorbell: a register the sender writes; the write sets a bit that asserts an interrupt on the receiver's core. The receiver's ISR (Layer 3) dispatches a callback (Layer 4) that reads the shared buffer.

Arm's reference IP is the MHU (Message Handling Unit): a set of channels, each with a register whose write raises a receiver interrupt and which the receiver clears to re-arm. The canonical handshake:

Notice what just composed: the mailbox is built out of shared memory + an interrupt + an ISR + a callback. Every lower rung of the ladder is load-bearing here. What's still missing is meaning — the bytes in that shared buffer are just bytes until both sides agree on a format. That agreement is the next layer.

SCMI — the shared language for power & system control

The System Control and Management Interface (Arm DEN 0056) is the standardized message format and command set spoken over that mailbox. It lets a non-trusted agent (an OS, a hypervisor, another core) ask a trusted platform (the SCP firmware) to change clocks, voltages, power domains, and performance levels — without the agent ever touching the underlying PMIC or clock-tree registers directly.

Why centralize this at all? Power and clock resources are shared across many requesters and are safety- and stability-critical. If every OS, secure-world service, and coprocessor wrote voltage registers directly, they'd race and brick the chip. SCMI makes the SCP the single arbiter: agents express intent ("I want performance level 5 on this domain"), and the platform firmware reconciles all requests, enforces limits, and actually programs the hardware. This is the same separation-of-policy-and-mechanism idea from Layer 4, raised to a whole-SoC contract.

The protocol family

SCMI is split into independent protocols, each with its own ID, so a platform implements only what it supports:

• Base (0x10) — discovery: vendor, version, which protocols exist.
• Power domain (0x11) & System power (0x12) — turn domains on/off, suspend/shutdown.
• Performance (0x13) — DVFS. The OS's cpufreq governor lives here, requesting performance levels that map to operating points (frequency + voltage).
• Clock (0x14), Sensor (0x15), Reset (0x16), Voltage (0x17) — plus newer additions (pin control, power-capping).

Anatomy of a message header

Every SCMI message begins with a 32-bit header. Hover the fields:

The four message types map onto the call patterns you'd expect: a command (request), an immediate response, a delayed response (the platform says "working on it" and notifies completion later — itself delivered through the doorbell/ISR/callback chain), and unsolicited notifications (e.g. "performance was limited because the chip got hot").

SCMI mailbox — protocol meets transport

SCMI is transport-agnostic; the SCMI mailbox is its most common transport binding — the concrete realization of Layer 6's messages over Layer 5's hardware. A region of shared memory carries the header + payload, and an MHU doorbell signals each direction.

The shared-memory channel has a defined layout, and the part that makes it safe is a single channel-status word with a free/busy bit. The protocol is a strict ownership ping-pong:

• Agent waits until the channel reads free, then writes the header + payload into shared memory and marks the channel busy.
• Agent rings the A2P doorbell (agent-to-platform). This is an interrupt on the SCP, handled by an ISR, dispatched to the SCMI callback.
• SCP parses the header, routes by protocol_id to the right protocol handler (here: Performance), executes (reconciles requests, programs the clock/voltage), writes the response back into the same shared buffer, and marks the channel free.
• SCP rings the P2A doorbell (or the agent polls the status bit). The agent's ISR fires, its callback reads the response, and matches it to the request by token.

DMA — getting the core out of the data path entirelyDMA

Even a sleeping-and-waking core wastes itself if it copies bytes by hand. Direct Memory Access is a dedicated engine that moves data between memory and peripherals (or memory and memory) on its own, freeing the core to sleep (WFI) until the move is done — completion announced, of course, by an interrupt.

Consider the alternative — programmed I/O: the core executes a load/store per word. Moving a 1 MB buffer is hundreds of thousands of instructions during which the core does nothing but shuttle data, blocking on every slow peripheral access. A DMA controller flips this. The core acts as a manager: it builds a descriptor — source address, destination address, length, and control flags — programs the DMA channel, and issues "go." The DMA engine then arbitrates for the interconnect (AXI/CHI), bursts the data across while the core does other work or sleeps, and raises a completion interrupt when finished.