blaster4385/linux-IllusionX/drivers/remoteproc/Kconfig, branch v6.12.1

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

2024-09-29T16:53:04Z

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:05Z

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:35Z

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:54Z

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:17Z

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

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

2023-06-22T07:54:44Z

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 Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Arnd Bergmann

drivers: remoteproc: Add Xilinx r5 remoteproc driver

2022-11-25T16:12:05Z

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 Signed-off-by: Tanmay Shah Reported-by: kernel test robot Link: https://lore.kernel.org/r/20221114233940.2096237-7-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier

remoteproc: qcom: q6v5: fix service routines build errors

2022-01-17T22:44:26Z

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 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 Reported-by: kernel test robot Cc: Bjorn Andersson Cc: Mathieu Poirier Cc: linux-remoteproc@vger.kernel.org Cc: 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

remoteproc: Add Renesas rcar driver

2021-12-13T18:30:55Z

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 Link: https://lore.kernel.org/r/20211207165829.195537-3-julien.massot@iot.bzh Signed-off-by: Mathieu Poirier

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

2021-10-12T15:16:58Z

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 Link: https://lore.kernel.org/r/1633944015-789-4-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier