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