summaryrefslogtreecommitdiff
path: root/drivers/remoteproc/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2018-10-06remoteproc: qcom: Introduce Non-PAS ADSP PIL driverRohit kumar1-0/+1
This adds Non PAS ADSP PIL driver for Qualcomm Technologies Inc SoCs. Added initial support for SDM845 with ADSP bootup and shutdown operation handled from Application Processor SubSystem(APSS). Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Rohit kumar <rohitkr@codeaurora.org> [bjorn: Renamed driver and Kconfig from qcom_adsp_pil to qcom_q6v5_adsp] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2018-09-26remoteproc: qcom: Rename Hexagon v5 modem driverBjorn Andersson1-1/+1
The qcom_q6v5_pil implements support for the self-authenticating modem subsystem. With the introduction of other q6v5 based non-TZ based remoteproc driver the current name is cause for confusion, so rename it to be more specific. No functional change. Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2018-09-26remoteproc: qcom: Rename Hexagon v5 PAS driverBjorn Andersson1-1/+1
The Hexagon v5 ADSP driver is used for more than only the ADSP and there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to qcom_q6v5_pas in order to better suite this. Cc: Rohit kumar <rohitkr@codeaurora.org> Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2018-06-19remoteproc: qcom: Introduce Hexagon V5 based WCSS driverSricharan R1-0/+1
IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan (Lithium) IP. An mdt type single image format is used for the firmware. So the mdt_load function can be directly used to load the firmware. Also add the relevant resets required for this core. Acked-by: Rob Herring <robh@kernel.org> (bindings) Signed-off-by: Sricharan R <sricharan@codeaurora.org> [bjorn: Rewrote as a separate driver, intead of extending q6v5_pil.c] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2018-06-19remoteproc: q6v5: Extract common resource handlingBjorn Andersson1-0/+1
Shared between all Hexagon V5 based remoteprocs is the handling of the 5 interrupts and the SMP2P stop request, so break this out into a separate function in order to allow these drivers to be cleaned up. Reviewed-by: Rohit kumar <rohitkr@codeaurora.org> Tested-by: Rohit kumar <rohitkr@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2018-02-13remoteproc: qcom: Introduce sysmonBjorn Andersson1-0/+1
The sysmon client communicates either via a dedicated SMD/GLINK channel or via QMI encoded messages over IPCROUTER with remote processors in order to perform graceful shutdown and inform about other remote processors shutting down. Acked-By: Chris Lew <clew@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-31remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driverOleksij Rempel1-0/+1
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 Anna1-0/+1
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 Andersson1-1/+0
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 Andersson1-0/+1
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-10remoteproc/ste: Delete unused driverJean Delvare1-1/+0
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-17Merge branch 'topic/st_fdma' of ↵Bjorn Andersson1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma into rproc-next
2016-11-16remoteproc: Introduce Qualcomm ADSP PILBjorn Andersson1-0/+1
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-15remoteproc: qcom_wcnss: Fix circular module dependencyBjorn Andersson1-2/+3
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-11-01remoteproc: Add a sysfs interface for firmware and stateMatt Redfearn1-0/+1
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 Griffin1-0/+1
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 Andersson1-0/+2
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 Andersson1-0/+2
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-30remoteproc: Supply controller driver for ST's Remote ProcessorsLee Jones1-0/+1
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 Gerlach1-0/+1
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 Tivy1-0/+1
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ændeland1-0/+1
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ændeland1-0/+1
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-Cohen1-1/+1
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-09remoteproc/omap: add a remoteproc driver for OMAP4Ohad Ben-Cohen1-0/+1
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-09remoteproc: create rpmsg virtio deviceOhad Ben-Cohen1-0/+1
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-09remoteproc: add debugfs entriesOhad Ben-Cohen1-0/+1
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-09remoteproc: add framework for controlling remote processorsOhad Ben-Cohen1-0/+6
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>