kernel/linux.git/drivers/remoteproc/Kconfig, branch linux-7.1.y

remoteproc: imx_rproc: Add support for System Manager LMM API

2026-01-13T16:52:35+00:00

i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and one Cortex-M7 core. The System Control Management Interface(SCMI) firmware runs on the M33 core. The i.MX95 SCMI firmware named System Manager(SM) includes vendor extension protocols, Logical Machine Management(LMM) protocol and CPU protocol and etc. Depending on SM configuration, M7 can be used as follows: (1) M7 in a separate Logical Machine (LM) from A55 cores, that Linux can't control (2) M7 in a separate LM from A55 cores that Linux can control using LMM protocol. (3) M7 runs in same Logical Machine as A55 cores, so Linux can control it using CPU protocol So extend the driver to using LMM and CPU protocol to manage the M7 core. - Compare linux LM ID(got using scmi_imx_lmm_info) and M7 LM ID(the ID is fixed as 1 in SM firmware if M7 is in a separate LM), if Linux LM ID is not same as M7 LM ID(linux and M7 in same LM), use LMM protocol to start/stop. CPU protocol support will be added in the following patch. Whether using CPU or LMM protocol to start/stop, the M7 status detection could use CPU protocol to detect started or not. So in imx_rproc_detect_mode, use scmi_imx_cpu_started to check the status of M7. - For above case (1) and (2), Use SCMI_IMX_LMM_POWER_ON to detect whether the M7 LM is under control of A55 LM. - For above case , after using SCMI_IMX_LMM_POWER_ON to check permission, SCMI_IMX_LMM_SHUTDOWN API should be called to shutdown the M7 LM to save power only when M7 LM is going to be started by remoteproc framework. Otherwise bypass SCMI_IMX_LMM_SHUTDOWN API if M7 LM is started before booting Linux. Current setup relies on pre-Linux software(U-Boot) to do M7 TCM ECC initialization. In future, we could add the support in Linux to decouple U-Boot and Linux. Reviewed-by: Daniel Baluta Reviewed-by: Frank Li Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-4-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier

remoteproc: qcom: pas: Conclude the rename from adsp

2025-06-11T03:03:47+00:00

The change that renamed the driver from "adsp" to "pas" didn't change any of the implementation. The result is an aesthetic eyesore, and confusing to many. Conclude the rename of the driver, by updating function, structures and variable names to match what the driver actually is. The "Hexagon v5" is also dropped from the name and Kconfig, as this isn't correct either. No functional change. Fixes: 9e004f97161d ("remoteproc: qcom: Rename Hexagon v5 PAS driver") Signed-off-by: Bjorn Andersson Reviewed-by: Wasim Nazir Link: https://lore.kernel.org/r/20250605-pas-rename-v2-1-f1c89e49e691@oss.qualcomm.com Signed-off-by: Bjorn Andersson

remoteproc: k3-r5: Add compile testing support

2024-10-18T15:59:21+00:00

This driver can be compile tested on non-K3 architectures as long as TI_SCI_PROTOCOL is not compiled as a module. Enable this here to improve this driver's build coverage. Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20241016164141.93401-3-afd@ti.com Signed-off-by: Mathieu Poirier

remoteproc: k3-dsp: Add compile testing support

2024-10-18T15:59:21+00:00

mailbox, remoteproc: k3-m4+: fix compile testing

2024-10-16T15:49:24+00:00

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in. arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe': ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle' Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3. Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Fixes: ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies") Fixes: 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20241007132441.2732215-1-arnd@kernel.org Signed-off-by: Mathieu Poirier

Merge tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox

2024-09-29T16:53:04+00:00

Pull mailbox updates from Jassi Brar: - fix kconfig dependencies (mhu-v3, omap2+) - use devie name instead of genereic imx_mu_chan as interrupt name (imx) - enable sa8255p and qcs8300 ipc controllers (qcom) - Fix timeout during suspend mode (bcm2835) - convert to use use of_property_match_string (mailbox) - enable mt8188 (mediatek) - use devm_clk_get_enabled helpers (spreadtrum) - fix device-id typo (rockchip) * tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: mailbox, remoteproc: omap2+: fix compile testing dt-bindings: mailbox: qcom-ipcc: Document QCS8300 IPCC dt-bindings: mailbox: qcom-ipcc: document the support for SA8255p dt-bindings: mailbox: mtk,adsp-mbox: Add compatible for MT8188 mailbox: Use of_property_match_string() instead of open-coding mailbox: bcm2835: Fix timeout during suspend mode mailbox: sprd: Use devm_clk_get_enabled() helpers mailbox: rockchip: fix a typo in module autoloading mailbox: imx: use device name in interrupt name mailbox: ARM_MHU_V3 should depend on ARM64

mailbox, remoteproc: omap2+: fix compile testing

2024-09-27T14:11:05+00:00

Selecting CONFIG_OMAP2PLUS_MBOX while compile testing causes a build failure: WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [m]: - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y]) Using 'select' to force-enable another subsystem is generally a mistake and causes problems such as this one, so change the three drivers that link against this driver to use 'depends on' instead, and ensure the driver itself can be compile tested regardless of the platform. When compile-testing without CONFIG_TI_SCI_PROTOCOL=m, there is a chance for a link failure, so add a careful dependency on that. arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe': ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle' Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Signed-off-by: Arnd Bergmann Reviewed-by: Mathieu Poirier Reviewed-by: Andrew Davis Reviewed-by: Martyn Welch Signed-off-by: Jassi Brar

remoteproc: k3-m4: use the proper dependencies

2024-09-24T19:48:35+00:00

The TI_K3_M4_REMOTEPROC Kconfig entry selects OMAP2PLUS_MBOX, but that driver in turn depends on other things, which the k4-m4 driver didn't. This causes a Kconfig time warning: WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [m]: - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y]) because you can't select something that is unavailable. Make the dependencies for TI_K3_M4_REMOTEPROC match those of the OMAP2PLUS_MBOX driver that it needs. Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Cc: Bjorn Andersson Cc: Martyn Welch Cc: Hari Nagalla Cc: Andrew Davis Cc: Mathieu Poirier Signed-off-by: Linus Torvalds

remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

2024-08-21T17:22:54+00:00

The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in the MCU domain. This core is typically used for safety applications in a stand alone mode. However, some application (non safety related) may want to use the M4F core as a generic remote processor with IPC to the host processor. The M4F core has internal IRAM and DRAM memories and are exposed to the system bus for code and data loading. A remote processor driver is added to support this subsystem, including being able to load and boot the M4F core. Loading includes to M4F internal memories and predefined external code/data memories. The carve outs for external contiguous memory is defined in the M4F device node and should match with the external memory declarations in the M4F image binary. The M4F subsystem has two resets. One reset is for the entire subsystem i.e including the internal memories and the other, a local reset is only for the M4F processing core. When loading the image, the driver first releases the subsystem reset, loads the firmware image and then releases the local reset to let the M4F processing core run. Signed-off-by: Martyn Welch Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis Tested-by: Wadim Egorov Link: https://lore.kernel.org/r/20240802152109.137243-4-afd@ti.com Signed-off-by: Mathieu Poirier

remoteproc: qcom: select AUXILIARY_BUS

2024-07-01T17:01:17+00:00

The QCOM_PD_MAPPER implementation made Qualcomm remoteproc drivers use auxiliary bus for the pd-mapper subdevice. Add necessary dependency. Reported-by: Mark Brown Fixes: 5b9f51b200dc ("remoteproc: qcom: enable in-kernel PD mapper") Signed-off-by: Dmitry Baryshkov Reviewed-by: Chris Lew Link: https://lore.kernel.org/r/20240626-qcom-pd-mapper-fix-deps-v1-2-644678dc4663@linaro.org Signed-off-by: Bjorn Andersson