Remoteproc Driver Analysis: Evolution and Hybrid Implementations

remoteproc_analysis.md

Remoteproc Driver Analysis: Evolution and Hybrid Implementations

1. Temporal Trends: Authorship Date vs. Implementation Style

The choice between the Standard Reset API and Syscon/Regmap is primarily driven by hardware architecture, but temporal trends show an evolution in how developers handle hardware complexity.

Comprehensive Authorship Date Table

The following table shows the original authorship date (first commit) for all drivers analyzed, sorted by date. This helps visualize the trends.

Date	Driver	Category
2011-10-20	omap_remoteproc.c	Mixed
2013-04-09	da8xx_remoteproc.c	Reset API
2015-05-22	wkup_m3_rproc.c	Reset API
2016-01-12	st_remoteproc.c	Mixed
2016-08-12	qcom_wcnss.c	Custom
2016-10-18	st_slim_rproc.c	Custom
2017-06-13	keystone_remoteproc.c	Mixed
2017-08-17	imx_rproc.c	Syscon/Regmap
2018-06-07	qcom_q6v5_wcss.c	Mixed
2018-09-24	qcom_q6v5_adsp.c	Mixed
2018-09-24	qcom_q6v5_mss.c	Mixed
2018-09-24	qcom_q6v5_pas.c	Custom
2019-05-14	stm32_rproc.c	Mixed
2019-11-12	mtk_scp.c	Custom
2020-05-15	ingenic_rproc.c	Custom
2020-07-21	ti_k3_dsp_remoteproc.c	Reset API
2020-10-02	ti_k3_r5_remoteproc.c	Reset API
2020-12-08	pru_rproc.c	Custom
2021-09-21	meson_mx_ao_arc.c	Mixed
2021-10-11	imx_dsp_rproc.c	Mixed
2021-12-07	rcar_rproc.c	Reset API
2022-11-14	xlnx_r5_remoteproc.c	Custom
2024-08-02	ti_k3_m4_remoteproc.c	Reset API

Note: Dates represent the author date of the first commit in the repository.

Trend Analysis

• Early (2011-2015): Mix of Reset API (DA8xx, Wkup M3) and Mixed/Platform specific (OMAP).
• Middle (2016-2019): High prevalence of Mixed and Custom implementations (STM32, i.MX, QCOM). This reflects a period of complex SoC integration where standard APIs struggled to cover all requirements (power + reset + status + firmware authentication).
• Modern (2020-Present): A return to Reset API (TI K3 family, R-Car) where possible, but Mixed (i.MX DSP) remains the standard for complex subsystems like DSPs.

---

2. Deep Dive: The Hybrid Approach in imx_dsp_rproc.c

The imx_dsp_rproc.c driver is a modern (2021) reference that uses both mechanisms to manage the complex boot sequence of HiFi DSPs.

Why use "Both"?

The driver manages different SoC variants (i.MX8MP, i.MX8ULP, i.MX8QM), each requiring a slightly different handshake.

i.MX8MP Implementation

• Reset API (reset_control): Used for the "Run/Stall" control (priv->run_stall). This manages whether the core is allowed to execute instructions.
• Direct Memory Access (ioremap): It manually maps the Debug Access Port (DAP) registers (IMX8M_DAP_DEBUG) to toggle the CORERESET bit.
• The logic: Toggling a core reset via the DAP is a low-level operation that often lacks a dedicated driver in the drivers/reset/ subsystem. Instead of writing a new reset driver for a single bit, the remoteproc author handles it locally.

i.MX8ULP Implementation

• Regmap (syscon): Uses regmap_update_bits for the SIM_LPAV registers. This block handles power, clocks, and resets for the "Low Power Audio Video" domain.
• Firmware Calls (SMC): Calls arm_smccc_smc() to request the Secure World to configure resource isolation (XRDC) before starting the core.

---

3. Reset Mechanism Breakdown

Below is the detailed categorization of drivers based on their reset handling mechanism, as requested.

1. Standard Reset API (reset_control_*)

Drivers that primarily use the Linux Reset Controller framework.

• drivers/remoteproc/da8xx_remoteproc.c
• drivers/remoteproc/rcar_rproc.c
• drivers/remoteproc/ti_k3_common.c
• drivers/remoteproc/ti_k3_dsp_remoteproc.c
• drivers/remoteproc/ti_k3_m4_remoteproc.c
• drivers/remoteproc/ti_k3_r5_remoteproc.c
• drivers/remoteproc/wkup_m3_rproc.c

2. Syscon/Regmap Direct Access

Drivers that use regmap/syscon to directly manipulate reset registers.

• drivers/remoteproc/imx_rproc.c

3. Both (Mixed Usage)

Drivers that use both the Reset API and Regmap/Syscon. This is common for complex DSPs or cores requiring a "reset then stall" sequence.

• drivers/remoteproc/imx_dsp_rproc.c
• drivers/remoteproc/keystone_remoteproc.c
• drivers/remoteproc/meson_mx_ao_arc.c
• drivers/remoteproc/omap_remoteproc.c
• drivers/remoteproc/qcom_q6v5_adsp.c
• drivers/remoteproc/qcom_q6v5_mss.c
• drivers/remoteproc/qcom_q6v5_wcss.c
• drivers/remoteproc/stm32_rproc.c
• drivers/remoteproc/st_remoteproc.c

4. Neither / Custom / Internal

Drivers utilizing direct memory writes, firmware calls (SCM), or platform-specific internal headers.

• drivers/remoteproc/ingenic_rproc.c
• drivers/remoteproc/mtk_scp.c
• drivers/remoteproc/pru_rproc.c
• drivers/remoteproc/qcom_q6v5_pas.c
• drivers/remoteproc/xlnx_r5_remoteproc.c
• (and other qcom helper modules)

---

4. Relevance to AD598 (Analog Devices)

When working with DSP cores like those in the AD598, the imx_dsp_rproc.c model is highly instructive for several reasons:

1. Stall-Before-Boot Sequence: Unlike a standard CPU, a DSP often requires a specific sequence:

   • Reset (Hold in reset)
   • Stall (Release reset, but keep core halted)
   • Load (Copy firmware to TCM/SRAM)
   • Run (Release stall) Standard Reset APIs often only support assert/deassert. If your "Stall" bit is in a general "System Control" register, you will likely need regmap to manage it.

2. Memory Consistency: DSPs often have tightly coupled memory (TCM) that requires 32-bit aligned access. Note how imx_dsp_rproc.c implements its own imx_dsp_rproc_memcpy to ensure hardware-compliant writes to the DSP's instruction RAM (IRAM).

Recommendation

If your AD598 integration involves a dedicated reset line and a separate "Stall" or "Vector Table" register in a system-wide block, do not hesitate to use a hybrid approach. Use reset_control for the main line and syscon/regmap for the specific configuration bits that don't fit the standard Reset API.