u-boot/drivers/remoteproc/Makefile

# SPDX-License-Identifier: GPL-2.0+
#
# (C) Copyright 2015
# Texas Instruments Incorporated - http://www.ti.com/
#

obj-$(CONFIG_$(SPL_)REMOTEPROC) += rproc-uclass.o

# Remote proc drivers - Please keep this list alphabetically sorted.
obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o
obj-$(CONFIG_REMOTEPROC_K3) += k3_rproc.o
obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
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-06 21:58:06 +00:00			`# SPDX-License-Identifier: GPL-2.0+`
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-09-17 20:42:39 +00:00			`#`
			`# (C) Copyright 2015`
			`# Texas Instruments Incorporated - http://www.ti.com/`
			`#`

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-08-27 10:27:53 +00:00			`obj-$(CONFIG_$(SPL_)REMOTEPROC) += rproc-uclass.o`
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-09-17 20:42:40 +00:00
			`# Remote proc drivers - Please keep this list alphabetically sorted.`
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-08-27 10:27:51 +00:00			`obj-$(CONFIG_K3_SYSTEM_CONTROLLER) += k3_system_controller.o`
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-08-27 10:27:52 +00:00			`obj-$(CONFIG_REMOTEPROC_K3) += k3_rproc.o`
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-09-17 20:42:40 +00:00			`obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o`
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-02-25 18:53:45 +00:00			`obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o`