Commit Graph

18 Commits

Author SHA1 Message Date
Jean Delvare
394c62000a remoteproc/ste: Delete unused driver
Back in July 2014 I asked around what was the intended target
platform for the STE Modem remoteproc driver, so that I could add the
proper hardware dependency to its config option. The answer I got was
that there was no known publicly available hardware needing it and it
was unlikely that there ever would.

So I think it's time to delete this driver to lower the maintenance
burden.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Suman Anna <s-anna@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-12-09 16:16:54 -08:00
Bjorn Andersson
f88536f1a5 Merge branch 'topic/st_fdma' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma into rproc-next 2016-11-16 22:19:47 -08:00
Bjorn Andersson
b9e718e950 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-11-15 18:44:53 -08:00
Bjorn Andersson
6de1a507c4 remoteproc: qcom_wcnss: Fix circular module dependency
The tie between the main WCNSS driver and the IRIS driver causes a
circular dependency between the two modules. Neither part makes sense to
have on their own so lets merge them into one module.

For the sake of picking up the clock and regulator resources described
in the iris of_node we need an associated struct device. But, to keep
the size of the patch down we continue to represent the IRIS part as its
own platform_driver, within the same module, rather than setting up a
dummy device.

Fixes: aed361adca ("remoteproc: qcom: Introduce WCNSS peripheral image loader")
Reported-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-11-14 21:52:19 -08:00
Matt Redfearn
2aefbef041 remoteproc: Add a sysfs interface for firmware and state
This patch adds a sysfs interface to rproc allowing the firmware name
and processor state to be changed dynamically.

State was previously available in debugfs, and is replicated here. The
firmware file allows retrieval of the running firmware name, and a new
one to be specified at run time, so long as the remote processor has
been stopped.

Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-10-31 17:24:46 -07:00
Peter Griffin
bb6869b214 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 20:12:05 +05:30
Bjorn Andersson
aed361adca 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-18 12:48:46 -07:00
Bjorn Andersson
051fb70fd4 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-07-13 13:38:15 -07:00
Lee Jones
63edb0310a 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-29 17:26:49 -08:00
Dave Gerlach
a01bc0d5f5 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-06-17 09:58:08 +03:00
Robert Tivy
13be5432d8 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-15 09:23:40 +03:00
Sjur Brændeland
ec4d02d918 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-22 16:35:13 +03:00
Sjur Brændeland
72854fb042 remoteproc: Move Elf related functions to separate file
Prepare for introduction of custom firmware loaders by
moving all ELF related handling into a separate file.

The functions: rproc_find_rsc_table(), rproc_fw_sanity_check(),
rproc_find_rsc_table() and rproc_get_boot_addr() are moved
to the new file remoteproc_elf_loader.c. The function
rproc_da_to_va() is made non-static and is declared in
remoteproc_internal.h

No functional changes are introduced in this patch.

Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
[ohad: rebase, fix kerneldoc, put prototypes in remoteproc_internal.h]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-15 11:25:27 +03:00
Ohad Ben-Cohen
04a9016e82 remoteproc: remoteproc_rpmsg -> remoteproc_virtio
At this point remoteproc can only register a single VIRTIO_ID_RPMSG virtio
device.

This limitation is going away soon: remoteproc is getting support for
registering any number of virtio devices and of any type (as
published by the firmware of the remote processor).

Rename remoteproc_rpmsg.c to remoteproc_virtio.c in preparation of
this generalization work.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Iliyan Malchev <malchev@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: John Williams <john.williams@petalogix.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
Cc: Anna Suman <s-anna@ti.com>
Cc: Clark Rob <rob@ti.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Saravana Kannan <skannan@codeaurora.org>
Cc: David Brown <davidb@codeaurora.org>
Cc: Kieran Bingham <kieranbingham@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
2012-03-06 19:13:45 +02:00
Ohad Ben-Cohen
34ed5a33b1 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>
2012-02-08 22:53:47 +02:00
Ohad Ben-Cohen
ac8954a413 remoteproc: create rpmsg virtio device
Create an rpmsg virtio device to allow message-based communication
with the remote processor (but only if supported by its firmware).

There are several advantages to provide this functionality at
the remoteproc-level:
- to support it, platforms only have to provide their own ->kick()
  handler; no need to duplicate the rest of the code.
- the virtio device is created only when the remote processor is
  registered and ready to go. No need to depend on initcall magic.
  moreover, we only add the virtio device if the firmware really
  supports it, and only after we know the supported virtio device features.
- correct device model hierarchy can be set, and that is useful
  for natural power management and DMA API behavior.
- when the remote processor crashes (or removed) we only need
  to remove the virtio device, and the driver core will take care of
  the rest. No need to implement any out-of-bound notifiers.
- we can now easily bind the virtio device to its rproc handle, and
  this way we don't need any name-based remoteproc ->get() API.

Currently we only support creating a single rpmsg virtio device per
remote processor, but later this is going to be extended to support
creating numerous virtio devices of other types too (block, net,
console...).

Designed with Brian Swetland <swetland@google.com>.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
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>
2012-02-08 22:53:39 +02:00
Ohad Ben-Cohen
6391a70682 remoteproc: add debugfs entries
Expose several remote processor properties (name, state, trace buffer)
that are helpful for debugging.

This part is extracted to a separate patch just to keep the review load
down.

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>
2012-02-08 22:53:30 +02:00
Ohad Ben-Cohen
400e64df6b 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>
2012-02-08 22:52:56 +02:00