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

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>

show more ...

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 <sju

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>

show more ...

remoteproc: fix missing CONFIG_FW_LOADER configurations

Remoteproc requires user space firmware loading support, so
let's select FW_LOADER explicitly to avoid painful misconfigurations

remoteproc: fix missing CONFIG_FW_LOADER configurations

Remoteproc requires user space firmware loading support, so
let's select FW_LOADER explicitly to avoid painful misconfigurations
(which only show up in runtime).

Cc: stable <stable@vger.kernel.org>
Reported-by: Mark Grosen <mgrosen@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

show more ...

remoteproc/omap: fix randconfig unmet direct dependencies

OMAP_REMOTEPROC selects REMOTEPROC and RPMSG, both of which depend
on EXPERIMENTAL, so let's have OMAP_REMOTEPROC depend on EXPE

remoteproc/omap: fix randconfig unmet direct dependencies

OMAP_REMOTEPROC selects REMOTEPROC and RPMSG, both of which depend
on EXPERIMENTAL, so let's have OMAP_REMOTEPROC depend on EXPERIMENTAL
too, in order to avoid the below randconfig warnings.

warning: (OMAP_REMOTEPROC) selects REMOTEPROC which has unmet direct dependencies (EXPERIMENTAL)
warning: (OMAP_REMOTEPROC) selects RPMSG which has unmet direct dependencies (EXPERIMENTAL)

Cc: stable <stable@vger.kernel.org>
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

show more ...

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' (

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>

show more ...

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 t

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>

show more ...

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.c

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>

show more ...

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

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>

show more ...

remoteproc: add framework for controlling remote processors

Modern SoCs typically employ a central symmetric multiprocessing (SMP)
application processor running Linux, with several other

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>

show more ...