linux/drivers/remoteproc/Kconfig

371 lines
11 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0-only
menu "Remoteproc drivers"
config REMOTEPROC
bool "Support for Remote Processor subsystem"
depends on HAS_DMA
select CRC32
select FW_LOADER
select VIRTIO
select WANT_DEV_COREDUMP
help
Support for remote processors (such as DSP coprocessors). These
are mainly used on embedded systems.
if REMOTEPROC
config REMOTEPROC_CDEV
bool "Remoteproc character device interface"
help
Say y here to have a character device interface for the remoteproc
framework. Userspace can boot/shutdown remote processors through
this interface.
It's safe to say N if you don't want to use this interface.
config IMX_REMOTEPROC
tristate "i.MX remoteproc support"
depends on ARCH_MXC
depends on HAVE_ARM_SMCCC
select MAILBOX
help
Say y here to support iMX's remote processors via the remote
processor framework.
It's safe to say N here.
config IMX_DSP_REMOTEPROC
tristate "i.MX DSP remoteproc support"
depends on ARCH_MXC
depends on HAVE_ARM_SMCCC
select MAILBOX
help
Say y here to support iMX's DSP remote processors via the remote
processor framework.
It's safe to say N here.
config INGENIC_VPU_RPROC
tristate "Ingenic JZ47xx VPU remoteproc support"
depends on MIPS || COMPILE_TEST
help
Say y or m here to support the VPU in the JZ47xx SoCs from Ingenic.
This can be either built-in or a loadable module.
If unsure say N.
config MTK_SCP
tristate "Mediatek SCP support"
depends on ARCH_MEDIATEK || COMPILE_TEST
select RPMSG_MTK_SCP
help
Say y here to support Mediatek's System Companion Processor (SCP) via
the remote processor framework.
It's safe to say N here.
config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
remoteproc/omap: Add support for DRA7xx remote processors DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems for offloading different computation algorithms. The IPU processor subsystem contains dual-core ARM Cortex-M4 processors, and is very similar to those on OMAP5. The DSP processor subsystem is based on the TI's standard TMS320C66x DSP CorePac core. Support has been added to the OMAP remoteproc driver through new DRA7xx specific compatibles for properly probing and booting all the different processor subsystem instances on DRA7xx/AM57xx SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX is added to enable the driver to be built in DRA7xx-only configuration. The DSP boot address programming needed enhancement for DRA7xx as the boot register fields are different on DRA7 compared to OMAP4 and OMAP5 SoCs. The register on DRA7xx contains additional fields within the register and the boot address bit-field is right-shifted by 10 bits. The internal memory parsing logic has also been updated to compute the device addresses for the L2 RAM for DSP devices using relative addressing logic, and to parse two additional RAMs at L1 level - L1P and L1D. This allows the remoteproc driver to support loading into these regions for a small subset of firmware images requiring as such. The most common usage would be to use the L1 programmable RAMs as L1 Caches. The firmware lookup logic also has to be adjusted for DRA7xx as there are (can be) more than one instance of both the IPU and DSP remote processors for the first time in OMAP4+ SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: moved address translation quirks to pdata] Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Andrew F. Davis <afd@ti.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324110035.29907-8-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-24 19:00:27 +08:00
depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
depends on OMAP_IOMMU
select MAILBOX
select OMAP2PLUS_MBOX
help
Say y here to support OMAP's remote processors (dual M3
and DSP on OMAP4) via the remote processor framework.
Currently only supported on OMAP4.
Usually you want to say Y here, in order to enable multimedia
use-cases to run on your platform (multimedia codecs are
offloaded to remote DSP processors using this framework).
It's safe to say N here if you're not interested in multimedia
offloading or just want a bare minimum kernel.
config OMAP_REMOTEPROC_WATCHDOG
bool "OMAP remoteproc watchdog timer"
depends on OMAP_REMOTEPROC
default n
help
Say Y here to enable watchdog timer for remote processors.
This option controls the watchdog functionality for the remote
processors in OMAP. Dedicated OMAP DMTimers are used by the remote
processors and triggers the timer interrupt upon a watchdog
detection.
config WKUP_M3_RPROC
tristate "AMx3xx Wakeup M3 remoteproc support"
depends on SOC_AM33XX || SOC_AM43XX
help
Say y here to support Wakeup M3 remote processor on TI AM33xx
and AM43xx family of SoCs.
Required for Suspend-to-RAM on AM33xx and AM43xx SoCs. Also needed
for deep CPUIdle states on AM33xx SoCs. Allows for loading of the
firmware onto these remote processors.
If unsure say N.
config DA8XX_REMOTEPROC
tristate "DA8xx/OMAP-L13x remoteproc support"
depends on ARCH_DAVINCI_DA8XX
depends on DMA_CMA
help
Say y here to support DA8xx/OMAP-L13x remote processors via the
remote processor framework.
You want to say y here in order to enable AMP
use-cases to run on your platform (multimedia codecs are
offloaded to remote DSP processors using this framework).
This module controls the name of the firmware file that gets
loaded on the DSP. This file must reside in the /lib/firmware
directory. It can be specified via the module parameter
da8xx_fw_name=<filename>, and if not specified will default to
"rproc-dsp-fw".
It's safe to say n here if you're not interested in multimedia
offloading.
config KEYSTONE_REMOTEPROC
tristate "Keystone Remoteproc support"
depends on ARCH_KEYSTONE
help
Say Y here here to support Keystone remote processors (DSP)
via the remote processor framework.
It's safe to say N here if you're not interested in the Keystone
DSPs or just want to use a bare minimum kernel.
config MESON_MX_AO_ARC_REMOTEPROC
tristate "Amlogic Meson6/8/8b/8m2 AO ARC remote processor support"
depends on HAS_IOMEM
depends on (ARM && ARCH_MESON) || COMPILE_TEST
select GENERIC_ALLOCATOR
help
Say m or y here to have support for the AO ARC remote processor
on Amlogic Meson6/Meson8/Meson8b/Meson8m2 SoCs. This is
typically used for system suspend.
If unsure say N.
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>
2020-12-08 22:09:58 +08:00
config PRU_REMOTEPROC
tristate "TI PRU remoteproc support"
depends on TI_PRUSS
default TI_PRUSS
help
Support for TI PRU remote processors present within a PRU-ICSS
subsystem via the remote processor framework.
Say Y or M here to support the Programmable Realtime Unit (PRU)
processors on various TI SoCs. It's safe to say N here if you're
not interested in the PRU or if you are unsure.
config QCOM_PIL_INFO
tristate
config QCOM_RPROC_COMMON
tristate
config QCOM_Q6V5_COMMON
tristate
depends on ARCH_QCOM
depends on QCOM_SMEM
config QCOM_Q6V5_ADSP
tristate "Qualcomm Technology Inc ADSP Peripheral Image Loader"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
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
2022-01-15 09:13:38 +08:00
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
select MFD_SYSCON
select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
help
Say y here to support the Peripheral Image Loader
for the non-TrustZone part of Qualcomm Technology Inc. ADSP and CDSP
remote processors. The TrustZone part is handled by QCOM_Q6V5_PAS
driver.
config QCOM_Q6V5_MSS
tristate "Qualcomm Hexagon V5 self-authenticating modem subsystem support"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
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
2022-01-15 09:13:38 +08:00
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
select MFD_SYSCON
select QCOM_MDT_LOADER
select QCOM_PIL_INFO
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
select QCOM_SCM
help
Say y here to support the Qualcomm self-authenticating modem
subsystem based on Hexagon V5. The TrustZone based system is
handled by QCOM_Q6V5_PAS driver.
config QCOM_Q6V5_PAS
tristate "Qualcomm Hexagon v5 Peripheral Authentication Service support"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
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
2022-01-15 09:13:38 +08:00
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
select MFD_SYSCON
select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
select QCOM_SCM
help
Say y here to support the TrustZone based Peripheral Image Loader
for the Qualcomm Hexagon v5 based remote processors. This is commonly
used to control subsystems such as ADSP (Audio DSP),
CDSP (Compute DSP), MPSS (Modem Peripheral SubSystem), and
SLPI (Sensor Low Power Island).
config QCOM_Q6V5_WCSS
tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
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
2022-01-15 09:13:38 +08:00
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
select MFD_SYSCON
select QCOM_MDT_LOADER
select QCOM_PIL_INFO
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
select QCOM_SCM
help
Say y here to support the Qualcomm Peripheral Image Loader for the
Hexagon V5 based WCSS remote processors on e.g. IPQ8074. This is
a non-TrustZone wireless subsystem.
config QCOM_SYSMON
tristate "Qualcomm sysmon driver"
depends on RPMSG
depends on ARCH_QCOM
depends on NET
select QCOM_QMI_HELPERS
help
The sysmon driver implements a sysmon QMI client and a handler for
the sys_mon SMD and GLINK channel, which are used for graceful
shutdown, retrieving failure information and propagating information
about other subsystems being shut down.
Say y here if your system runs firmware on any other subsystems, e.g.
modem or DSP.
config QCOM_WCNSS_PIL
tristate "Qualcomm WCNSS Peripheral Image Loader"
depends on OF && ARCH_QCOM
depends on RPMSG_QCOM_SMD || RPMSG_QCOM_SMD=n
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SMEM
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
select QCOM_MDT_LOADER
select QCOM_PIL_INFO
select QCOM_RPROC_COMMON
select QCOM_SCM
help
Say y here to support the Peripheral Image Loader for loading WCNSS
firmware and boot the core on e.g. MSM8974, MSM8916. The firmware is
verified and booted with the help of the Peripheral Authentication
System (PAS) in TrustZone.
config RCAR_REMOTEPROC
tristate "Renesas R-Car Gen3 remoteproc support"
depends on ARCH_RENESAS || COMPILE_TEST
help
Say y here to support R-Car realtime processor via the
remote processor framework. An ELF firmware can be loaded
thanks to sysfs remoteproc entries. The remote processor
can be started and stopped.
This can be either built-in or a loadable module.
If compiled as module (M), the module name is rcar_rproc.
config ST_REMOTEPROC
tristate "ST remoteproc support"
depends on ARCH_STI
select MAILBOX
select STI_MBOX
help
Say y here to support ST's adjunct processors via the remote
processor framework.
This can be either built-in or a loadable module.
config ST_SLIM_REMOTEPROC
tristate
config STM32_RPROC
tristate "STM32 remoteproc support"
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>
2023-06-09 18:45:42 +08:00
depends on ARCH_STM32 || COMPILE_TEST
depends on REMOTEPROC
select MAILBOX
help
Say y here to support STM32 MCU processors via the
remote processor framework.
You want to say y here in order to enable AMP
use-cases to run on your platform (dedicated firmware could be
offloaded to remote MCU processors using this framework).
This can be either built-in or a loadable module.
remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN voltage domain that are based on the TI's standard TMS320C66x DSP CorePac module. Each subsystem has a Fixed/Floating-Point DSP CPU, with 32 KB each of L1P & L1D SRAMs that can be configured and partitioned as either RAM and/or Cache, and 288 KB of L2 SRAM with 256 KB of memory configurable as either RAM and/or Cache. The CorePac also includes an Internal DMA (IDMA), External Memory Controller (EMC), Extended Memory Controller (XMC) with a Region Address Translator (RAT) unit for 32-bit to 48-bit address extension/translations, an Interrupt Controller (INTC) and a Powerdown Controller (PDC). A new remoteproc module is added to perform the device management of these DSP devices. The support is limited to images using only external DDR memory at the moment, the loading support to internal memories and any on-chip RAM memories will be added in a subsequent patch. RAT support is also left for a future patch, and as such the reserved memory carveout regions are all expected to be using memory regions within the first 2 GB. Error Recovery and Power Management features are not currently supported. The C66x remote processors do not have an MMU, and so require fixed memory carveout regions matching the firmware image addresses. Support for this is provided by mandating multiple memory regions to be attached to the remoteproc device. The first memory region will be used to serve as the DMA pool for all dynamic allocations like the vrings and vring buffers. The remaining memory regions are mapped into the kernel at device probe time, and are used to provide address translations for firmware image segments without the need for any RSC_CARVEOUT entries. Any firmware image using memory outside of the supplied reserved memory carveout regions will be errored out. The driver uses various TI-SCI interfaces to talk to the System Controller (DMSC) for managing configuration, power and reset management of these cores. IPC between the A72 cores and the DSP cores is supported through the virtio rpmsg stack using shared memory and OMAP Mailboxes. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200721223617.20312-6-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-22 06:36:16 +08:00
config TI_K3_DSP_REMOTEPROC
tristate "TI K3 DSP remoteproc support"
depends on ARCH_K3
select MAILBOX
select OMAP2PLUS_MBOX
help
Say m here to support TI's C66x and C71x DSP remote processor
subsystems on various TI K3 family of SoCs through the remote
processor framework.
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem The TI K3 family of SoCs typically have one or more dual-core Arm Cortex R5F processor clusters/subsystems (R5FSS). This R5F subsystem/cluster can be configured at boot time to be either run in a LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. This subsystem has 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - TCMA and TCMB (further interleaved into two banks). The subsystem does not have an MMU, but has a Region Address Translater (RAT) module that is accessible only from the R5Fs for providing translations between 32-bit CPU addresses into larger system bus addresses. Add a remoteproc driver to support this subsystem to be able to load and boot the R5F cores primarily in LockStep mode. The code also includes the base support for Split mode. Error Recovery and Power Management features are not currently supported. Loading support includes the internal TCMs and DDR. RAT support is left for a future patch, and as such the reserved memory carveout regions are all expected to be using memory regions within the first 2 GB. The R5F remote processors do not have an MMU, and so require fixed memory carveout regions matching the firmware image addresses. Support for this is provided by mandating multiple memory regions to be attached to the remoteproc device. The first memory region will be used to serve as the DMA pool for all dynamic allocations like the vrings and vring buffers. The remaining memory regions are mapped into the kernel at device probe time, and are used to provide address translations for firmware image segments without the need for any RSC_CARVEOUT entries. Any firmware image using memory outside of the supplied reserved memory carveout regions will be errored out. The R5F processors on TI K3 SoCs require a specific sequence for booting and shutting down the processors. This sequence is also dependent on the mode (LockStep or Split) the R5F cluster is configured for. The R5F cores have a Memory Protection Unit (MPU) that has a default configuration that does not allow the cores to run out of DDR out of reset. This is resolved by using the TCMs for boot-strapping code that applies the appropriate executable permissions on desired DDR memory. The loading into the TCMs requires that the resets be released first with the cores in halted state. The Power Sleep Controller (PSC) module on K3 SoCs requires that the cores be in WFI/WFE states with no active bus transactions before the cores can be put back into reset. Support for this is provided by using the newly introduced .prepare() and .unprepare() ops in the remoteproc core. The .prepare() ops is invoked before any loading, and the .unprepare() ops is invoked after the remoteproc resource cleanup. The R5F core resets are deasserted in .prepare() and asserted in .unprepare(), and the cores themselves are started and halted in .start() and .stop() ops. This ensures symmetric usage and allows the R5F cores state machine to be maintained properly between using the sysfs 'state' variable, bind/unbind and regular module load/unload flows. The subsystem is represented as a single remoteproc in LockStep mode, and as two remoteprocs in Split mode. The driver uses various TI-SCI interfaces to talk to the System Controller (DMSC) for managing configuration, power and reset management of these cores. IPC between the A53 cores and the R5 cores is supported through the virtio rpmsg stack using shared memory and OMAP Mailboxes. The AM65x SoCs typically have a single R5FSS in the MCU voltage domain. The J721E SoCs uses a slightly revised IP and typically have three R5FSSs, with one cluster present within the MCU voltage domain (MCU_R5FSS0), and the remaining two clusters present in the MAIN voltage domain (MAIN_R5FSS0 and MAIN_R5FSS1). The integration of these clusters on J721E SoC is also slightly different in that these IPs do support an actual local reset line, while they are a no-op on AM65x SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201002234234.20704-3-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-10-03 07:42:32 +08:00
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
select MAILBOX
select OMAP2PLUS_MBOX
help
Say m here to support TI's R5F remote processor subsystems
on various TI K3 family of SoCs through the remote processor
framework.
It's safe to say N here if you're not interested in utilizing
a slave processor.
config XLNX_R5_REMOTEPROC
tristate "Xilinx R5 remoteproc support"
depends on PM && ARCH_ZYNQMP
select ZYNQMP_FIRMWARE
select RPMSG_VIRTIO
select MAILBOX
select ZYNQMP_IPI_MBOX
help
Say y or m here to support Xilinx R5 remote processors via the remote
processor framework.
It's safe to say N if not interested in using RPU r5f cores.
endif # REMOTEPROC
endmenu