brain-hackers_pepepper-mirror/u-boot-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/u-boot-brain synced 2024-06-09 23:36:03 +09:00
Code Issues Projects Releases Wiki Activity
e8fc0d0cf3
u-boot-brain/drivers/remoteproc/Kconfig

85 lines
2.1 KiB
Plaintext
Raw Normal View History

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 06:58:06 +09: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-18 05:42:39 +09:00
#
# (C) Copyright 2015
# Texas Instruments Incorporated - http://www.ti.com/
#
menu "Remote Processor drivers"
# REMOTEPROC gets selected by drivers as needed
# All users should depend on DM
config REMOTEPROC
bool
depends on DM
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-18 05:42:40 +09:00
# Please keep the configuration 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 19:27:51 +09:00
config K3_SYSTEM_CONTROLLER
bool "Support for TI' K3 System Controller"
select REMOTEPROC
depends on DM
depends on ARCH_K3
depends on OF_CONTROL
help
Say 'y' here to add support for TI' K3 System Controller.
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-18 05:42:40 +09:00
config REMOTEPROC_SANDBOX
bool "Support for Test processor for Sandbox"
select REMOTEPROC
depends on DM
depends on SANDBOX
help
Say 'y' here to add support for test processor which does dummy
operations for sandbox platform.
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-26 03:53:45 +09:00
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-05-31 22:11:34 +09:00
config REMOTEPROC_STM32_COPRO
bool "Support for STM32 coprocessor"
select REMOTEPROC
depends on DM
depends on ARCH_STM32MP
depends on OF_CONTROL
help
Say 'y' here to add support for STM32 Cortex-M4 coprocessors via the
remoteproc framework.
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-06-07 22:55:59 +09:00
config REMOTEPROC_TI_K3_ARM64
bool "Support for TI's K3 based ARM64 remoteproc driver"
select REMOTEPROC
depends on DM
depends on ARCH_K3
depends on OF_CONTROL
help
Say y here to support TI's ARM64 processor subsystems
on various TI K3 family of SoCs through the remote processor
framework.
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-09-04 19:31:36 +09:00
config REMOTEPROC_TI_K3_DSP
bool "TI K3 C66 and C71 remoteproc support"
select REMOTEPROC
depends on ARCH_K3
depends on TI_SCI_PROTOCOL
help
Say y here to support TI's C66/C71 remote processor subsystems
on various TI K3 family of SoCs through the remote processor
framework.
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-09-04 19:31:34 +09:00
config REMOTEPROC_TI_K3_R5F
bool "TI K3 R5F remoteproc support"
select REMOTEPROC
depends on ARCH_K3
depends on TI_SCI_PROTOCOL
help
Say y here to support TI's R5F remote processor subsystems
on various TI K3 family of SoCs through the remote processor
framework.
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-26 03:53:45 +09:00
config REMOTEPROC_TI_POWER
bool "Support for TI Power processor"
select REMOTEPROC
depends on DM
depends on ARCH_KEYSTONE
depends on OF_CONTROL
help
Say 'y' here to add support for TI power processors such as those
found on certain TI keystone and OMAP generation SoCs.
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-18 05:42:39 +09:00
endmenu
Reference in New Issue Copy Permalink