summaryrefslogtreecommitdiff
path: root/drivers/remoteproc
AgeCommit message (Collapse)AuthorFilesLines
2024-07-22drivers: remoteproc: Remove duplicate newlinesMarek Vasut2-2/+0
Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-06-07Merge patch series "Adding support to load secure firmware for HS devices"Tom Rini2-0/+8
Udit Kumar <u-kumar1@ti.com> says: Some use case needs rproc firmware to be loaded at u-boot stage, using following commands at u-boot shell, firmware could be loaded => setenv dorprocboot 1 => run boot_rprocs For Secure devices, secure version of rproc firmware should be loaded, which is appended by sec keyword[0]. but currently non-secure firmware is loaded even for secure devices. So adding support for loading secure firmware on Secured devices. [0]: https://gist.github.com/uditkumarti/cd8bf6a448079b59145d17a0e8bf13b7 Bootlogs: GP : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-gp_device line 65 onwards HS : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-hs-device line 60 onwards
2024-06-07drivers: remoteproc: ti_k3 : enable secure booting with firmware imagesManorit Chawdhry2-0/+8
Remoteproc firmware images aren't authenticated in the current boot flow. Authenticates remoteproc firmware images to complete the root of trust in secure booting. Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"Tom Rini11-13/+7
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-20Merge tag 'v2024.07-rc3' into nextTom Rini11-7/+13
Prepare v2024.07-rc3
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini11-7/+13
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-15Merge patch series "Add remoteproc driver for AM62a SoC"Tom Rini2-4/+38
Hari Nagalla <hnagalla@ti.com> says: This series adds relevant ip data in remoteproc driver for AM62a devices. Logs: https://paste.sr.ht/~hnagalla/5e20838705c1d688bca81886dad56451b56d3913
2024-05-15remoteproc: k3-r5: Add support for R5F core on AM62A SoCsHari Nagalla1-2/+27
AM62A has a R5F core in MCU voltage domain. Extend support for R5F remote proc driver on AM62A with compatible strings. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
2024-05-15remoteproc: k3-dsp: Enable C71x support for AM62AHari Nagalla1-2/+11
AM62A SoC has a single C71x DSP subsystem with analytics engine in main voltage domain. Extend support to AM62A with compatible strings. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
2024-05-10Merge patch series "Add AM64x Support to PRUSS and PRU_RPROC driver"Tom Rini1-2/+7
MD Danish Anwar <danishanwar@ti.com> says: This series adds AM64x related compatibles to PRUSS and PRU_RPROC drivers. This series is a prerequisite for ICSSG Ethernet driver. Once Support for AM64x is added to PRUSS and PRU_RPROC driver, I'll send another series to enable ICSSG Ethernet driver for AM64x as well.
2024-05-10remoteproc: pru: Add support for AM64x PRU / RTU coresMD Danish Anwar1-2/+7
Add support for AM64x PRU cores by adding compatibles for AM64x. Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org>
2024-05-07remoteproc: Remove <common.h> and add needed includesTom Rini11-11/+0
Remove <common.h> from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-03-22remoteproc: uclass: Add methods to load firmware to rproc and boot rprocMD Danish Anwar2-0/+111
Add APIs to set a firmware_name to a rproc and boot the rproc with the same firmware. Clients can call rproc_set_firmware() API to set firmware_name for a rproc whereas rproc_boot() will load the firmware set by rproc_set_firmware() to a buffer by calling request_firmware_into_buf(). rproc_boot() will then load the firmware file to the remote processor and start the remote processor. Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Acked-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org>
2024-03-22remoteproc: k3-dsp: Extend support for C71x DSPs on J721S2 SoCsHari Nagalla1-1/+3
The K3 J721S2 SoCs have two C71x DSP subsystems in MAIN voltage domain, and there are no C66x DSP subsystems on these SoCs. The C71x DSP subsystem is a slighly updated version of the C71x DSP subsystem on J721e. The C71x DSPs are 64 bit machine with fixed and floating point DSP operations. Extend support to the C71x DSPs with J721S2 compatible strings. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Apurva Nandan <a-nandan@ti.com>
2024-03-22remoteproc: k3-r5: Extend support for R5F clusters on J721S2 SoCsHari Nagalla1-2/+4
The K3 J721S2 SoCs have three dual-core R5F subsystems, one in MCU voltage domain and the other two in MAIN voltage domain. These R5F clusters are similar to the R5F clusters in J7200 SoCs. Compatible Info is updated to support J721S2 SoCs. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Apurva Nandan <a-nandan@ti.com>
2023-12-19remoteproc: k3-dsp: Avoid reloading of firmwareUdit Kumar1-0/+11
DSP core is going into abnormal state when load callback is called after starting of DSP core. Reload of firmware needs core to be stopped first, followed by load. So avoid loading of firmware, when core is started. Signed-off-by: Udit Kumar <u-kumar1@ti.com>
2023-11-10tree-wide: Replace http:// link with https:// link for ti.comNishanth Menon11-11/+11
Replace instances of http://www.ti.com with https://www.ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-09-24common: Drop linux/printk.h from common headerSimon Glass6-0/+6
This old patch was marked as deferred. Bring it back to life, to continue towards the removal of common.h Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-08-08remoteproc: uclass: Clean up a returnDan Carpenter1-1/+1
We know that "pa" is non-NULL so it's nicer to just return zero instead of return !pa. This has no effect on runtime behavior. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-24remoteproc: ti_k3_arm64: Change the startup of arm64 coreManorit Chawdhry1-20/+42
Configuring master firewalls require the power of the cluster to be enabled before configuring them, change the load of rproc to configure the gtc clocks and start the cluster along with configuring the boot vector. The start of rproc will only start the core. Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
2022-02-08remoteproc: ipu: Add driver to bring up ipuKeerthy3-0/+770
The driver enables IPU support. Basically enables the clocks, timers, watchdog timers and bare minimal MMU and supports loading the firmware from mmc. Signed-off-by: Keerthy <j-keerthy@ti.com> [Amjad: fix compile warnings] Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
2022-02-08remoteproc: uclass: Add remoteproc resource handling helpersKeerthy1-0/+534
Add remoteproc resource handling helpers. These functions are primarily to parse the resource table and to handle different types of resources. Carveout, devmem, trace & vring resources are handled. Signed-off-by: Keerthy <j-keerthy@ti.com> [Amjad: fix redefinition of "struct resource_table" and compile warnings ] Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
2022-02-08remoteproc: k3_system_controller: Support optional boot_notification channelNishanth Menon1-1/+19
If there is an optional boot notification channel that an SoC uses separate from the rx path, use the same. Signed-off-by: Nishanth Menon <nm@ti.com>
2022-01-19doc: replace @return by Return:Heinrich Schuchardt2-8/+8
Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-10-05remoteproc: migrate uclass to livetreePatrick Delaunay1-14/+2
Use dev_ function to read the name and boolean to support a live tree. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-07-15remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCsKeerthy3-0/+473
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem, commonly referred to as ICSSG. Each ICSSG processor subsystem on AM65x SR1.0 contains two primary PRU cores and two new auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. This IP instance has two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than a PRU), Control and debug feature sets, but is different in terms of sub-modules integrated around it and does not have the full capabilities associated with a PRU core. The RTU core is typically used to aid a PRU core in accelerating data transfers, while the Tx_PRU cores is normally used to control the TX L2 FIFO if enabled in Ethernet applications. Both can also be used to run independent applications. The RTU and Tx_PRU cores though share the same Data RAMs as the PRU cores, so the memories have to be partitioned carefully between different applications. The new cores also support a new sub-module called Task Manager to support two different context thread executions. The driver currently supports the AM65xx SoC Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210622063431.3151-3-lokeshvutla@ti.com
2021-07-06dm: define LOG_CATEGORY for all uclassPatrick Delaunay1-0/+3
Define LOG_CATEGORY for all uclass to allow filtering with log command. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-06-11remoteproc: k3-r5: remove sysfw PM calls if not supportedTero Kristo1-11/+19
With the sysfw rearch, sysfw PM calls are no longer available from SPL level. To properly support this, remove the is_on checks and the reset assertion from the R5 remoteproc driver as these are not supported. Attempting to access unavailable services will cause the device to hang. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-02-15Merge branch '2021-02-02-drop-asm_global_data-when-unused'Tom Rini2-0/+2
- Merge the patch to take <asm/global_data.h> out of <common.h>
2021-02-04remoteproc: k3_r5: Sync to upstreamed kernel DT property namesSuman Anna1-4/+4
The K3 R5F remoteproc driver in U-Boot was upstreamed prior to the equivalent remoteproc driver in the Linux kernel. Some of the DT properties used in U-Boot got upstreamed using different names in Linux kernel. The modified property names include the R5F cluster mode configuration property "lockstep-mode"; and three different individual R5F core config properties - "atcm-enable", "btcm-enable" and "loczrama". The property names were updated as follows: lockstep-mode => ti,cluster-mode atcm-enable => ti,atcm-enable btcm-enable => ti,btcm-enable loczrama => ti,loczrama Update the K3 R5F remoteproc driver, the corresponding binding, and all the existing usage in AM65x, J721E and J7200 dts files all at once to use the new properties and to not break any bisectability. Signed-off-by: Suman Anna <s-anna@ti.com>
2021-02-02common: Drop asm/global_data.h from common headerSimon Glass2-0/+2
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-01-13remoproc: stm32: migrate trace to log macroPatrick Delaunay1-1/+2
Define LOG_CATEGORY and remove unneeded pr_fmt macro with the dev macro as dev->name is displayed and CONFIG_LOGF_FUNC can be activated for log macro. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2021-01-12remoteproc: ti_k3_arm64: Program CNTFID0 register in GTCNishanth Menon1-0/+15
ARMv8's generic timer[1] picks up it's graycode from GTC. However, the frequency of the GTC is supposed to be programmed in CNTFID0[2] register prior to enabling the GTC in CNTCR[3] register. In K3 architecture, GTC provides a central time to many parts of the SoC including graycode to the generic timer in the ARMv8 subsystem. However, due to the central nature and the need to enable the counter early in the boot process, the R5 based u-boot enables GTC and programs it's frequency based on central needs of the system. This may not be a constant 200MHz based on the system. The bootloader is supposed to program the FID0 register with the correct frequency it has sourced for GTC from the central system controller OR from PLLs as appropriate, and TF-A is supposed[4] to use that as the frequency for it's local timer. Currently we are programming just the CNTCR[3] register to enable the GTC, however we dont let TF-A know the frequency that GTC is actually running at. A mismatch in programmed frequency and what we program for generic timer will, as we can imagine, all kind of weird mayhem. So, program the CNTFID0 register with the clock frequency. Note: assigned-clock-rates should have set the clock frequency, so the only operation we need to explicitly do is to retrieve the frequency and program it in FID0 register. Since the valid in K3 for GTC clock frequencies are < U32_MAX, we can just cast the ulong and continue. [1] https://developer.arm.com/documentation/100095/0002/generic-timer/generic-timer-register-summary/aarch64-generic-timer-register-summary [2] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntfid0 [3] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntcr [4] https://github.com/ARM-software/arm-trusted-firmware/commit/6a22d9ea3c7fa28d053d3ba264b49b7396a86f9e Signed-off-by: Nishanth Menon <nm@ti.com>
2021-01-05dm: Rename U_BOOT_DEVICE() to U_BOOT_DRVINFO()Simon Glass1-1/+1
The current macro is a misnomer since it does not declare a device directly. Instead, it declares driver_info record which U-Boot uses at runtime to create a device. The distinction seems somewhat minor most of the time, but is becomes quite confusing when we actually want to declare a device, with of-platdata. We are left trying to distinguish between a device which isn't actually device, and a device that is (perhaps an 'instance'?) It seems better to rename this macro to describe what it actually is. The macros is not widely used, since boards should use devicetree to declare devices. Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is declaring a new driver_info record, not a device. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05dm: core: Access device flags through functionsSimon Glass1-1/+1
At present flags are stored as part of the device. In preparation for storing them separately, change the access to go through inline functions. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05dm: Use access methods for dev/uclass private dataSimon Glass1-2/+2
Most drivers use these access methods but a few do not. Update them. In some cases the access is not permitted, so mark those with a FIXME tag for the maintainer to check. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Pratyush Yadav <p.yadav@ti.com>
2020-12-13dm: treewide: Update 'auto' declarations to be on one lineSimon Glass1-2/+1
Fix up the code style for those declarations that should now fit onto one line, which is all of them that currently do not. This is needed for dtoc to detect the structs correctly, at present. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-13dm: treewide: Rename 'platdata' variables to just 'plat'Simon Glass3-19/+19
We use 'priv' for private data but often use 'platdata' for platform data. We can't really use 'pdata' since that is ambiguous (it could mean private or platform data). Rename some of the latter variables to end with 'plat' for consistency. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-13dm: treewide: Rename auto_alloc_size members to be shorterSimon Glass8-9/+9
This construct is quite long-winded. In earlier days it made some sense since auto-allocation was a strange concept. But with driver model now used pretty universally, we can shorten this to 'auto'. This reduces verbosity and makes it easier to read. Coincidentally it also ensures that every declaration is on one line, thus making dtoc's job easier. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-11-25remoteproc: stm32: update error management in stm32_copro_startPatrick Delaunay1-7/+6
The coprocessor is running as soon as the hold boot is de-asserted. So indicate this running state and save the resource table even if the protective assert, to avoid autonomous reboot, is failed. This error case should never occurs. Cc: Fabien DESSENNE <fabien.dessenne@st.com> Cc: Arnaud POULIQUEN <arnaud.pouliquen@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-11-25remoteproc: stm32: use reset for hold bootPatrick Delaunay1-68/+25
Use the reset function to handle the hold boot bit in RCC with device tree handle with MCU_HOLD_BOOT identifier. This generic reset allows to remove the two specific properties: - st,syscfg-holdboot - st,syscfg-tz This patch prepares alignment with kernel device tree. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Cc: Fabien DESSENNE <fabien.dessenne@st.com> Cc: Arnaud POULIQUEN <arnaud.pouliquen@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-09-30remoteproc: k3: Fix not calling dev_xxx with a deviceSean Anderson1-4/+5
Pass a device to functions which log with one. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-09-30remoteproc: k3-r5: Fix not calling dev_xxx with a deviceSean Anderson1-10/+14
Usually we can get a device from the current core, but some dev_dbg calls have been converted to debug, since we are called on a cluster. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-09-30remoteproc: Remove unused function rproc_elf_sanity_checkSean Anderson1-16/+0
This function is never used anywhere, and it also tries to log with a nonexistant device. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-09-15remoteproc: k3-r5: Add support for J7200 R5FsSuman Anna1-10/+89
The K3 J7200 SoC family has a revised R5F sub-system and contains a subset of the R5F clusters present on J721E SoCs. The integration of these clusters is very much similar to J721E SoCs otherwise. The revised IP has the following two new features: 1. TCMs are auto-initialized during module power-up, and the behavior is programmable through a MMR bit controlled by System Firmware. 2. The LockStep-mode allows the Core1 TCMs to be combined with the Core0 TCMs effectively doubling the amount of TCMs available. The LockStep-mode on previous SoCs could only use the Core0 TCMs. This combined TCMs appear contiguous at the respective Core0 TCM addresses. Add the support to these clusters in the K3 R5F remoteproc driver using J7200 specific compatibles and revised logic accounting for the above IP features/differences. Signed-off-by: Suman Anna <s-anna@ti.com>
2020-05-18common: Drop log.h from common headerSimon Glass8-0/+8
Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop net.h from common headerSimon Glass1-0/+1
Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-03-16remoteproc: k3-r5: Fix rproc init failure on Split-mode _only_ devicesSuman Anna1-3/+5
The R5F subsystem/cluster on K3 SoCs can support both LockStep and Split-modes (superset) or just Split-mode depending on an eFUSE capability register. The LockStep configuration bit is Read-only though on Split-mode _only_ devices and as such the System Firmware does not allow the LockStep mode bit to be configured on such devices. The current logic in k3_r5f_rproc_configure() fails on Split-mode devices because of this unconditional programming of the LockStep mode bit, and results in the probe failure shown during the "rproc init" step at U-Boot prompt. Fix this by limiting the LockStep mode bit clear configuration only on devices supporting both LockStep/Split-modes. Fixes: 4c850356a83f ("remoteproc: Introduce K3 remoteproc driver for R5F subsystem") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-03-16remoteproc: k3-r5: Fix rproc init failure for Main R5FSS0Suman Anna1-0/+1
The Main R5FSS0 cluster is also enabled to probe the R5F remoteproc driver within R5 SPL for booting the Core0 very early. This results in a ti_sci_power_domain_on failure during the probe from the A72 U-Boot when "rproc init" is executed at U-Boot prompt, and doesn't enumerate all the rproc devices. Fix this by suppressing the power_domain_on altogether using the flag DM_FLAG_DEFAULT_PD_CTRL_OFF added in commit af94ad418dc7 ("dm: core: Allow for not controlling the power-domain by DM framework"). Fixes: fac6aa817a09 ("configs: j721e_evm_r5: Enable R5F remoteproc support") Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16remoteproc: k3-dsp: Add support for L2RAM loading on C66x DSPsSuman Anna1-7/+83
The resets for the DSP processors on K3 SoCs are managed through the Power and Sleep Controller (PSC) module. Each DSP typically has two resets - a global module reset for powering on the device, and a local reset that affects only the CPU while allowing access to the other sub-modules within the DSP processor sub-systems. The C66x DSPs have two levels of internal RAMs that can be used to boot from, and the firmware loading into these RAMs require the local reset to be asserted with the device powered on/enabled using the module reset. Enhance the K3 DSP remoteproc driver to add support for loading into the internal RAMs. The local reset is deasserted on SoC power-on-reset, so logic has to be added in probe in remoteproc mode to balance the remoteproc state-machine. Note that the local resets are a no-op on C71x cores, and the hardware does not supporting loading into its internal RAMs. Signed-off-by: Suman Anna <s-anna@ti.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 15:09:41 +0000