Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
kernel-fxtec-pro1x/drivers/remoteproc/Kconfig

81 lines
2.3 KiB
Text
Raw Normal View History

drivers/remoteproc: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-16 19:53:51 -07:00
menu "Remoteproc drivers"
remoteproc: add Kconfig menu Add a dedicated Kconfig menu for the remoteproc drivers, so they don't show up in the main driver menu. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2011-12-14 04:01:59 -07:00
remoteproc: add framework for controlling remote processors Modern SoCs typically employ a central symmetric multiprocessing (SMP) application processor running Linux, with several other asymmetric multiprocessing (AMP) heterogeneous processors running different instances of operating system, whether Linux or any other flavor of real-time OS. Booting a remote processor in an AMP configuration typically involves: - Loading a firmware which contains the OS image - Allocating and providing it required system resources (e.g. memory) - Programming an IOMMU (when relevant) - Powering on the device This patch introduces a generic framework that allows drivers to do that. In the future, this framework will also include runtime power management and error recovery. Based on (but now quite far from) work done by Fernando Guzman Lugo <fernando.lugo@ti.com>. ELF loader was written by Mark Grosen <mgrosen@ti.com>, based on msm's Peripheral Image Loader (PIL) by Stephen Boyd <sboyd@codeaurora.org>. Designed with Brian Swetland <swetland@google.com>. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Cc: Brian Swetland <swetland@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Tony Lindgren <tony@atomide.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <greg@kroah.com> Cc: Stephen Boyd <sboyd@codeaurora.org>
2011-10-20 08:52:46 -06:00
# REMOTEPROC gets selected by whoever wants it
config REMOTEPROC
tristate
remoteproc: Add dependency to HAS_DMA Remoteproc relies on HAS_DMA, add this dependency in Kconfig. Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-13 12:03:58 -06:00
depends on HAS_DMA
remoteproc: perserve resource table data Copy resource table from first to second firmware loading. After firmware is loaded to memory, update the vdevs resource pointer to the resource table kept in device memory. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Acked-by: Ido Yariv <ido@wizery.com> [rebase, terminology and style changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-04-07 05:06:07 -06:00
select CRC32
remoteproc: fix FW_CONFIG typo Fix obvious typo introduced in commit e121aefa7d9f10eee5cf26ed47129237a05d940b ("remoteproc: fix missing CONFIG_FW_LOADER configurations"). Cc: stable@vger.kernel.org Signed-off-by: Robert Tivy <rtivy@ti.com> [cc stable, slight subject change] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-03-28 19:41:43 -06:00
select FW_LOADER
remoteproc: select VIRTIO to avoid build breakage drivers/built-in.o: In function `rproc_virtio_finalize_features': remoteproc_virtio.c:(.text+0x2f9a02): undefined reference to `vring_transport_features' drivers/built-in.o: In function `rproc_virtio_del_vqs': remoteproc_virtio.c:(.text+0x2f9a74): undefined reference to `vring_del_virtqueue' drivers/built-in.o: In function `rproc_virtio_find_vqs': remoteproc_virtio.c:(.text+0x2f9c44): undefined reference to `vring_new_virtqueue' drivers/built-in.o: In function `rproc_add_virtio_dev': (.text+0x2f9e2c): undefined reference to `register_virtio_device' drivers/built-in.o: In function `rproc_vq_interrupt': (.text+0x2f9db7): undefined reference to `vring_interrupt' drivers/built-in.o: In function `rproc_remove_virtio_dev': (.text+0x2f9e9f): undefined reference to `unregister_virtio_device' Cc: stable@vger.kernel.org Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-30 02:25:34 -06:00
select VIRTIO
remoteproc: fix kconfig dependencies for VIRTIO Fix this: warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION) Cc: stable@vger.kernel.org Signed-off-by: Suman Anna <s-anna@ti.com> [edit commit log] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-04-21 07:29:38 -06:00
select VIRTUALIZATION
remoteproc/omap: add a remoteproc driver for OMAP4 Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and and DSP subsystems. Use the omap_device_* API to control the hardware state, and utilize the OMAP mailbox to interrupt the remote processor when a new message is pending (the mailbox payload is used to tell it which virtqueue was the message placed in). Conversely, when an inbound mailbox message arrives, tell the remoteproc core which virtqueue is triggered. Later we will also use the mailbox payload to signal omap-specific events like remote crashes (which will be used to trigger remoteproc recovery) and power management transitions. At that point we will also extend the remoteproc core to support this. Based on (but now quite far from) work done by Fernando Guzman Lugo <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>. Designed with Brian Swetland <swetland@google.com>. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Brian Swetland <swetland@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Russell King <linux@arm.linux.org.uk> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <greg@kroah.com> Cc: Stephen Boyd <sboyd@codeaurora.org>
2011-10-20 10:53:35 -06:00
config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
remoteproc: Add dependency to HAS_DMA Remoteproc relies on HAS_DMA, add this dependency in Kconfig. Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-13 12:03:58 -06:00
depends on HAS_DMA
remoteproc/omap: support OMAP5 too This allows building remoteproc on OMAP5 too. Signed-off-by: Vincent Stehlé <v-stehle@ti.com> [edit commit log] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-02-18 04:06:52 -07:00
depends on ARCH_OMAP4 || SOC_OMAP5
remoteproc/omap: two Kconfig fixes 1. Depend on OMAP_IOMMU instead of selecting it, to fix an unmet direct dependency of it (and its imminent build error) 2. Set default to 'no' (achieved implicitly by dropping the 'default' line) Reported-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mark Grosen <mgrosen@ti.com> Cc: Suman Anna <s-anna@ti.com> Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Cc: Rob Clark <rob@ti.com> Cc: Ludovic BARRE <ludovic.barre@stericsson.com> Cc: Loic PALLARDY <loic.pallardy@stericsson.com> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Cc: Russell King <linux@arm.linux.org.uk>
2012-02-28 04:04:33 -07:00
depends on OMAP_IOMMU
remoteproc/omap: add a remoteproc driver for OMAP4 Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and and DSP subsystems. Use the omap_device_* API to control the hardware state, and utilize the OMAP mailbox to interrupt the remote processor when a new message is pending (the mailbox payload is used to tell it which virtqueue was the message placed in). Conversely, when an inbound mailbox message arrives, tell the remoteproc core which virtqueue is triggered. Later we will also use the mailbox payload to signal omap-specific events like remote crashes (which will be used to trigger remoteproc recovery) and power management transitions. At that point we will also extend the remoteproc core to support this. Based on (but now quite far from) work done by Fernando Guzman Lugo <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>. Designed with Brian Swetland <swetland@google.com>. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Brian Swetland <swetland@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Russell King <linux@arm.linux.org.uk> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <greg@kroah.com> Cc: Stephen Boyd <sboyd@codeaurora.org>
2011-10-20 10:53:35 -06:00
select REMOTEPROC
mailbox/omap: move the OMAP mailbox framework to drivers The mailbox hardware (in OMAP) uses a queued mailbox interrupt mechanism that provides a communication channel between processors through a set of registers and their associated interrupt signals by sending and receiving messages. The OMAP mailbox framework/driver code is moved to be under drivers/mailbox, in preparation for adapting to a common mailbox driver framework. This allows the build for OMAP mailbox to be enabled (it was disabled during the multi-platform support). As part of the migration from plat and mach code: - Kconfig symbols have been renamed to build OMAP1 or OMAP2+ drivers. - mailbox.h under plat-omap/plat/include has been split into a public and private header files. The public header has only the API related functions and types. - The module name mailbox.ko from plat-omap is changed to omap-mailbox.ko - The module name mailbox_mach.ko from mach-omapX is changed as mailbox_omap1.ko for OMAP1 mailbox_omap2.ko for OMAP2+ Cc: Tony Lindgren <tony@atomide.com> [gregkh@linuxfoundation.org: ack for staging part] Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Omar Ramirez Luna <omar.ramirez@copitl.com> Signed-off-by: Suman Anna <s-anna@ti.com>
2013-03-12 16:55:29 -06:00
select MAILBOX
select OMAP2PLUS_MBOX
remoteproc/omap: add a remoteproc driver for OMAP4 Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and and DSP subsystems. Use the omap_device_* API to control the hardware state, and utilize the OMAP mailbox to interrupt the remote processor when a new message is pending (the mailbox payload is used to tell it which virtqueue was the message placed in). Conversely, when an inbound mailbox message arrives, tell the remoteproc core which virtqueue is triggered. Later we will also use the mailbox payload to signal omap-specific events like remote crashes (which will be used to trigger remoteproc recovery) and power management transitions. At that point we will also extend the remoteproc core to support this. Based on (but now quite far from) work done by Fernando Guzman Lugo <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>. Designed with Brian Swetland <swetland@google.com>. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Brian Swetland <swetland@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Russell King <linux@arm.linux.org.uk> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <greg@kroah.com> Cc: Stephen Boyd <sboyd@codeaurora.org>
2011-10-20 10:53:35 -06:00
select RPMSG
help
Say y here to support OMAP's remote processors (dual M3
and DSP on OMAP4) via the remote processor framework.
Currently only supported on OMAP4.
Usually you want to say y here, in order to enable multimedia
use-cases to run on your platform (multimedia codecs are
offloaded to remote DSP processors using this framework).
It's safe to say n here if you're not interested in multimedia
offloading or just want a bare minimum kernel.
remoteproc: add Kconfig menu Add a dedicated Kconfig menu for the remoteproc drivers, so they don't show up in the main driver menu. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2011-12-14 04:01:59 -07:00
remoteproc: Add STE modem driver Add support for the STE modem shared memory driver. This driver hooks into the remoteproc framework in order to manage configuration and the virtio devices. This driver adds custom firmware handlers, because STE modem uses a custom firmware layout. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> cc: Linus Walleij <linus.walleij@linaro.org> cc: Alan Cox <alan@lxorguk.ukuu.org.uk> [ohad: validate mdev->ops, move setup() to probe/remove, trivial style changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-20 10:32:56 -06:00
config STE_MODEM_RPROC
tristate "STE-Modem remoteproc support"
depends on HAS_DMA
select REMOTEPROC
default n
help
Say y or m here to support STE-Modem shared memory driver.
This can be either built-in or a loadable module.
If unsure say N.
remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3 Add a remoteproc driver to load the firmware and boot a small Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This Wakeup M3 remote processor is an integrated Cortex M3 that allows the SoC to enter the lowest possible power state by taking control from the MPU after it has gone into its own low power state and shutting off any additional peripherals. The Wakeup M3 processor has two internal memory regions - 16 kB of unified instruction memory called UMEM used to store executable code, and 8 kB of data memory called DMEM used for all data sections. The Wakeup M3 processor executes its code entirely from within the UMEM and uses the DMEM for any data. It does not use any external memory or any other external resources. The device address view has the UMEM at address 0x0 and DMEM at address 0x80000, and these are computed automatically within the driver based on relative address calculation from the corresponding device tree IOMEM resources. These device addresses are used to aid the core remoteproc ELF loader code to properly translate and load the firmware segments through the .rproc_da_to_va ops. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2015-05-22 14:45:30 -06:00
config WKUP_M3_RPROC
tristate "AMx3xx Wakeup M3 remoteproc support"
depends on SOC_AM33XX || SOC_AM43XX
select REMOTEPROC
help
Say y here to support Wakeup M3 remote processor on TI AM33xx
and AM43xx family of SoCs.
Required for Suspend-to-RAM on AM33xx and AM43xx SoCs. Also needed
for deep CPUIdle states on AM33xx SoCs. Allows for loading of the
firmware onto these remote processors.
If unsure say N.
remoteproc/davinci: add a remoteproc driver for OMAP-L13x DSP Adding a new remoteproc driver for OMAP-L13x DSP Signed-off-by: Robert Tivy <rtivy@ti.com> [removed 'EXPERIMENTAL' and fixed some indentation issues] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-04-09 15:20:21 -06:00
config DA8XX_REMOTEPROC
tristate "DA8xx/OMAP-L13x remoteproc support"
depends on ARCH_DAVINCI_DA8XX
remoteproc: da8xx: don't select CMA on no-MMU We can only use CMA on systems that have an MMU, because of the requirement to use memory migration. NOMMU systems are rather constrained to start with, but it seems reasonable to assume that DMA allocations can still succeed in the constrained case for remoteproc on NOMMU, so this patch changes the da8xx implementation to not rely on CMA when the MMU is disabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Robert Tivy <rtivy@ti.com>
2014-04-11 10:14:26 -06:00
select CMA if MMU
remoteproc/davinci: add a remoteproc driver for OMAP-L13x DSP Adding a new remoteproc driver for OMAP-L13x DSP Signed-off-by: Robert Tivy <rtivy@ti.com> [removed 'EXPERIMENTAL' and fixed some indentation issues] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-04-09 15:20:21 -06:00
select REMOTEPROC
select RPMSG
help
Say y here to support DA8xx/OMAP-L13x remote processors via the
remote processor framework.
You want to say y here in order to enable AMP
use-cases to run on your platform (multimedia codecs are
offloaded to remote DSP processors using this framework).
This module controls the name of the firmware file that gets
loaded on the DSP. This file must reside in the /lib/firmware
directory. It can be specified via the module parameter
da8xx_fw_name=<filename>, and if not specified will default to
"rproc-dsp-fw".
It's safe to say n here if you're not interested in multimedia
offloading.
remoteproc: add Kconfig menu Add a dedicated Kconfig menu for the remoteproc drivers, so they don't show up in the main driver menu. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2011-12-14 04:01:59 -07:00
endmenu
Reference in a new issue Copy permalink