remoteproc: qcom: Unify user-visible "Qualcomm" name

Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qu

remoteproc: qcom: Unify user-visible "Qualcomm" name

Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260422083334.84294-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

show more ...

remoteproc: Dead code cleanup in Kconfig for STM32_RPROC

There is already an 'if REMOTEPROC' condition wrapping this config option,
making the 'depends on REMOTEPROC' statement a duplicate dependenc

remoteproc: Dead code cleanup in Kconfig for STM32_RPROC

There is already an 'if REMOTEPROC' condition wrapping this config option,
making the 'depends on REMOTEPROC' statement a duplicate dependency
(dead code).

I propose leaving the outer 'if REMOTEPROC...endif' and removing the
individual 'depends on REMOTEPROC' statement.

This dead code was found by kconfirm, a static analysis tool for Kconfig.

Signed-off-by: Julian Braha <julianbraha@gmail.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20260417221337.286313-1-julianbraha@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

remoteproc: imx_rproc: Add support for System Manager LMM API

i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
one Cortex-M7 core. The System Control Management Interface(SCMI)
firmware

remoteproc: imx_rproc: Add support for System Manager LMM API

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 <daniel.baluta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-4-d2fefb36263d@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

remoteproc: qcom: pas: Conclude the rename from adsp

The change that renamed the driver from "adsp" to "pas" didn't change
any of the implementation. The result is an aesthetic eyesore, and
confusin

remoteproc: qcom: pas: Conclude the rename from adsp

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 <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Wasim Nazir <quic_wasimn@quicinc.com>
Link: https://lore.kernel.org/r/20250605-pas-rename-v2-1-f1c89e49e691@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

show more ...

remoteproc: k3-r5: Add compile testing support

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 driv

remoteproc: k3-r5: Add compile testing support

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 <afd@ti.com>
Link: https://lore.kernel.org/r/20241016164141.93401-3-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

remoteproc: k3-dsp: Add compile testing support

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 dri

remoteproc: k3-dsp: Add compile testing support

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 <afd@ti.com>
Link: https://lore.kernel.org/r/20241016164141.93401-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

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

The k3-m4 remoteproc driver was merged with incorrect dependencies.
Despite multiple people trying to fix this, the version 6.12-rc2
remains broken a

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

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 <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241007132441.2732215-1-arnd@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

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

Pull mailbox updates from Jassi Brar:

- fix kconfig dependencies (mhu-v3, omap2+)

- use devie name in

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

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

show more ...

mailbox, remoteproc: omap2+: fix compile testing

Selecting CONFIG_OMAP2PLUS_MBOX while compile testing
causes a build failure:

WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX
Depen

mailbox, remoteproc: omap2+: fix compile testing

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 <arnd@arndb.de>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

show more ...

remoteproc: k3-m4: use the proper dependencies

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 cau

remoteproc: k3-m4: use the proper dependencies

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 <andersson@kernel.org>
Cc: Martyn Welch <martyn.welch@collabora.com>
Cc: Hari Nagalla <hnagalla@ti.com>
Cc: Andrew Davis <afd@ti.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

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

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

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

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 <martyn.welch@collabora.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240802152109.137243-4-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

remoteproc: qcom: select AUXILIARY_BUS

The QCOM_PD_MAPPER implementation made Qualcomm remoteproc drivers use
auxiliary bus for the pd-mapper subdevice. Add necessary dependency.

Reported-by: Mark

remoteproc: qcom: select AUXILIARY_BUS

The QCOM_PD_MAPPER implementation made Qualcomm remoteproc drivers use
auxiliary bus for the pd-mapper subdevice. Add necessary dependency.

Reported-by: Mark Brown <broonie@kernel.org>
Fixes: 5b9f51b200dc ("remoteproc: qcom: enable in-kernel PD mapper")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Chris Lew <quic_clew@quicinc.com>
Link: https://lore.kernel.org/r/20240626-qcom-pd-mapper-fix-deps-v1-2-644678dc4663@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

show more ...

remoteproc: stm32: use correct format strings on 64-bit

With CONFIG_ARCH_STM32 making it into arch/arm64, a couple of format
strings no longer work, since they rely on size_t being compatible
with %

remoteproc: stm32: use correct format strings on 64-bit

With CONFIG_ARCH_STM32 making it into arch/arm64, a couple of format
strings no longer work, since they rely on size_t being compatible
with %x, or they print an 'int' using %z:

drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc':
drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=]
drivers/remoteproc/stm32_rproc.c:122:40: note: format string is defined here
122 | dev_dbg(dev, "map memory: %pa+%x\n", &mem->dma, mem->len);
| ~^
| |
| unsigned int
| %lx
drivers/remoteproc/stm32_rproc.c:125:30: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=]
drivers/remoteproc/stm32_rproc.c:125:65: note: format string is defined here
125 | dev_err(dev, "Unable to map memory region: %pa+%x\n",
| ~^
| |
| unsigned int
| %lx
drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_get_loaded_rsc_table':
drivers/remoteproc/stm32_rproc.c:646:30: error: format '%zx' expects argument of type 'size_t', but argument 4 has type 'int' [-Werror=format=]
drivers/remoteproc/stm32_rproc.c:646:66: note: format string is defined here
646 | dev_err(dev, "Unable to map memory region: %pa+%zx\n",
| ~~^
| |
| long unsigned int
| %x

Fix up all three instances to work across architectures, and enable
compile testing for this driver to ensure it builds everywhere.

Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...

drivers: remoteproc: Add Xilinx r5 remoteproc driver

This driver enables r5f dual core Real time Processing Unit subsystem
available on Xilinx Zynq Ultrascale MPSoC Platform. RPU subsystem
(cluster)

drivers: remoteproc: Add Xilinx r5 remoteproc driver

This driver enables r5f dual core Real time Processing Unit subsystem
available on Xilinx Zynq Ultrascale MPSoC Platform. RPU subsystem
(cluster) can be configured in different modes e.g. split mode in which
two r5f cores work independent of each other and lock-step mode in which
both r5f cores execute same code clock-for-clock and notify if the
result is different.

The Xilinx r5 Remoteproc Driver boots the RPU cores via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20221114233940.2096237-7-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

remoteproc: qcom: q6v5: fix service routines build errors

When CONFIG_QCOM_AOSS_QMP=m and CONFIG_QCOM_Q6V5_MSS=y, the builtin
driver cannot call into the loadable module's low-level service
function

remoteproc: qcom: q6v5: fix service routines build errors

When CONFIG_QCOM_AOSS_QMP=m and CONFIG_QCOM_Q6V5_MSS=y, the builtin
driver cannot call into the loadable module's low-level service
functions. Trying to build with that config combo causes linker errors.

There are two problems here. First, drivers/remoteproc/qcom_q6v5.c
should #include <linux/soc/qcom/qcom_aoss.h> for the definitions of
the service functions, depending on whether CONFIG_QCOM_AOSS_QMP is
set/enabled or not. Second, the qcom remoteproc drivers should depend
on QCOM_AOSS_QMP iff it is enabled (=y or =m) so that the qcom
remoteproc drivers can be built properly.

This prevents these build errors:

aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `q6v5_load_state_toggle':
qcom_q6v5.c:(.text+0xc4): undefined reference to `qmp_send'
aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_deinit':
(.text+0x2e4): undefined reference to `qmp_put'
aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_init':
(.text+0x778): undefined reference to `qmp_get'
aarch64-linux-ld: (.text+0x7d8): undefined reference to `qmp_put'

Fixes: c1fe10d238c0 ("remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: linux-remoteproc@vger.kernel.org
Cc: Sibi Sankar <sibis@codeaurora.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220115011338.2973-1-rdunlap@infradead.org

show more ...

remoteproc: Add Renesas rcar driver

Renesas Gen3 platform includes a Cortex-r7 processor.

Both: the application cores (A5x) and the realtime core (CR7)
share access to the RAM and devices with the

remoteproc: Add Renesas rcar driver

Renesas Gen3 platform includes a Cortex-r7 processor.

Both: the application cores (A5x) and the realtime core (CR7)
share access to the RAM and devices with the same address map,
so device addresses are equal to the Linux physical addresses.

In order to initialize this remote processor we need to:
- power on the realtime core
- put the firmware in a RAM area
- set the boot address for this firmware (reset vector)
- Deassert the reset

This initial driver allows to start and stop the Cortex R7
processor.

Signed-off-by: Julien Massot <julien.massot@iot.bzh>
Link: https://lore.kernel.org/r/20211207165829.195537-3-julien.massot@iot.bzh
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX

Provide a basic driver to control DSP processor found on NXP i.MX8QM,
i.MX8QXP, i.MX8MP and i.MX8ULP.

Currently it is able to resolv

remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX

Provide a basic driver to control DSP processor found on NXP i.MX8QM,
i.MX8QXP, i.MX8MP and i.MX8ULP.

Currently it is able to resolve addresses between DSP and main CPU,
start and stop the processor, suspend and resume.

The communication between DSP and main CPU is based on mailbox, there
are three mailbox channels (tx, rx, rxdb).

This driver was tested on NXP i.MX8QM, i.MX8QXP, i.MX8MP and i.MX8ULP.

Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1633944015-789-4-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>

show more ...

remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor

Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
Always-On (AO) power-domain. This is typically used for

remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor

Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
Always-On (AO) power-domain. This is typically used for waking up the
ARM cores after system suspend.

The configuration is spread across three different registers:
- AO_REMAP_REG0 which must be programmed to zero, it's actual purpose
is unknown. There is a second remap register which is not used in the
vendor kernel (which served as reference for this driver).
- AO_CPU_CNTL is used to start and stop the ARC core.
- AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose.

To boot the ARC core we also need to enable it's gate clock and trigger
a reset.

The actual code for this ARC core can come from an ELF binary, for
example by building the Zephyr RTOS for an ARC EM4 core and then taking
"zephyr.elf" as firmware. This executable does not have any "rsc table"
so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) and
rproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210921192557.1610709-3-martin.blumenstingl@googlemail.com
[Fixed header file order]
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

remoteproc: qcom: Loosen dependency on RPMSG_QCOM_SMD

There doesn't seem to be any actual build time dependency on the
RPMSG_QCOM_SMD, besides that these drivers should be a module if the smd
rpmsg

remoteproc: qcom: Loosen dependency on RPMSG_QCOM_SMD

There doesn't seem to be any actual build time dependency on the
RPMSG_QCOM_SMD, besides that these drivers should be a module if the smd
rpmsg code is a module. Drop the compile test dependency so that these
drivers can be used without RPMSG_QCOM_SMD being enabled. This is useful
for the qcom SoCs that are using RPMSG_QCOM_GLINK_SMEM instead of
RPMSG_QCOM_SMD and thus don't want to enable the SMD driver when it is
never used.

Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210823235120.1203512-2-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

remoteproc: imx-rproc: Fix IMX_REMOTEPROC configuration

When CONFIG_IMX_REMOTEPROC is y and CONFIG_HAVE_ARM_SMCCC
is not set, compiling errors are encountered as follows:

drivers/remoteproc/imx_rpr

remoteproc: imx-rproc: Fix IMX_REMOTEPROC configuration

When CONFIG_IMX_REMOTEPROC is y and CONFIG_HAVE_ARM_SMCCC
is not set, compiling errors are encountered as follows:

drivers/remoteproc/imx_rproc.o: in function `imx_rproc_stop':
imx_rproc.c:(.text+0x140): undefined reference to `__arm_smccc_smc'
drivers/remoteproc/imx_rproc.o: in function `imx_rproc_detect_mode':
imx_rproc.c:(.text+0x272): undefined reference to `__arm_smccc_smc'
drivers/remoteproc/imx_rproc.o: in function `imx_rproc_start':
imx_rproc.c:(.text+0x5e0): undefined reference to `__arm_smccc_smc'

__arm_smccc_smc is defined when HAVE_ARM_SMCCC is y, so
add dependency on HAVE_ARM_SMCCC in IMX_REMOTEPROC configuration.

Fixes: 79806d32d5aa ("remoteproc: imx_rproc: support i.MX8MN/P")
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20210610031530.26326-1-peng.fan@oss.nxp.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

remoteproc: imx_rproc: fix build error without CONFIG_MAILBOX

Fix build error when CONFIG_MAILBOX is not set:

arm-linux-gnueabi-ld: drivers/remoteproc/imx_rproc.o: in function `imx_rproc_kick':
imx

remoteproc: imx_rproc: fix build error without CONFIG_MAILBOX

Fix build error when CONFIG_MAILBOX is not set:

arm-linux-gnueabi-ld: drivers/remoteproc/imx_rproc.o: in function `imx_rproc_kick':
imx_rproc.c:(.text+0x328): undefined reference to `mbox_send_message'
arm-linux-gnueabi-ld: drivers/remoteproc/imx_rproc.o: in function `imx_rproc_probe':
imx_rproc.c:(.text+0x52c): undefined reference to `mbox_request_channel_byname'
arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x548): undefined reference to `mbox_request_channel_byname'
arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x76c): undefined reference to `mbox_free_channel'
arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x774): undefined reference to `mbox_free_channel'
arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x7c4): undefined reference to `mbox_free_channel'
arm-linux-gnueabi-ld: drivers/remoteproc/imx_rproc.o: in function `imx_rproc_remove':
imx_rproc.c:(.text+0x86c): undefined reference to `mbox_free_channel'
arm-linux-gnueabi-ld: imx_rproc.c:(.text+0x874): undefined reference to `mbox_free_channel'
make: *** [Makefile:1292: vmlinux] Error 1

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20210331122709.3935521-1-weiyongjun1@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

remoteproc: imx_rproc: support i.MX8MQ/M

Add i.MX8MQ dev/sys addr map and configuration data structure
i.MX8MM share i.MX8MQ settings.

Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: M

remoteproc: imx_rproc: support i.MX8MQ/M

Add i.MX8MQ dev/sys addr map and configuration data structure
i.MX8MM share i.MX8MQ settings.

Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1615029865-23312-9-git-send-email-peng.fan@oss.nxp.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

remoteproc: qcom: fix glink dependencies

Building the remoteproc drivers into the kernel while the qcom_glink
code is in a loadable module results in a link error:

ld.lld: error: undefined symbol:

remoteproc: qcom: fix glink dependencies

Building the remoteproc drivers into the kernel while the qcom_glink
code is in a loadable module results in a link error:

ld.lld: error: undefined symbol: qcom_glink_ssr_notify
>>> referenced by vmlinux.o:(glink_subdev_unprepare)

Add a Kconfig dependency to avoid this.

Reviewed-by: Alex Elder <elder@linaro.org>
Fixes: 8527efc59d45 ("rpmsg: glink: Guard qcom_glink_ssr_notify() with correct config")
Fixes: 5d1f2e3c8090 ("soc: qcom: glink_ssr: Internalize ssr_notifiers")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210204154010.1585457-1-arnd@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

remoteproc: qcom: add more help text qcom options

With these more help text added, hopefully it's easier to understand the
distinctions of these qcom remoteproc drivers.

Signed-off-by: Shawn Guo <s

remoteproc: qcom: add more help text qcom options

With these more help text added, hopefully it's easier to understand the
distinctions of these qcom remoteproc drivers.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20201217030400.6235-1-shawn.guo@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

remoteproc: pru: Add a PRU remoteproc driver

The Programmable Real-Time Unit Subsystem (PRUSS) consists of
dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
for program execution. This

remoteproc: pru: Add a PRU remoteproc driver

The Programmable Real-Time Unit Subsystem (PRUSS) consists of
dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
for program execution. This patch adds a remoteproc platform
driver for managing the individual PRU RISC cores life cycle.

The PRUs do not have a unified address space (have an Instruction
RAM and a primary Data RAM at both 0x0). The PRU remoteproc driver
therefore uses a custom remoteproc core ELF loader ops. The added
.da_to_va ops is only used to provide translations for the PRU
Data RAMs. This remoteproc driver does not have support for error
recovery and system suspend/resume features. Different compatibles
are used to allow providing scalability for instance-specific device
data if needed. The driver uses a default firmware-name retrieved
from device-tree for each PRU core, and the firmwares are expected
to be present in the standard Linux firmware search paths. They can
also be adjusted by userspace if required through the sysfs interface
provided by the remoteproc core.

The PRU remoteproc driver uses a client-driven boot methodology: it
does _not_ support auto-boot so that the PRU load and boot is dictated
by the corresponding client drivers for achieving various usecases.
This allows flexibility for the client drivers or applications to set
a firmware name (if needed) based on their desired functionality and
boot the PRU. The sysfs bind and unbind attributes have also been
suppressed so that the PRU devices cannot be unbound and thereby
shutdown a PRU from underneath a PRU client driver.

The driver currently supports the AM335x, AM437x, AM57xx and 66AK2G
SoCs, and support for other TI SoCs will be added in subsequent
patches.

Co-developed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201208141002.17777-3-grzegorz.jaszczyk@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...