Commit graph

87 commits

Author SHA1 Message Date
Simon Glass
c46760d596 global: Rename SPL_ to XPL_
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.

Signed-off-by: Simon Glass <sjg@chromium.org>
2024-10-11 11:44:48 -06:00
MD Danish Anwar
6dd95456f7 remoteproc: uclass: Modify uc_pdata->name to use combination of device name and device's parent name
uc_pdata->name is populated from device tree property "remoteproc-name".
For those devcices that don't set "remoteproc-name", uc_pdata->name
falls back to dev->name.

If two devices have same name, this will result into uc_pdata->name not
being unique and rproc_init() will fail.

Fix this by using combination of dev->name and dev->parent->name instead
of using just the dev->name to populate uc_pdata->name.

Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Andrew Davis <afd@ti.com>
2024-08-27 11:17:39 -06:00
Marek Vasut
136d76f5a3 drivers: remoteproc: Remove duplicate newlines
Drop all duplicate newlines. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-07-22 10:53:06 -06:00
Tom Rini
30060e0480 Merge patch series "Adding support to load secure firmware for HS devices"
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-07 14:01:15 -06:00
Manorit Chawdhry
5b5bb51af8 drivers: remoteproc: ti_k3 : enable secure booting with firmware images
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-06-07 14:00:43 -06:00
Tom Rini
03de305ec4 Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"
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-20 13:35:03 -06:00
Tom Rini
d4781422d1 Prepare v2024.07-rc3
-----BEGIN PGP SIGNATURE-----
 
 iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmZLdOcACgkQFHw5/5Y0
 tyxIBgwAq83rYBPV5D4JIurAvQ3W34cYDFdDhlph7RFjd8eCfsyYIvHRjRBzQfMf
 YdMdOxsAzXVm/l//ZUOF4tuXHw74IsBgG8gZou8ggD4Crya5OvIbxKHGZAS24d/8
 dmqG8jSxrjwqkyxhAyHfmceL9rlNO7VCPY2YoP8GEZybmagN6LV4SREG+aTzGj5t
 ExWFpK24E90qXMH6XPbZs1kAPFsRr8HwyG5IlOMdpE1KL256gdTeEec/pT7cXt5M
 QcOm9nIJKDrgOvxSb4eGagmYP1K7upMyvhbqGrzTpV0PRYLNiVeLJMAiM2xVrhw9
 T9gNedIrDviUwoMNIWkDTQNobuXafro9Qh/eoXjELNvMKGYVet7Hp7WEwyaHEjuA
 hCgflFH3vmx/7oxQNb92jd2h1HCreX3SpzVY6T49lmAtQHIvzDdlQluiF8Vpgf/K
 CQT3CIGgKiWJ/si185UvIFwjyFdqDeZxIC/s/WD9u4XQP5Wpn3xImEK31/3lN5jw
 FeiehuIP
 =RH8n
 -----END PGP SIGNATURE-----

Merge tag 'v2024.07-rc3' into next

Prepare v2024.07-rc3
2024-05-20 10:16:33 -06:00
Tom Rini
d678a59d2d Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""
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 c8ffd1356d, reversing
changes made to 2ee6f3a5f7.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-19 08:16:36 -06:00
Tom Rini
85e2c6900e Merge patch series "Add remoteproc driver for AM62a SoC"
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-15 10:45:33 -06:00
Hari Nagalla
8d5e97181e remoteproc: k3-r5: Add support for R5F core on AM62A SoCs
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-15 10:45:27 -06:00
Hari Nagalla
a5366098b6 remoteproc: k3-dsp: Enable C71x support for AM62A
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-15 10:45:27 -06:00
Tom Rini
c67199962b Merge patch series "Add AM64x Support to PRUSS and PRU_RPROC driver"
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-10 11:33:01 -06:00
MD Danish Anwar
2b1a5d2217 remoteproc: pru: Add support for AM64x PRU / RTU cores
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-10 10:44:54 -06:00
Tom Rini
f07668b30a remoteproc: Remove <common.h> and add needed includes
Remove <common.h> from this driver directory and when needed
add missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-07 08:00:56 -06:00
MD Danish Anwar
fb49d6c289 remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
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-22 15:50:28 -04:00
Hari Nagalla
df479dde31 remoteproc: k3-dsp: Extend support for C71x DSPs on J721S2 SoCs
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-22 15:50:21 -04:00
Hari Nagalla
f732b8747f remoteproc: k3-r5: Extend support for R5F clusters on J721S2 SoCs
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>
2024-03-22 15:50:21 -04:00
Udit Kumar
34fc186123 remoteproc: k3-dsp: Avoid reloading of firmware
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-12-19 10:07:48 -05:00
Nishanth Menon
a94a4071d4 tree-wide: Replace http:// link with https:// link for ti.com
Replace instances of http://www.ti.com with https://www.ti.com

Signed-off-by: Nishanth Menon <nm@ti.com>
2023-11-10 11:01:50 -05:00
Simon Glass
1e94b46f73 common: Drop linux/printk.h from common header
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-09-24 09:54:57 -04:00
Dan Carpenter
f9a12cc92a remoteproc: uclass: Clean up a return
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-08-08 17:05:43 -04:00
Manorit Chawdhry
65f3afc6b9 remoteproc: ti_k3_arm64: Change the startup of arm64 core
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>
2023-04-24 13:18:48 -04:00
Keerthy
fc6b41fefb remoteproc: ipu: Add driver to bring up ipu
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-08 11:00:03 -05:00
Keerthy
a03df89844 remoteproc: uclass: Add remoteproc resource handling helpers
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-08 11:00:03 -05:00
Nishanth Menon
473bd5aee1 remoteproc: k3_system_controller: Support optional boot_notification channel
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-02-08 09:41:26 -05:00
Heinrich Schuchardt
185f812c41 doc: replace @return by Return:
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>
2022-01-19 18:11:34 +01:00
Patrick Delaunay
e2170c29ee remoteproc: migrate uclass to livetree
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-10-05 08:50:15 -04:00
Keerthy
02bfcc5c3a remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs
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-15 17:56:04 +05:30
Patrick Delaunay
b953ec2bca dm: define LOG_CATEGORY for all uclass
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-07-06 10:38:03 -06:00
Tero Kristo
25805b6f0c remoteproc: k3-r5: remove sysfw PM calls if not supported
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-06-11 16:34:52 +05:30
Tom Rini
2ae80437fb Merge branch '2021-02-02-drop-asm_global_data-when-unused'
- Merge the patch to take <asm/global_data.h> out of <common.h>
2021-02-15 10:16:45 -05:00
Suman Anna
468ec2f3ef remoteproc: k3_r5: Sync to upstreamed kernel DT property names
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-04 20:37:56 +05:30
Simon Glass
401d1c4f5d common: Drop asm/global_data.h from common header
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-02-02 15:33:42 -05:00
Patrick Delaunay
c886cd6eea remoproc: stm32: migrate trace to log macro
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-13 09:52:58 +01:00
Nishanth Menon
ea3f534806 remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC
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] 6a22d9ea3c

Signed-off-by: Nishanth Menon <nm@ti.com>
2021-01-12 10:59:04 +05:30
Simon Glass
20e442ab2d dm: Rename U_BOOT_DEVICE() to U_BOOT_DRVINFO()
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-05 12:26:35 -07:00
Simon Glass
73466df3e2 dm: core: Access device flags through functions
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-05 12:24:41 -07:00
Simon Glass
0fd3d91152 dm: Use access methods for dev/uclass private data
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>
2021-01-05 12:24:40 -07:00
Simon Glass
b012ff1f1b dm: treewide: Update 'auto' declarations to be on one line
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-13 16:51:09 -07:00
Simon Glass
caa4daa2ae dm: treewide: Rename 'platdata' variables to just 'plat'
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-13 16:51:08 -07:00
Simon Glass
41575d8e4c dm: treewide: Rename auto_alloc_size members to be shorter
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-12-13 08:00:25 -07:00
Patrick Delaunay
9ed6f929a3 remoteproc: stm32: update error management in stm32_copro_start
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-25 11:32:31 +01:00
Patrick Delaunay
5a536dfe33 remoteproc: stm32: use reset for hold boot
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-11-25 11:32:31 +01:00
Sean Anderson
d7bd29c912 remoteproc: k3: Fix not calling dev_xxx with a device
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-30 08:53:42 -04:00
Sean Anderson
44f1c38a32 remoteproc: k3-r5: Fix not calling dev_xxx with a device
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-30 08:53:40 -04:00
Sean Anderson
b608c54b52 remoteproc: Remove unused function rproc_elf_sanity_check
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-30 08:53:38 -04:00
Suman Anna
6aa3b740c3 remoteproc: k3-r5: Add support for J7200 R5Fs
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-09-15 18:51:53 +05:30
Simon Glass
f7ae49fc4f common: Drop log.h from common header
Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:18 -04:00
Simon Glass
90526e9fba common: Drop net.h from common header
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-05-18 17:33:31 -04:00
Suman Anna
445b45042c remoteproc: k3-r5: Fix rproc init failure on Split-mode _only_ devices
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: 4c850356a8 ("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-16 12:33:19 +05:30