Changes in Kconfig

be3e6529 - remoteproc: k3-r5: Add compile testing support

Wed, 16 Oct 2024 16:41:41 +0000

remoteproc: k3-r5: Add compile testing supportThis driver can be compile tested on non-K3 architectures as longas TI_SCI_PROTOCOL is not compiled as a module. Enable this hereto improve this driver's build coverage.Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20241016164141.93401-3-afd@ti.comSigned-off-by: Mathieu Poirier List of files: /linux-6.15/drivers/remoteproc/Kconfig

0db357ef - remoteproc: k3-dsp: Add compile testing support

Wed, 16 Oct 2024 16:41:40 +0000

remoteproc: k3-dsp: Add compile testing supportThis driver can be compile tested on non-K3 architectures as longas TI_SCI_PROTOCOL is not compiled as a module. Enable this hereto improve this driver's build coverage.Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20241016164141.93401-2-afd@ti.comSigned-off-by: Mathieu Poirier List of files: /linux-6.15/drivers/remoteproc/Kconfig

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

Mon, 07 Oct 2024 13:23:57 +0000

mailbox, remoteproc: k3-m4+: fix compile testingThe k3-m4 remoteproc driver was merged with incorrect dependencies.Despite multiple people trying to fix this, the version 6.12-rc2remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=mwhen 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 driversdependencies. The link failure can be avoided with a simple 'dependsdo, so turn that into the same 'depends' to ensure we get no circularon TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is whatwe use elsehwere. On the other hand, building for OMAP2PLUS makesno 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.orgSigned-off-by: Mathieu Poirier List of files: /linux-6.15/drivers/remoteproc/Kconfig

54595f28 - mailbox, remoteproc: omap2+: fix compile testing

Mon, 09 Sep 2024 20:38:09 +0000

mailbox, remoteproc: omap2+: fix compile testingSelecting CONFIG_OMAP2PLUS_MBOX while compile testingcauses 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 generallya mistake and causes problems such as this one, so change thethree drivers that link against this driver to use 'depends on'instead, and ensure the driver itself can be compile testedregardless of the platform.When compile-testing without CONFIG_TI_SCI_PROTOCOL=m, thereis a chance for a link failure, so add a careful dependencyon 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 List of files: /linux-6.15/drivers/remoteproc/Kconfig

ba0c0cb5 - remoteproc: k3-m4: use the proper dependencies

Tue, 24 Sep 2024 19:48:35 +0000

remoteproc: k3-m4: use the proper dependenciesThe TI_K3_M4_REMOTEPROC Kconfig entry selects OMAP2PLUS_MBOX, but thatdriver 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 theOMAP2PLUS_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 List of files: /linux-6.15/drivers/remoteproc/Kconfig

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

Fri, 02 Aug 2024 15:21:03 +0000

remoteproc: k3-m4: Add a remoteproc driver for M4F subsystemThe AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core inthe MCU domain. This core is typically used for safety applications in astand alone mode. However, some application (non safety related) maywant to use the M4F core as a generic remote processor with IPC to thehost processor. The M4F core has internal IRAM and DRAM memories and areexposed to the system bus for code and data loading.A remote processor driver is added to support this subsystem, includingbeing able to load and boot the M4F core. Loading includes to M4Finternal memories and predefined external code/data memories. Thecarve outs for external contiguous memory is defined in the M4F devicenode and should match with the external memory declarations in the M4Fimage binary. The M4F subsystem has two resets. One reset is for theentire subsystem i.e including the internal memories and the other, alocal reset is only for the M4F processing core. When loading the image,the driver first releases the subsystem reset, loads the firmware imageand 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.comSigned-off-by: Mathieu Poirier List of files: /linux-6.15/drivers/remoteproc/Kconfig

e9b85438 - remoteproc: qcom: select AUXILIARY_BUS

Wed, 26 Jun 2024 19:12:38 +0000

remoteproc: qcom: select AUXILIARY_BUSThe QCOM_PD_MAPPER implementation made Qualcomm remoteproc drivers useauxiliary 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.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

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

Fri, 09 Jun 2023 10:45:42 +0000

remoteproc: stm32: use correct format strings on 64-bitWith CONFIG_ARCH_STM32 making it into arch/arm64, a couple of formatstrings no longer work, since they rely on size_t being compatiblewith %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 | %lxdrivers/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 | %lxdrivers/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 | %xFix up all three instances to work across architectures, and enablecompile testing for this driver to ensure it builds everywhere.Reviewed-by: Arnaud Pouliquen Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Arnd Bergmann List of files: /linux-6.15/drivers/remoteproc/Kconfig

6b291e80 - drivers: remoteproc: Add Xilinx r5 remoteproc driver

Mon, 14 Nov 2022 23:39:40 +0000

drivers: remoteproc: Add Xilinx r5 remoteproc driverThis driver enables r5f dual core Real time Processing Unit subsystemavailable on Xilinx Zynq Ultrascale MPSoC Platform. RPU subsystem(cluster) can be configured in different modes e.g. split mode in whichtwo r5f cores work independent of each other and lock-step mode in whichboth r5f cores execute same code clock-for-clock and notify if theresult is different.The Xilinx r5 Remoteproc Driver boots the RPU cores via calls to the XilinxPlatform Management Unit that handles the R5 configuration, memory accessand R5 lifecycle management. The interface to this manager is done in thisdriver via zynqmp_pm_* function calls.Signed-off-by: Ben Levinsky Signed-off-by: Tanmay Shah Reported-by: kernel test robot Link: https://lore.kernel.org/r/20221114233940.2096237-7-tanmay.shah@amd.comSigned-off-by: Mathieu Poirier List of files: /linux-6.15/drivers/remoteproc/Kconfig

eee412e9 - remoteproc: qcom: q6v5: fix service routines build errors

Sat, 15 Jan 2022 01:13:38 +0000

remoteproc: qcom: q6v5: fix service routines build errorsWhen CONFIG_QCOM_AOSS_QMP=m and CONFIG_QCOM_Q6V5_MSS=y, the builtindriver cannot call into the loadable module's low-level servicefunctions. Trying to build with that config combo causes linker errors.There are two problems here. First, drivers/remoteproc/qcom_q6v5.cshould #include for the definitions ofthe service functions, depending on whether CONFIG_QCOM_AOSS_QMP isset/enabled or not. Second, the qcom remoteproc drivers should dependon QCOM_AOSS_QMP iff it is enabled (=y or =m) so that the qcomremoteproc 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 Reported-by: kernel test robot Cc: Bjorn Andersson Cc: Mathieu Poirier Cc: linux-remoteproc@vger.kernel.orgCc: Sibi Sankar Cc: Stephen Boyd Reviewed-by: Stephen Boyd Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220115011338.2973-1-rdunlap@infradead.org List of files: /linux-6.15/drivers/remoteproc/Kconfig

285892a7 - remoteproc: Add Renesas rcar driver

Tue, 07 Dec 2021 16:58:29 +0000

remoteproc: Add Renesas rcar driverRenesas 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 resetThis initial driver allows to start and stop the Cortex R7processor.Signed-off-by: Julien Massot Link: https://lore.kernel.org/r/20211207165829.195537-3-julien.massot@iot.bzhSigned-off-by: Mathieu Poirier List of files: /linux-6.15/drivers/remoteproc/Kconfig

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

Mon, 11 Oct 2021 09:20:14 +0000

remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MXProvide 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, thereare 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 Link: https://lore.kernel.org/r/1633944015-789-4-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mathieu Poirier List of files: /linux-6.15/drivers/remoteproc/Kconfig

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

Tue, 21 Sep 2021 19:25:57 +0000

remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesorAmlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in theAlways-On (AO) power-domain. This is typically used for waking up theARM 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 triggera reset.The actual code for this ARC core can come from an ELF binary, forexample 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) andrproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20210921192557.1610709-3-martin.blumenstingl@googlemail.com[Fixed header file order]Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

fc1b6b64 - remoteproc: qcom: Loosen dependency on RPMSG_QCOM_SMD

Mon, 23 Aug 2021 23:51:20 +0000

remoteproc: qcom: Loosen dependency on RPMSG_QCOM_SMDThere doesn't seem to be any actual build time dependency on theRPMSG_QCOM_SMD, besides that these drivers should be a module if the smdrpmsg code is a module. Drop the compile test dependency so that thesedrivers can be used without RPMSG_QCOM_SMD being enabled. This is usefulfor the qcom SoCs that are using RPMSG_QCOM_GLINK_SMEM instead ofRPMSG_QCOM_SMD and thus don't want to enable the SMD driver when it isnever used.Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210823235120.1203512-2-swboyd@chromium.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

1cd62394 - remoteproc: imx-rproc: Fix IMX_REMOTEPROC configuration

Thu, 10 Jun 2021 03:15:30 +0000

remoteproc: imx-rproc: Fix IMX_REMOTEPROC configurationWhen CONFIG_IMX_REMOTEPROC is y and CONFIG_HAVE_ARM_SMCCCis 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, soadd dependency on HAVE_ARM_SMCCC in IMX_REMOTEPROC configuration.Fixes: 79806d32d5aa ("remoteproc: imx_rproc: support i.MX8MN/P")Reviewed-by: Mathieu Poirier Reported-by: kernel test robot Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20210610031530.26326-1-peng.fan@oss.nxp.comSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

889cb0d4 - remoteproc: imx_rproc: fix build error without CONFIG_MAILBOX

Wed, 31 Mar 2021 12:27:09 +0000

remoteproc: imx_rproc: fix build error without CONFIG_MAILBOXFix 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 1Reviewed-by: Mathieu Poirier Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox")Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210331122709.3935521-1-weiyongjun1@huawei.comSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

4ab8f960 - remoteproc: imx_rproc: support i.MX8MQ/M

Sat, 06 Mar 2021 11:24:23 +0000

remoteproc: imx_rproc: support i.MX8MQ/MAdd i.MX8MQ dev/sys addr map and configuration data structurei.MX8MM share i.MX8MQ settings.Reviewed-by: Richard Zhu Reviewed-by: Mathieu Poirier Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/1615029865-23312-9-git-send-email-peng.fan@oss.nxp.comSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

bfb44502 - remoteproc: qcom: fix glink dependencies

Thu, 04 Feb 2021 15:40:04 +0000

remoteproc: qcom: fix glink dependenciesBuilding the remoteproc drivers into the kernel while the qcom_glinkcode 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 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 Link: https://lore.kernel.org/r/20210204154010.1585457-1-arnd@kernel.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

9e19f44d - remoteproc: qcom: add more help text qcom options

Thu, 17 Dec 2020 03:04:00 +0000

remoteproc: qcom: add more help text qcom optionsWith these more help text added, hopefully it's easier to understand thedistinctions of these qcom remoteproc drivers.Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20201217030400.6235-1-shawn.guo@linaro.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig

d4ce2de7 - remoteproc: pru: Add a PRU remoteproc driver

Tue, 08 Dec 2020 14:09:58 +0000

remoteproc: pru: Add a PRU remoteproc driverThe Programmable Real-Time Unit Subsystem (PRUSS) consists ofdual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)for program execution. This patch adds a remoteproc platformdriver for managing the individual PRU RISC cores life cycle.The PRUs do not have a unified address space (have an InstructionRAM and a primary Data RAM at both 0x0). The PRU remoteproc drivertherefore uses a custom remoteproc core ELF loader ops. The added.da_to_va ops is only used to provide translations for the PRUData RAMs. This remoteproc driver does not have support for errorrecovery and system suspend/resume features. Different compatiblesare used to allow providing scalability for instance-specific devicedata if needed. The driver uses a default firmware-name retrievedfrom device-tree for each PRU core, and the firmwares are expectedto be present in the standard Linux firmware search paths. They canalso be adjusted by userspace if required through the sysfs interfaceprovided by the remoteproc core.The PRU remoteproc driver uses a client-driven boot methodology: itdoes _not_ support auto-boot so that the PRU load and boot is dictatedby the corresponding client drivers for achieving various usecases.This allows flexibility for the client drivers or applications to seta firmware name (if needed) based on their desired functionality andboot the PRU. The sysfs bind and unbind attributes have also beensuppressed so that the PRU devices cannot be unbound and therebyshutdown a PRU from underneath a PRU client driver.The driver currently supports the AM335x, AM437x, AM57xx and 66AK2GSoCs, and support for other TI SoCs will be added in subsequentpatches.Co-developed-by: Andrew F. Davis Signed-off-by: Andrew F. Davis Signed-off-by: Suman Anna Co-developed-by: Grzegorz Jaszczyk Signed-off-by: Grzegorz Jaszczyk Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201208141002.17777-3-grzegorz.jaszczyk@linaro.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/drivers/remoteproc/Kconfig