forked from Minki/linux
489d129a2f
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>
30 lines
784 B
Plaintext
30 lines
784 B
Plaintext
menu "Remoteproc drivers (EXPERIMENTAL)"
|
|
|
|
# REMOTEPROC gets selected by whoever wants it
|
|
config REMOTEPROC
|
|
tristate
|
|
depends on EXPERIMENTAL
|
|
|
|
config OMAP_REMOTEPROC
|
|
tristate "OMAP remoteproc support"
|
|
depends on ARCH_OMAP4
|
|
select OMAP_IOMMU
|
|
select REMOTEPROC
|
|
select OMAP_MBOX_FWK
|
|
select RPMSG
|
|
default m
|
|
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.
|
|
|
|
endmenu
|