hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
linux-sg2042/drivers/remoteproc/Kconfig

125 lines
3.4 KiB
Plaintext
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-17 10:53:51 +08: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 19:01:59 +08: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 22:52:46 +08:00
config REMOTEPROC
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
tristate "Support for Remote Processor subsystem"
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-14 02:03:58 +08: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 19:06:07 +08: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-29 09:41:43 +08: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 16:25:34 +08: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 21:29:38 +08: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-21 00:53:35 +08:00
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
if REMOTEPROC
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-21 00:53:35 +08: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-14 02:03:58 +08: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 19:06:52 +08: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 19:04:33 +08:00
depends on OMAP_IOMMU
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
depends on 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-13 06:55:29 +08:00
select MAILBOX
select OMAP2PLUS_MBOX
rpmsg: Move rpmsg_device API to new file Extract the now indirect rpmsg_create_ept() interface to a separate file and start building up a rpmsg core. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-09-02 06:27:59 +08:00
select RPMSG_VIRTIO
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-21 00:53:35 +08:00
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 19:01:59 +08:00
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-23 04:45:30 +08:00
config WKUP_M3_RPROC
tristate "AMx3xx Wakeup M3 remoteproc support"
depends on SOC_AM33XX || SOC_AM43XX
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
depends on REMOTEPROC
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-23 04:45:30 +08:00
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-10 05:20:21 +08:00
config DA8XX_REMOTEPROC
tristate "DA8xx/OMAP-L13x remoteproc support"
depends on ARCH_DAVINCI_DA8XX
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
depends on REMOTEPROC
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-12 00:14:26 +08:00
select CMA if MMU
rpmsg: Move rpmsg_device API to new file Extract the now indirect rpmsg_create_ept() interface to a separate file and start building up a rpmsg core. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-09-02 06:27:59 +08:00
select RPMSG_VIRTIO
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-10 05:20:21 +08:00
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: Introduce Qualcomm ADSP PIL The Qualcomm ADSP Peripheral Image Loader is used on a variety of different Qualcomm platforms for loading firmware into and controlling the Hexagon based ADSP. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-23 13:57:44 +08:00
config QCOM_ADSP_PIL
tristate "Qualcomm ADSP Peripheral Image Loader"
depends on OF && ARCH_QCOM
remoteproc: adsp-pil: fix recursive dependency The newly added driver tries to 'select' a symbol that it has an implicit dependency on, which confuses Kconfig: subsection "Kconfig recursive dependency limitations" drivers/remoteproc/Kconfig:3: symbol REMOTEPROC is selected by QCOM_ADSP_PIL As REMOTEPROC is itself user-visible, we clearly should not select it from a driver, removing the line fixes the problem. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-11-16 16:47:31 +08:00
depends on REMOTEPROC
remoteproc: Introduce Qualcomm ADSP PIL The Qualcomm ADSP Peripheral Image Loader is used on a variety of different Qualcomm platforms for loading firmware into and controlling the Hexagon based ADSP. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-23 13:57:44 +08:00
depends on QCOM_SMEM
select MFD_SYSCON
select QCOM_MDT_LOADER
remoteproc: qcom_adsp_pil: select qcom_scm The adsp-pil driver relies on SCM and causes a build error without it: ERROR: "qcom_scm_pas_supported" [drivers/remoteproc/qcom_adsp_pil.ko] undefined! ERROR: "qcom_scm_is_available" [drivers/remoteproc/qcom_adsp_pil.ko] undefined! ERROR: "qcom_scm_pas_auth_and_reset" [drivers/remoteproc/qcom_adsp_pil.ko] undefined! ERROR: "qcom_scm_pas_shutdown" [drivers/remoteproc/qcom_adsp_pil.ko] undefined! ERROR: "qcom_scm_pas_mem_setup" [drivers/remoteproc/qcom_adsp_pil.ko] undefined! ERROR: "qcom_scm_pas_init_image" [drivers/remoteproc/qcom_adsp_pil.ko] undefined! This adds a 'select', as SCM is a silent Kconfig symbol that gets enabled implicitly by all its users. Fixes: b9e718e950c3 ("remoteproc: Introduce Qualcomm ADSP PIL") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-12-09 19:47:02 +08:00
select QCOM_SCM
remoteproc: Introduce Qualcomm ADSP PIL The Qualcomm ADSP Peripheral Image Loader is used on a variety of different Qualcomm platforms for loading firmware into and controlling the Hexagon based ADSP. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-23 13:57:44 +08:00
help
Say y here to support the TrustZone based Peripherial Image Loader
for the Qualcomm ADSP remote processors.
remoteproc: qcom: Driver for the self-authenticating Hexagon v5 This driver supports bringing the Q6V5 out of reset, load and drive the self-authenticating boot loader and use this to load the mdt and subsequent bXX files. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-06-21 05:28:41 +08:00
config QCOM_MDT_LOADER
tristate
config QCOM_Q6V5_PIL
tristate "Qualcomm Hexagon V5 Peripherial Image Loader"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
depends on REMOTEPROC
remoteproc: qcom: Driver for the self-authenticating Hexagon v5 This driver supports bringing the Q6V5 out of reset, load and drive the self-authenticating boot loader and use this to load the mdt and subsequent bXX files. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-06-21 05:28:41 +08:00
select MFD_SYSCON
select QCOM_MDT_LOADER
help
Say y here to support the Qualcomm Peripherial Image Loader for the
Hexagon V5 based remote processors.
remoteproc: qcom: Introduce WCNSS peripheral image loader This introduces the peripheral image loader, for loading WCNSS firmware and boot the core on e.g. MSM8974. The firmware is verified and booted with the help of the Peripheral Authentication System (PAS) in TrustZone. Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-13 09:18:59 +08:00
config QCOM_WCNSS_PIL
tristate "Qualcomm WCNSS Peripheral Image Loader"
depends on OF && ARCH_QCOM
remoteproc: wcnss-pil: add QCOM_SMD dependency When qcom_smd is a loadable module and wcnss-pil is built-in, we get a link error: drivers/remoteproc/qcom_wcnss_pil.o: In function `wcnss_smd_remove': qcom_wcnss_iris.c:(.text.wcnss_smd_remove+0x10): undefined reference to `qcom_smd_unregister_edge' drivers/remoteproc/qcom_wcnss_pil.o: In function `wcnss_smd_probe': qcom_wcnss_iris.c:(.text.wcnss_smd_probe+0x12): undefined reference to `qcom_smd_register_edge' This adds a Kconfig dependency to avoid this. We can still allow build-testing with SMD disabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-11-19 00:15:06 +08:00
depends on QCOM_SMD || (COMPILE_TEST && QCOM_SMD=n)
remoteproc: qcom: Introduce WCNSS peripheral image loader This introduces the peripheral image loader, for loading WCNSS firmware and boot the core on e.g. MSM8974. The firmware is verified and booted with the help of the Peripheral Authentication System (PAS) in TrustZone. Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-13 09:18:59 +08:00
depends on QCOM_SMEM
remoteproc: st_slim_rproc: add a slimcore rproc driver slim core is used as a basis for many IPs in the STi chipsets such as fdma and demux. To avoid duplicating the elf loading code in each device driver a slim rproc driver has been created. This driver is designed to be used by other device drivers such as fdma, or demux whose IP is based around a slim core. The device driver can call slim_rproc_alloc() to allocate a slim rproc and slim_rproc_put() when finished. This driver takes care of ioremapping the slim registers (dmem, imem, slimcore, peripherals), whose offsets and sizes can change between IP's. It also obtains and enables any clocks used by the device. This approach avoids having a double mapping of the registers as slim_rproc does not register its own platform device. It also maps well to device tree abstraction as it allows us to have one dt node for the whole device. All of the generic rproc elf loading code can be reused, and we provide start() stop() hooks to start and stop the slim core once the firmware has been loaded. This has been tested successfully with fdma driver. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:06 +08:00
depends on REMOTEPROC
remoteproc: qcom: Introduce WCNSS peripheral image loader This introduces the peripheral image loader, for loading WCNSS firmware and boot the core on e.g. MSM8974. The firmware is verified and booted with the help of the Peripheral Authentication System (PAS) in TrustZone. Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-13 09:18:59 +08:00
select QCOM_MDT_LOADER
select QCOM_SCM
help
Say y here to support the Peripheral Image Loader for the Qualcomm
Wireless Connectivity Subsystem.
remoteproc: Supply controller driver for ST's Remote Processors Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-01-12 20:46:18 +08:00
config ST_REMOTEPROC
tristate "ST remoteproc support"
depends on ARCH_STI
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
depends on REMOTEPROC
remoteproc: Supply controller driver for ST's Remote Processors Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-01-12 20:46:18 +08:00
help
Say y here to support ST's adjunct processors via the remote
processor framework.
This can be either built-in or a loadable module.
remoteproc: st_slim_rproc: add a slimcore rproc driver slim core is used as a basis for many IPs in the STi chipsets such as fdma and demux. To avoid duplicating the elf loading code in each device driver a slim rproc driver has been created. This driver is designed to be used by other device drivers such as fdma, or demux whose IP is based around a slim core. The device driver can call slim_rproc_alloc() to allocate a slim rproc and slim_rproc_put() when finished. This driver takes care of ioremapping the slim registers (dmem, imem, slimcore, peripherals), whose offsets and sizes can change between IP's. It also obtains and enables any clocks used by the device. This approach avoids having a double mapping of the registers as slim_rproc does not register its own platform device. It also maps well to device tree abstraction as it allows us to have one dt node for the whole device. All of the generic rproc elf loading code can be reused, and we provide start() stop() hooks to start and stop the slim core once the firmware has been loaded. This has been tested successfully with fdma driver. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:06 +08:00
config ST_SLIM_REMOTEPROC
tristate
remoteproc: Update Kconfig setup to 'depends on REMOTEPROC' Make REMOTEPROC core a selectable kconfig option, and update remoteproc client drivers to 'depends on' the core. This avoids some nasty Kconfig recursive dependency issues. Also when using menuconfig client drivers will be hidden until the core has been enabled. Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:08 +08:00
depends on REMOTEPROC
endif # REMOTEPROC
remoteproc: st_slim_rproc: add a slimcore rproc driver slim core is used as a basis for many IPs in the STi chipsets such as fdma and demux. To avoid duplicating the elf loading code in each device driver a slim rproc driver has been created. This driver is designed to be used by other device drivers such as fdma, or demux whose IP is based around a slim core. The device driver can call slim_rproc_alloc() to allocate a slim rproc and slim_rproc_put() when finished. This driver takes care of ioremapping the slim registers (dmem, imem, slimcore, peripherals), whose offsets and sizes can change between IP's. It also obtains and enables any clocks used by the device. This approach avoids having a double mapping of the registers as slim_rproc does not register its own platform device. It also maps well to device tree abstraction as it allows us to have one dt node for the whole device. All of the generic rproc elf loading code can be reused, and we provide start() stop() hooks to start and stop the slim core once the firmware has been loaded. This has been tested successfully with fdma driver. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-10-18 17:39:06 +08:00
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 19:01:59 +08:00
endmenu