linux-dev/drivers/remoteproc/Makefile, branch master

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

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

2021-09-27T23:37:13Z

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 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

remoteproc: pru: Add a PRU remoteproc driver

2020-12-10T16:55:55Z

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 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.org Signed-off-by: Bjorn Andersson

remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem

2020-10-13T23:34:38Z

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 Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20201002234234.20704-3-s-anna@ti.com Signed-off-by: Bjorn Andersson

remoteproc: Add remoteproc character device interface

2020-08-05T03:16:37Z

Add the character device interface into remoteproc framework. This interface can be used in order to boot/shutdown remote subsystems and provides a basic ioctl based interface to implement supplementary functionality. An ioctl call is implemented to enable the shutdown on release feature which will allow remote processors to be shutdown when the controlling userspace application crashes or hangs. Reviewed-by: Bjorn Andersson Reviewed-by: Mathieu Poirier Signed-off-by: Rishabh Bhatnagar Signed-off-by: Siddharth Gupta Link: https://lore.kernel.org/r/1596044401-22083-2-git-send-email-sidgup@codeaurora.org [bjorn: s/int32_t/s32/ per checkpatch] Signed-off-by: Bjorn Andersson

remoteproc: kill IPA notify code

2020-07-29T00:11:02Z

The IPA code now uses the generic remoteproc SSR notification mechanism. This makes the original IPA notification code unused and unnecessary, so get rid of it. This is effectively a revert of commit d7f5f3c89c1a ("remoteproc: add IPA notification to q6v5 driver"). Reviewed-by: Bjorn Andersson Signed-off-by: Alex Elder Link: https://lore.kernel.org/r/20200724181142.13581-3-elder@linaro.org Signed-off-by: Bjorn Andersson

remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs

2020-07-29T00:06:45Z

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 Reviewed-by: Bjorn Andersson Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200721223617.20312-6-s-anna@ti.com Signed-off-by: Bjorn Andersson

remoteproc: Move coredump functionality to a new file

2020-07-21T21:00:49Z

Move all coredump functionality to an individual file. This is being done so that the current functionality can be extended in future patchsets. Signed-off-by: Rishabh Bhatnagar Reviewed-by: Bjorn Andersson Reviewed-by: Mathieu Poirier Reviewed-by: Sibi Sankar Tested-by: Sibi Sankar Link: https://lore.kernel.org/r/1594938035-7327-2-git-send-email-rishabhb@codeaurora.org Signed-off-by: Bjorn Andersson

remoteproc: qcom: Introduce helper to store pil info in IMEM

2020-07-02T05:10:18Z

A region in IMEM is used to communicate load addresses of remoteproc to post mortem debug tools. Implement a helper function that can be used to store this information in order to enable these tools to process collected ramdumps. Reviewed-by: Mathieu Poirier Reviewed-by: Vinod Koul Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200622191942.255460-3-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson