Commit graph

27 commits

Author SHA1 Message Date
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
Fabien Dessenne
7a7c4cb0f0 remoteproc: add elf file load support
The current implementation supports only binary file load.
Add helpers to support ELF32 format (sanity check, and load).
Note that since an ELF32 image is built for the remote processor, the
load function uses the device_to_virt ops to translate the addresses.
Implement a basic translation for sandbox_testproc.

Add related tests. Test result:
=> ut dm remoteproc_elf
Test: dm_test_remoteproc_elf: remoteproc.c
Test: dm_test_remoteproc_elf: remoteproc.c (flat tree)
Failures: 0

Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-22 09:21:28 +02:00
Lokesh Vutla
0d7b6cffa5 remoteproc: k3_system_controller: Increase rx timeout
There is one case where 400ms is not sufficient for loading the
system firmware:
- System firmware is not signed with rsa degenerate key.
- ROM loading the sysfw directly from SPI flash which is in memory
  mapped mode.

The above scenario is definitely not desired in production use cases
as it effects boot time. But still keeping this support as this is
a valid boot scenario.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-09 20:22:05 -04:00
Lokesh Vutla
08c45314a8 spl: Allow remoteproc drivers to be used within SPL
Add an option for building remoteproc drivers within SPL.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
c365ed7d4b remoteproc: Introduce K3 remoteproc driver
Add support for K3 based remoteproc driver that
communicates with TISCI to start start a remote processor.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
1ad190bf59 remoteproc: Introduce K3 system controller
K3 specific SoCs have a dedicated microcontroller for doing
resource management. Any HLOS/firmware on compute clusters should
load a firmware to this microcontroller before accessing any resource.
Adding support for loading this firmware.

After the K3 system controller got loaded with firmware and started
up it sends out a boot notification message through the secure proxy
facility using the TI SCI protocol. Intercept and receive this message
through the rproc start operation which will need to get invoked
explicitly after the firmware got loaded.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
81ae6e6d00 remoteproc: Allow for individual remoteproc initialization
Existing rproc_init() api tries to initialize all available
remoteproc devices. This will fail when there is dependency
among available remoteprocs. So introduce a separate api
that allows to initialize remoteprocs individually based
on id.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Simon Glass
e160f7d430 dm: core: Replace of_offset with accessor
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-02-08 06:12:14 -07:00
Nishanth Menon
4239284973 remoteproc: Add support for TI power processor
Many TI System on Chip (SoC) solutions do have a dedicated
microcontroller for doing power management functionality. These include
the AM335x, AM437x, Keystone K2G SoCs. The functionality provided by
these microcontrollers and the communication mechanisms vary very
widely. However, we are able to consolidate some basic functionality to
be generic enough starting with K2G SoC family. Introduce a basic remote
proc driver to support these microcontrollers. In fact, on SoCs starting
with K2G, basic power management functions are primarily accessible for
the High Level Operating Systems(HLOS) via these microcontroller solutions.

Hence, having these started at a bootloader level is pretty much
mandatory.

Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-14 19:18:37 -04:00
Nishanth Menon
9cb05a8f9f drivers: remoteproc: rproc-uclass: Fix check for NULL pointers
Neither uc_pdata->name nor check_name are supposed to be NULL in
_rproc_name_is_unique(). if uc_pdata->name is NULL, we are not
intialized yet, however if check_data is NULL, we do not have
proper data. Further, if either were NULL, strlen will crap out
while attempting to derefence NULL.

Instead, just check if either of these are NULL and bail out.

This should also fix the following coverity scan warnings:
*** CID 132281:  Null pointer dereferences  (FORWARD_NULL)
/drivers/remoteproc/rproc-uclass.c: 73 in _rproc_name_is_unique()

Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
2015-12-05 18:22:32 -05:00
Nishanth Menon
3df0b8b4da remoteproc: Introduce a sandbox dummy driver
Introduce a dummy driver for sandbox that allows us to verify basic
functionality. This is not meant to do anything functional - but is
more or less meant as a framework plumbing debug helper.

The sandbox remoteproc driver maintains absolutey no states and is a
simple driver which just is filled with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-10-22 14:18:39 -04:00
Nishanth Menon
ddf56bc7e3 drivers: Introduce a simplified remoteproc framework
Many System on Chip(SoC) solutions are complex with multiple processors
on the same die dedicated to either general purpose of specialized
functions. Many examples do exist in today's SoCs from various vendors.
Typical examples are micro controllers such as an ARM M3/M0 doing a
offload of specific function such as event integration or power
management or controlling camera etc.

Traditionally, the responsibility of loading up such a processor with a
firmware and communication has been with a High Level Operating
System(HLOS) such as Linux. However, there exists classes of products
where Linux would need to expect services from such a processor or the
delay of Linux and operating system being able to load up such a
firmware is unacceptable.

To address these needs, we need some minimal capability to load such a
system and ensure it is started prior to an Operating System(Linux or
any other) is started up.

NOTE: This is NOT meant to be a solve-all solution, instead, it tries to
address certain class of SoCs and products that need such a solution.

A very simple model is introduced here as part of the initial support
that supports microcontrollers with internal memory (no MMU, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-10-22 14:18:38 -04:00