Commit graph

62 commits

Author SHA1 Message Date
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
Suman Anna
0438a0a181 remoteproc: k3-r5: Fix rproc init failure for Main R5FSS0
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 af94ad418d
("dm: core: Allow for not controlling the power-domain by DM framework").

Fixes: fac6aa817a ("configs: j721e_evm_r5: Enable R5F remoteproc support")
Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16 12:33:03 +05:30
Suman Anna
42005817ee remoteproc: k3-dsp: Add support for L2RAM loading on C66x DSPs
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>
2020-03-16 12:32:47 +05:30
Suman Anna
1e53d5b585 remoteproc: k3-dsp: Add a sanity check for DSP boot address alignment
The DSP remote processors on K3 SoCs require a boot register to be
programmed with a boot address, and these boot addresses need to be
aligned on certain address boundaries. The current code does not have
any error checks, and relies on the System Firmware to perform the
checking. Add logic to perform this sanity check within the remoteproc
driver itself to detect these anomalies specifically, and print a
meaningful trace. This avoids the cumbersome debug of root-causing
such failures from the corresponding TI-SCI failure.

The C66x and C71x DSP cores have different alignment needs and are
as follows:
	C66x DSP = 1 KB (0x400)
	C71x DSP = 2 MB (0x200000)

Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16 12:32:47 +05:30
Suman Anna
0020003ef3 remoteproc: k3-dsp: Fix unbalanced state machine in k3_dsp_start
The global module reset is deasserted through the ti_sci_power_domain_on()
call in k3_dsp_start(), but is not asserted back if the local module reset
fails. Fix this.

While at this, remove the stale comment about assigned-clock-rates that
seems to have been copied from the K3 ARM64 Remoteproc driver.

Fixes: ab827b3857 ("remoteproc: Introduce K3 C66 and C71 remoteproc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>
2020-03-16 12:32:47 +05:30
Simon Glass
336d4615f8 dm: core: Create a new header file for 'compat' features
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05 19:33:46 -07:00
Simon Glass
61b29b8268 dm: core: Require users of devres to include the header
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
2020-02-05 19:33:46 -07:00
Fabien Dessenne
83b539cfd4 remoteproc: elf_loader: fix program header parsing
Fix an issue where some sections are never loaded : if p_type is
different from PT_LOAD the phdr pointer must be incremented.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Suman Anna <s-anna@ti.com>
2020-01-24 11:19:52 -05:00
Fabien Dessenne
33fd41951a remoteproc: stm32: load resource table from firmware
Load the optional resource table from the firmware, and write its
address in the dedicated backup register.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-07 11:13:25 -05:00
Fabien Dessenne
4a4deb870f remoteproc: stm32: track the coprocessor state in a backup register
Update the dedicated backup register to track the coprocessor state and
rely on that register to compute the .is_running() value (which expects
a return value of 0 -not 1- if the processor is running).

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-07 11:13:25 -05:00
Fabien Dessenne
ffcb880de8 remoteproc: elf_loader: Add elf resource table load support
Add rproc_elf_load_rsc_table(), which searches for a resource table in
an elf64/elf32 image, and if found, copies it to device memory.
Add also the elf32 and elf64 variants of this API.
Add a test for this.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-07 11:13:25 -05:00
Simon Glass
1eb69ae498 common: Move ARM cache operations out of common.h
These functions are CPU-related and do not use driver model. Move them to
cpu_func.h

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2019-12-02 18:24:58 -05:00
Lokesh Vutla
af17b0dad5 remoteproc: k3_arm64: Enable DM_FLAG_DEFAULT_PD_CTRL_OFF
Enable DM_FLAG_DEFAULT_PD_CTRL_OFF for arm64 remote core so that
pd can be enabled after loading the image.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2019-10-15 08:40:03 -06:00
Lokesh Vutla
ab827b3857 remoteproc: Introduce K3 C66 and C71 remoteproc driver
Certain SoCs with K3 architecture have integrated a C66 Corepac DSP
subsystem and an advanced C71 DSPs. Introduce a remoteproc driver
that that does take care of loading an elf to any of the specified
DSPs and start it.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
4c850356a8 remoteproc: Introduce K3 remoteproc driver for R5F subsystem
SoCs with K3 architecture have an integrated Arm Cortex-R5F subsystem
that is comprised of dual-core Arm Cortex-R5F processor cores. This R5
subsytem 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 each Tightly-Coupled Memory (TCM) internal memories
for each core split between two banks - TCMA and TCMB.

Add a remoteproc driver to support this subsystem to be able to load
and boot the R5 cores primarily in LockStep mode or split mode.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
f7954828b8 remoteproc: tisci_proc: Add helper api for controlling core power domain
Power domain for the remote cores needs to be handled in a right
sequence as mandated by the spec. Introduce tisci helper apis
that can control power-domains of remote cores. TISCI clients
can use this api and control the remote cores power domain instead
of hooking it to power-domain layer.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
81e39fbd92 remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api
Introduce rproc_elf_get_boot_addr() that returns the entry point of
the elf file. This api auto detects the 64/32 bit elf file and returns
the boot addr accordingly.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
856c0ad413 remoteproc: elf_loader: Introduce a common elf loader and checker functions
Introduce a common remoteproc elf loader and checker functions that
automatically detects the 64 bit elf file or 32 bit elf file and
loads/checks the sections accordingly.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
e3c4d6f01f remoteproc: elf-loader: Add 64 bit elf loading support
The current rproc-elf-loader supports loading of only 32 bit elf files.
Introduce support for loading of 64 bit elf files in rproc-elf-loader.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
14d963d1b5 remoteproc: elf_loader: Always check the validity of the image before loading
rproc_elf32_load_image() rely on user to send a valid address for elf loading.
Instead do a sanity check on the address passed by user. This will help
all rproc elf users to not call sanity_check explicitly before calling
elf_loading.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
c08eb93626 remoteproc: ops: Add elf section size as input parameter to device_to_virt api
Introduce a new parameter "size" that accepts size of the region to
remoteproc ops callback device_to_virt(). This can enforce more checks
on the region that device_to_virt() is dealing with.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:33 -04:00
Patrick Delaunay
5d2901a4b6 stm32mp1: Add remoteproc support for m4 coprocessor
Alignment with kernel patch proposal for binding:

[PATCH v4 0/8] stm32 m4 remoteproc on STM32MP157c
https://lkml.org/lkml/2019/5/14/159

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-08-27 11:19:23 +02:00
Lokesh Vutla
54e4311fa1 remoteproc: k3_rproc: Rename to ti_k3_arm64_rproc
k3_rproc driver is specifically meant for controlling an arm64
core using TISCI protocol. So rename the driver, Kconfig symbol,
compatible and functions accordingly.

While at it drop this remoteproc selection for a53 defconfig.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-26 21:49:25 -04:00
Lokesh Vutla
44de37a00e remoteproc: k3_rproc: Update the driver to use ti_sci_proc helpers
Update the k3_rproc driver to use the generic ti_sci_proc helper
apis which simplifies the driver a bit.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-26 21:49:25 -04:00
Lokesh Vutla
4fa23ebe73 remoteproc: tisci: add TI-SCI processor control helper functions
Texas Instruments' K3 generation SoCs has specific modules/register
spaces used for configuring the various aspects of a remote processor.
These include power, reset, boot vector and other configuration features
specific to each compute processor present on the SoC. These registers
are managed by the System Controller such as DMSC on K3 AM65x SoCs.

The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used to communicate to the System Controller from various compute
processors to invoke specific services provided by the firmware running
on the System Controller.

Add a common processor control interface header file that can be used by
multiple remoteproc drivers. The helper functions within this header file
abstract the various TI SCI protocol ops for the remoteproc drivers, and
allow them to request the System Controller to be able to program and
manage various remote processors on the SoC. The common macros required
by the R5 remoteproc driver were also added. The remoteproc drivers are
expected to manage the life-cycle of their ti_sci_proc_dev local
structures.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-07-26 21:49:24 -04:00
Fabien Dessenne
6bed04fbd4 remoteproc: Introduce STM32 Cortex-M4 remoteproc driver
This patch introduces support of Cortex-M4 remote processor for STM32
MCU and MPU families.

Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-07-22 09:21:28 +02:00