summaryrefslogtreecommitdiff
path: root/drivers/remoteproc/Makefile
AgeCommit message (Collapse)Author
2017-08-30remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driverOleksij Rempel
Provide a basic driver to control Cortex M4 co-processor found on NXP i.MX7D and i.MX6SX. Currently it is able to resolve addresses between M4 and main CPU, start and stop the co-processor. Other functionality is not provided or test. This driver was tested on NXP i.MX7D and expected to work on i.MX6SX as well. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-06-26remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPsSuman Anna
The Texas Instrument's Keystone 2 family of SoCs has 1 or more TMS320C66x DSP Core Subsystems (C66x CorePacs). Each subsystem has a C66x Fixed/Floating-Point DSP Core, with 32KB of L1P and L1D SRAMs, that can be configured and partitioned as either RAM and/or Cache, and 1 MB of L2 SRAM. The CorePac also includes an Internal DMA (IDMA), External Memory Controller (EMC), Extended Memory Controller (XMC) with a Memory Protection and Address Extension (MPAX) unit, a Bandwidth Management (BWM) unit, an Interrupt Controller (INTC) and a Powerdown Controller (PDC). A new remoteproc module is added to perform the device management of these DSP devices. The driver expects the firmware names to be of the form "keystone-dsp<X>-fw", where X is the corresponding DSP number, and uses the standard remoteproc core ELF loader. The support is limited to images only using the DSP internal memories at the moment. This remoteproc driver is also designed to work with virtio, and uses the IPC Generation registers for performing the virtio signalling and getting notified of exceptions. The driver currently supports the 66AK2H/66AK2K, 66AK2L and 66AK2E SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Sam Nelson <sam.nelson@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-02-06remoteproc: Move qcom_mdt_loader into drivers/soc/qcomBjorn Andersson
With the remoteproc parts cleaned out of the MDT loader we can move it to drivers/soc/qcom. Acked-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-02-06remoteproc: qcom: Extract non-mdt related helperBjorn Andersson
In preparation for moving the mdt loader out of remoteproc let's move the somewhat unrelated resource table dummy helper to a Qualcomm "common" file. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-12-09remoteproc/ste: Delete unused driverJean Delvare
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-11-16Merge branch 'topic/st_fdma' of ↵Bjorn Andersson
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma into rproc-next
2016-11-15remoteproc: Introduce Qualcomm ADSP PILBjorn Andersson
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-14remoteproc: qcom_wcnss: Fix circular module dependencyBjorn Andersson
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: aed361adca9f ("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-10-31remoteproc: Add a sysfs interface for firmware and stateMatt Redfearn
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-18remoteproc: st_slim_rproc: add a slimcore rproc driverPeter Griffin
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-08-18remoteproc: qcom: Introduce WCNSS peripheral image loaderBjorn Andersson
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-07-13remoteproc: qcom: Driver for the self-authenticating Hexagon v5Bjorn Andersson
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-01-29remoteproc: Supply controller driver for ST's Remote ProcessorsLee Jones
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>
2015-06-17remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3Dave Gerlach
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>
2013-04-15remoteproc/davinci: add a remoteproc driver for OMAP-L13x DSPRobert Tivy
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>
2012-09-22remoteproc: Add STE modem driverSjur Brændeland
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-07-15remoteproc: Move Elf related functions to separate fileSjur Brændeland
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-03-06remoteproc: remoteproc_rpmsg -> remoteproc_virtioOhad Ben-Cohen
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-02-08remoteproc/omap: add a remoteproc driver for OMAP4Ohad Ben-Cohen
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-08remoteproc: create rpmsg virtio deviceOhad Ben-Cohen
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-08remoteproc: add debugfs entriesOhad Ben-Cohen
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-08remoteproc: add framework for controlling remote processorsOhad Ben-Cohen
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>