kevin/linux
1
Fork 0
Code
30338cf09f
linux/drivers/remoteproc/Kconfig

29 lines
777 B
Plaintext
Raw Normal View History

remoteproc: depend on EXPERIMENTAL Remoteproc is still under development and as it gets traction we definitely expect to do some changes in the binary format (most probably only in the resource table, e.g. the upcoming move to TLV-based entries). Active testing and use of remoteproc is most welcome, but we don't want users to expect backward binary compatibility with the preliminary images we have today. Therefore mark remoteproc as EXPERIMENTAL, and explicitly inform the user about this when a new remote processor is registered. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Rob Clark <rob@ti.com> Cc: Mark Grosen <mgrosen@ti.com> Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
2011-12-21 02:25:43 -07:00
menu "Remoteproc drivers (EXPERIMENTAL)"
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 07:52:46 -07:00
# REMOTEPROC gets selected by whoever wants it
config REMOTEPROC
tristate
remoteproc: depend on EXPERIMENTAL Remoteproc is still under development and as it gets traction we definitely expect to do some changes in the binary format (most probably only in the resource table, e.g. the upcoming move to TLV-based entries). Active testing and use of remoteproc is most welcome, but we don't want users to expect backward binary compatibility with the preliminary images we have today. Therefore mark remoteproc as EXPERIMENTAL, and explicitly inform the user about this when a new remote processor is registered. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Rob Clark <rob@ti.com> Cc: Mark Grosen <mgrosen@ti.com> Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
2011-12-21 02:25:43 -07:00
depends on EXPERIMENTAL
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 09:53:35 -07:00
config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
depends on ARCH_OMAP4
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 09:53:35 -07:00
select REMOTEPROC
select OMAP_MBOX_FWK
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
endmenu
Copy Permalink