IPC Infrastructure (IPC3 & IPC4)

The Inter-Processor Communication (IPC) infrastructure in Sound Open Firmware (SOF) is the primary messaging conduit and control plane bridging the host operating system (mainline Linux ASoC drivers, Windows audio subsystems) and the Digital Signal Processor (DSP) firmware. It coordinates audio pipeline topologies, runtime module parameter updates, hardware interface configurations, stream power states, and real-time diagnostic telemetry.

This guide provides a high-level conceptual overview of the IPC messaging framework, hardware mailbox windows, doorbell interrupt handshakes, deferred Zephyr work queues, protocol evolution from IPC3 to IPC4, dynamic module binding, asynchronous telemetry, and multi-core Inter-Domain Communication (IDC) without focusing on low-level C code.

—

1. IPC Infrastructure & Communication Model

The Dual Planes of Inter-Processor Communication

In modern audio systems, the DSP operates as an autonomous processor requiring tightly coordinated, bidirectional communication with the host kernel:

1. The Control Plane (Host to DSP): * Pipeline Topology Instantiation: Dynamically assembling audio pipelines, allocating memory buffers, and binding processing components. * Parameter Configuration: Applying volume curves, equalizer filter coefficients, dynamic range compressor profiles, and microphone calibration blobs. * Stream State Machine: Transitioning audio streams through operational states (PREPARE, START, PAUSE, STOP, RESET). * Power Management: Coordinating clock scaling, core sleep states, and host D0ix runtime power transitions.

2. The Telemetry & Event Plane (DSP to Host): * Stream Position Tracking: High-frequency DMA buffer pointer updates allowing the host ALSA subsystem to maintain accurate audio-video synchronization without host polling. * XRUN Alerts: Instantaneous notifications when an audio buffer underrun (starvation) or overrun (overflow) occurs. * Diagnostic Traces & Crash Telemetry: Streaming real-time debug log packets and exception backtraces directly into host trace buffers.

System-Level Architecture

Figure 35 System-Level IPC Architecture: Host Driver to DSP Firmware Dispatch

—

2. Hardware Mailbox Architecture & Memory Windows

Inter-processor messaging relies on dedicated Shared SRAM Windows mapped directly across PCIe Base Address Registers (BARs) on the host and accessible over the DSP system interconnect.

Shared Memory Mailbox Windows

Modern SOF platforms partition shared SRAM into distinct functional memory windows:

Window	Direction	Architectural Purpose
Window 0 (Outbox & Status)	DSP to Host	Stores firmware reply payloads, asynchronous notifications, boot status words, and firmware version descriptors.
Window 1 (Inbox)	Host to DSP	Receives incoming host command headers, large parameter configuration blobs, and pipeline state commands.
Window 2 (Debug & Traces)	DSP to Host	Real-time debug log buffer accessed by host logging daemons (such as sof-logger or trace DMA).
Window 3 (Stream Payloads)	Bidirectional	Hosts large coefficient matrices (e.g. 10-band equalizer filter tables) and page-table descriptors for host DMA gateways.

The Doorbell Interrupt Handshake Protocol

To coordinate memory access without race conditions, the host and DSP follow a strict Doorbell Handshake Protocol:

Figure 36 Bidirectional Hardware Mailbox and Doorbell Handshake Sequence

1. Atomic Ownership: While the Busy bit is asserted, the host is barred from overwriting the inbox. Ownership belongs exclusively to the DSP.

2. Deterministic Acknowledgment: The DSP signals completion by asserting the Done interrupt and writing status codes directly into Window 0, ensuring that the host driver never experiences mailbox data corruption.

—

3. Core Framework & Zephyr Thread Handoff

Why IPC Processing is Decoupled from Interrupts

When the host triggers a mailbox doorbell interrupt, the DSP responds inside a hardware Interrupt Service Routine (ISR). However, executing the entire IPC message within the ISR is strictly forbidden in real-time audio systems:

• Real-Time Latency Spikes: Parsing complex pipeline topologies, allocating dynamic heaps, or configuring DAI clocks requires thousands of cycles. If executed inside an ISR, audio DMA interrupts would be delayed, causing immediate audio glitches and buffer underruns.

• Blocking & DMA Waits: Certain commands require waiting for DMA page table synchronization or inter-core responses. Interrupt service routines cannot sleep or block.

Deferred Work Queue Architecture

Sound Open Firmware solves this by delegating all command handling to the Zephyr Work Queue subsystem (k_work):

Figure 37 Mailbox ISR to Zephyr Work Queue Handoff and Message State Machine

Message Lifecycle & Backpressure Handling

Firmware-initiated messages (such as notifications or stream position updates) are governed by an internal state machine:

1. State Progression: Messages transition through UNREGISTERED $rightarrow$ QUEUED $rightarrow$ PROCESSING $rightarrow$ ACK_PENDING $rightarrow$ COMPLETED.

2. Outbox Message Queueing: If the DSP needs to send an asynchronous notification while the hardware mailbox is already occupied by a previous pending message, the core IPC framework places the new message onto an internal transmission list (ipc_msg_send), preventing message loss under heavy host bus traffic.

—

4. Protocol Generations: IPC3 vs. IPC4

Sound Open Firmware supports two major generations of the Inter-Processor Communication protocol. While older hardware architectures use IPC3, all modern Intel platforms (Tiger Lake, Meteor Lake, Arrow Lake, Panther Lake) and contemporary designs utilize IPC4.

Architectural Comparison

Figure 38 Structural Comparison: IPC3 Flat Scalar Model vs IPC4 Dynamic Compound Object Model

Key Differences

Dimension	IPC3 (Scalar Architecture)	IPC4 (Compound Object Architecture)
Topology Model	Static: Entire pipeline graph is compiled into a monolithic topology binary and parsed at driver probe.	Dynamic: Pipelines and modules are constructed, bound, and torn down dynamically at runtime via individual IPC commands.
Component Addressing	Global 32-bit component IDs assigned statically by the topology compiler.	Modular 32-bit Tuple: module_id (algorithm type UUID) combined with an instance_id (unique runtime instance).
Command Density	Scalar: Each operation requires a separate round-trip command/response handshake.	Compound: Multiple operations (create pipeline, instantiate modules, bind pins) can be batched in a single transaction.
Memory Footprint	Graph nodes and buffers are pre-allocated statically during system boot.	Memory heaps are allocated and reclaimed on-demand as audio streams open and close.

—

5. Pipeline Lifecycle & Dynamic Graph Control

In IPC4, the host operating system dynamically constructs, connects, and controls the audio processing graph:

Dynamic Graph Instantiation Flow

Figure 39 IPC4 Dynamic Pipeline Construction and Streaming Sequence

Core State Machine Integration

The host controls pipeline progression by sending ipc4_set_pipeline_state() commands. The IPC framework maps these high-level host requests directly into SOF core state machine triggers:

• ``IPC4_PIPELINE_STATE_RESET`` $rightarrow$ Re-initializes buffers and resets filter delay lines.

• ``IPC4_PIPELINE_STATE_PAUSED`` $rightarrow$ Halts active processing while preserving audio parameters and buffer memory.

• ``IPC4_PIPELINE_STATE_RUNNING`` $rightarrow$ Dispatches COMP_TRIGGER_START, enabling real-time timer or DMA interrupts.

• ``IPC4_PIPELINE_STATE_EOS`` $rightarrow$ Signals End-Of-Stream, allowing remaining samples in ring buffers to drain cleanly without truncation.

—

6. Firmware-Initiated Notifications & Telemetry

While commands flow from Host to DSP, the IPC infrastructure also provides a high-efficiency path for Firmware-Initiated Asynchronous Notifications (DSP to Host).

Asynchronous Telemetry Flow

Figure 40 Firmware-Initiated Asynchronous Notification Architecture

Notification Types & Purpose

1. Stream Position Updates: * Sent periodically as hardware DMA transfers audio frames to/from host memory. * Updates host ALSA ring buffer pointers, allowing user-space applications to track playback timing with microsecond accuracy.

2. XRUN Notifications: * Instantly alerts the host kernel if an audio underrun or overrun occurs, enabling the host driver to log diagnostics and initiate recovery.

3. Firmware Panic & Error Reports: * In the rare event of a CPU exception, watchdog timeout, or kernel assert, the exception handler formats a panic descriptor containing CPU register states, execution backtraces, and memory faults into Window 0 before resetting the DSP.

—

7. Multi-Core IPC & Inter-Domain Communication (IDC)

Modern Intel and partner DSPs feature multi-core architectures (Dual-Core, Quad-Core, or Octa-Core). However, the physical PCIe mailbox hardware and doorbell interrupt registers are physically routed only to Core 0.

Core 0 as the Central Host Gateway

Core 0 acts as the central gateway for all external host communication:

• All incoming host doorbell interrupts are caught exclusively by Core 0’s mailbox ISR.

• All outgoing notifications and replies must be written to Window 0 by Core 0.

Inter-Domain Communication (IDC) Architecture

When the host issues an IPC command targeting a pipeline, audio module, or power state located on a secondary core (such as Core 1, Core 2, or Core 3), SOF utilizes Inter-Domain Communication (IDC):

Figure 41 Multi-Core IPC Routing Topology: Core 0 (Host Gateway) and Core 1 (Secondary Core) via IDC

1. Transparent Routing: The host driver remains completely agnostic to core partitioning. The host targets a module by ID; Core 0’s IPC framework transparently resolves which core owns the module.

2. IDC Doorbell Interrupts: Core 0 copies the message payload into shared inter-core SRAM and triggers a hardware inter-core interrupt to awaken Core 1.

3. Status Aggregation: When Core 1 finishes processing the command, it returns an acknowledgment via IDC. Core 0 aggregates the response and completes the transaction to the host.

—

8. Upstream Code References & Related Guides

For developers seeking low-level C implementation details, data structures, and function prototypes:

• Upstream IPC Specifications: * Core IPC framework architecture: thesofproject/sof: src/ipc/README.md. * IPC3 scalar architecture: thesofproject/sof: src/ipc/ipc3/README.md. * IPC4 dynamic object architecture: thesofproject/sof: src/ipc/ipc4/README.md.

• Core Source Files:

  • src/ipc/ipc-common.c: Core message state machine, dispatcher, and outbox queue management.

  • src/ipc/ipc-zephyr.c: Zephyr work queue thread handoff (ipc_work_handler).

  • src/ipc/ipc3/handler.c: IPC3 global command dispatcher (stream, DAI, PM).

  • src/ipc/ipc4/handler-kernel.c: IPC4 primary header parser, global pipeline state engine, and module dispatcher.

  • src/ipc/ipc4/ams_helpers.c: IPC4 dynamic module instantiation and pin binding helpers.

  • src/ipc/notification_pool.c: Pre-allocated asynchronous notification pool allocator.

• Core Header Files:

  • src/include/ipc/header.h: Common IPC message header definitions and command enums.

  • src/include/ipc/stream.h: Stream parameter, trigger, and position payload definitions.

  • src/include/ipc/topology.h: Topology IPC structures and component creation payloads.

  • src/include/sof/ipc/schedule.h: Scheduling domain integration with IPC work queues.

Related Guides

• Pipeline Architecture: How IPC commands dynamically create, prepare, and trigger audio pipelines.

• Module Framework Architecture: How IPC parameter blobs configure processing modules and runtime algorithms.

• Scheduler Architecture: Real-time scheduling domains (LL, DP, TWB) that coordinate with IPC work queues.

• Audio Buffer Management: Allocating and binding circular ring buffers during IPC pipeline construction.

• Firmware Initialization & Boot Architecture: Boot flow, hardware mailbox FW Ready handshake, and Zephyr initialization.

• ALSA Topology 2.0 Architecture & Developer Guide: How ALSA Topology 2.0 configuration files generate IPC topology commands.