summaryrefslogtreecommitdiff
path: root/include/linux/remoteproc.h
AgeCommit message (Collapse)Author
2017-09-01remoteproc: Introduce rproc handle accessor for childrenBjorn Andersson
In certain circumstances rpmsg devices needs to acquire a handle to the ancestor remoteproc instance, e.g. to invoke rproc_report_crash() when a fatal error is detected. Introduce an interface that walks the device tree in search for a remoteproc instance and return this. Tested-by: Suman Anna <s-anna@ti.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-01-30remoteproc: Drop firmware_loading_completeSarangdhar Joshi
firmware_loading_complete is used to synchronize operations on rproc while asynchronous firmware loading is in progress. However, rproc_boot() no longer waits on firmware_loading_complete. Hence drop this completion variable altogether and handle the race between rproc_del() and rproc_boot() using new state RPROC_DELETED. The request_firmware_nowait() will hold the reference to rproc device by using a get_device()/put_device(), so the rproc struct will remain valid even when we return from rproc_del() before the asynchronous call to rproc_fw_config_virtio() completes. CC: Loic Pallardy <loic.pallardy@st.com> CC: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-01-30remoteproc: Add RPROC_DELETED stateSarangdhar Joshi
Add new state RPROC_DELETED to handle synchronization between rproc_del() and other operations on rproc. This state represents the rproc device that has been "deleted". CC: Loic Pallardy <loic.pallardy@st.com> CC: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-12-30Revert "remoteproc: Merge table_ptr and cached_table pointers"Bjorn Andersson
Following any fw_rsc_vdev entries in the resource table are two variable length arrays, the first one reference vring resources and the second one is the virtio config space. The virtio config space is used by virtio to communicate status and configuration changes and must as such be shared with the remote. The reverted commit incorrectly made any changes to the virtio config space only affect the local copy, in an attempt to allowing memory protection of the shared resource table. This reverts commit cda8529346935fc86f476999ac4fbfe4e17abf11. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-11-14remoteproc: Merge table_ptr and cached_table pointersBjorn Andersson
As all vdev resources are allocated before we boot the remote processor we no longer need to support modifying the resource table while the remote is running. This saves us from the table_ptr dance, but more importantly allow the remote processor to enable security lock down of the loaded table memory region. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-11-14remoteproc: Decouple vdev resources and devicesBjorn Andersson
Represent the virtio device part of the vdev resources as remoteproc subdevices to finalize the decoupling of the virtio resource and device handling. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-11-14remoteproc: Assign kref to rproc_vdevBjorn Andersson
No functional change Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-11-09remoteproc: Introduce subdevicesBjorn Andersson
A subdevice is an abstract entity that can be used to tie actions to the booting and shutting down of a remote processor. The subdevice object is expected to be embedded in concrete implementations, allowing for a variety of use cases to be implemented. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-10-18remoteproc: Keep local copy of firmware nameMatt Redfearn
Storage of the firmware name was inconsistent, either storing a pointer to a name stored with unknown ownership, or a variable length tacked onto the end of the struct proc allocated in rproc_alloc. In preparation for allowing the firmware of an already allocated struct rproc to be changed, instead always keep a locally maintained copy of the firmware name. Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-10-02remoteproc: Split driver and consumer dereferencingBjorn Andersson
In order to be able to lock a rproc driver implementations only when used by a client, we must differ between the dereference operation of a client and the implementation itself. This patch brings no functional change. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-09-06remoteproc: core: transform struct fw_rsc_vdev_vring reserved field in paLoic PALLARDY
In current implementation, struct fw_rsc_vdev_vring which describes vring resource in firmware resource table owns only device address, because it assumes that host is responsible of vring allocation and only device address is needed by coprocessor. But if vrings need to be fixed in system memory map for any reasons (security, SoC charactieristics...), physical address is needed exatly identified the memory chunck by host. For that let's transform reserved field of struct fw_rsc_vdev_vring to pa (physical address). Signed-off-by: Loic Pallardy <loic.pallardy@st.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-09-06remoteproc: Modify FW_RSC_ADDR_ANY definitionLoic PALLARDY
Replace 0xFFFFFFFFFFFFFFFF by -1 to fit any type. Signed-off-by: Loic Pallardy <loic.pallardy@st.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-17remoteproc: Move handling of cached table to boot/shutdownBjorn Andersson
As we moved the vdev handling to the main boot/shutdown code path we can further simplify the resource table handling by moving the parsing spet to boot as well. The lifespan of the resource table is changed to live from rproc_boot() to rproc_shutdown(). Cc: Lee Jones <lee.jones@linaro.org> Cc: Loic Pallardy <loic.pallardy@st.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-17remoteproc: Introduce auto-boot flagBjorn Andersson
Introduce an "auto-boot" flag on rprocs to make it possible to flag remote processors without vdevs to automatically boot once the firmware is found. Preserve previous behavior of the wkup_m3 processor being explicitly booted by a consumer. Cc: Lee Jones <lee.jones@linaro.org> Cc: Loic Pallardy <loic.pallardy@st.com> Cc: Suman Anna <s-anna@ti.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-12remoteproc: align code with open parenthesisAnna, Suman
This patch fixes the existing alignment checkpatch check warnings of the type "Alignment should match open parenthesis" in the remoteproc core source files. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-08-12remoteproc: fix bare unsigned type usageAnna, Suman
While there is nothing wrong with defining an unsigned integer variable or argument using the bare unsigned type, it is better to use the checkpatch preferred 'unsigned int' type. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2016-05-12remoteproc: Add additional crash reasonsBjorn Andersson
The Qualcomm WCNSS can crash by watchdog or a fatal software error. Add these types to the list of remoteproc crash reasons. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2015-06-17remoteproc: add a rproc ops for performing address translationSuman Anna
The rproc_da_to_va API is currently used to perform any device to kernel address translations to meet the different needs of the remoteproc core/drivers (eg: loading). The functionality is achieved within the remoteproc core, and is limited only for carveouts allocated within the core. A new rproc ops, da_to_va, is added to provide flexibility to platform implementations to perform the address translation themselves when the above conditions cannot be met by the implementations. The rproc_da_to_va() API is extended to invoke this ops if present, and fallback to regular processing if the platform implementation cannot provide the translation. This will allow any remoteproc implementations to translate addresses for dedicated memories like internal memories. While at this, also update the rproc_da_to_va() documentation since it is an exported function. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2015-06-16remoteproc: introduce rproc_get_by_phandle APIDave Gerlach
Allow users of remoteproc the ability to get a handle to an rproc by passing a phandle supplied in the user's device tree node. This is useful in situations that require manual booting of the rproc. This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc: remove the get_by_name/put API") for the ref counting but is modified to use a simple list and locking mechanism and has rproc_get_by_name replaced with an rproc_get_by_phandle API. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> [fix order of Signed-off-by tags] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2015-03-12remoteproc: add IOMMU hardware capability flagSuman Anna
The remoteproc framework currently relies on iommu_present() on the bus the device is on, to perform MMU management. However, this logic doesn't scale for multi-arch, especially for processors that do not have an IOMMU. Replace this logic instead by using a h/w capability flag for the presence of IOMMU in the rproc structure. This issue is seen on OMAP platforms when trying to add a remoteproc driver for a small Cortex M3 called the WkupM3 used for suspend / resume management on TI AM335/AM437x SoCs. This processor does not have an MMU. Same is the case with another processor subsystem PRU-ICSS on AM335/AM437x. All these are platform devices, and the current iommu_present check will not scale for the same kernel image to support OMAP4/OMAP5 and AM335/AM437x. The existing platform implementation drivers - OMAP remoteproc, STE Modem remoteproc and DA8xx remoteproc, are updated as well to properly configure the newly added rproc field. Cc: Robert Tivy <rtivy@ti.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Suman Anna <s-anna@ti.com> [small change in the commit title and in a single comment] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-04-07remoteproc: support virtio config space.Sjur Brændeland
Support virtio configuration space and device status. The virtio device can now access the resource table in shared memory. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Acked-by: Ido Yariv <ido@wizery.com> [rebase and style changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2013-04-07remoteproc: perserve resource table dataOhad Ben-Cohen
Copy resource table from first to second firmware loading. After firmware is loaded to memory, update the vdevs resource pointer to the resource table kept in device memory. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Acked-by: Ido Yariv <ido@wizery.com> [rebase, terminology and style changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-18remtoteproc: maintain max notifyidSjur Brændeland
Some of the rproc drivers (STE modem specifically) needs to know the range of the notification IDs used for notifying the device. Maintain a variable in struct rproc holding the largest allocated notification id, so low-level rproc drivers could access it. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> [ohad: rebase, slightly edit commit log] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-18remoteproc: create a 'recovery' debugfs entryFernando Guzman Lugo
Add a 'recovery' debugfs entry to dynamically disable/enable recovery at runtime. This is useful when one is trying to debug an rproc crash; without it, a recovery will immediately take place, making it harder to debug the crash. Contributions from Subramaniam Chanderashekarapuram. Examples: - disabling recovery: $ echo disabled > <debugfs>/remoteproc/remoteproc0/recovery - in case you want to recover a crash, but keep recovery disabled (useful in debugging sessions when you expect additional crashes you want to debug): $ echo recover > <debugfs>/remoteproc/remoteproc0/recovery - enabling recovery: $ echo enabled > <debugfs>/remoteproc/remoteproc0/recovery Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> [ohad: some white space, commentary and commit log changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-18remoteproc: add actual recovery implementationFernando Guzman Lugo
Add rproc_trigger_recovery() which takes care of the recovery itself, by removing, and re-adding, all of the remoteproc's virtio devices. This resets all virtio users of the remote processor, during which the remote processor is powered off and on again. Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> [ohad: introduce rproc_add_virtio_devices to avoid 1.copying code 2.anomaly] [ohad: some white space, naming and commit log changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-18remoteproc: add rproc_report_crash function to notify rproc crashesFernando Guzman Lugo
Allow low-level remoteproc drivers to report rproc crashes by exporting a new rproc_report_crash() function (invoking this from non-rproc drivers is probably wrong, and should be carefully scrutinized if ever needed). rproc_report_crash() can be called from any context; it offloads the tasks of handling the crash to a separate thread. Handling the crash from a separate thread is helpful because: - Ability to call invoke rproc_report_crash() from atomic context, due to the fact that many crashes trigger an interrupt, so this function can be called directly from ISR context. - Avoiding deadlocks which could happen if rproc_report_crash() is called from a function which indirectly holds the rproc lock. Handling the crash might involve: - Remoteproc register dump - Remoteproc stack dump - Remoteproc core dump - Saving Remoteproc traces so they can be read after the crash - Reseting the remoteproc in order to make it functional again (hard recovery) Right now, we only print the crash type which was detected, and only the mmufault type is supported. Remoteproc low-level drivers can add more types when needed. Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> [ohad: some commentary, white space and commit log changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-15remoteproc: Support custom firmware handlersSjur Brændeland
Firmware handling is made customizable. This is done by creating a separate ops structure for the firmware functions that depends on a particular firmware format (such as ELF). The ELF functions are default used unless the HW driver explicitly injects another firmware handler by updating rproc->fw_ops. The function rproc_da_to_va() is exported, as custom firmware handlers may need to use this function. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> [ohad: namespace fixes, whitespace fixes, style fixes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06remoteproc: adopt the driver core's alloc/add/del/put namingOhad Ben-Cohen
To make remoteproc's API more intuitive for developers, we adopt the driver core's naming, i.e. alloc -> add -> del -> put. We'll also add register/unregister when their first user shows up. Otherwise - there's no functional change here. Suggested by Russell King <linux@arm.linux.org.uk>. Cc: Russell King <linux@arm.linux.org.uk> Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Cc: Sjur Brændeland <sjur.brandeland@stericsson.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06remoteproc: remove the get_by_name/put APIOhad Ben-Cohen
Remove rproc_get_by_name() and rproc_put(), and the associated remoteproc infrastructure that supports it (i.e. klist and friends), because: 1. No one uses them 2. Using them is highly discouraged, and any potential user will be deeply scrutinized and encouraged to move. If a user, that absolutely can't live with the direct boot/shutdown model, does show up one day, then bringing this functionality back is going to be trivial. At this point though, keeping this functionality around is way too much of a maintenance burden. Cc: Sjur Brændeland <sjur.brandeland@stericsson.com> Cc: Loic Pallardy <loic.pallardy@stericsson.com> Cc: Ludovic BARRE <ludovic.barre@stericsson.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Cc: Suman Anna <s-anna@ti.com> Cc: Mark Grosen <mgrosen@ti.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06remoteproc: remove the now-redundant krefOhad Ben-Cohen
Now that every rproc instance contains a device, we don't need a kref anymore to maintain the refcount of the rproc instances: that's what device are good with! This patch removes the now-redundant kref, and switches to {get, put}_device instead of kref_{get, put}. We also don't need the kref's release function anymore, and instead, we just utilize the class's release handler (which is now responsible for all memory de-allocations). Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06remoteproc: maintain a generic child device for each rprocOhad Ben-Cohen
For each registered rproc, maintain a generic remoteproc device whose parent is the low level platform-specific device (commonly a pdev, but it may certainly be any other type of device too). With this in hand, the resulting device hierarchy might then look like: omap-rproc.0 | - remoteproc0 <---- new ! | - virtio0 | - virtio1 | - rpmsg0 | - rpmsg1 | - rpmsg2 Where: - omap-rproc.0 is the low level device that's bound to the driver which invokes rproc_register() - remoteproc0 is the result of this patch, and will be added by the remoteproc framework when rproc_register() is invoked - virtio0 and virtio1 are vdevs that are registered by remoteproc when it realizes that they are supported by the firmware of the physical remote processor represented by omap-rproc.0 - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg channels, and are registerd by the rpmsg bus when it gets notified about their existence Technically, this patch: - changes 'struct rproc' to contain this generic remoteproc.x device - creates a new "remoteproc" type, to which this new generic remoteproc.x device belong to. - adds a super simple enumeration method for the indices of the remoteproc.x devices - updates all dev_* messaging to use the generic remoteproc.x device instead of the low level platform-specific device - updates all dma_* allocations to use the parent of remoteproc.x (where the platform-specific memory pools, most commonly CMA, are to be found) Adding this generic device has several merits: - we can now add remoteproc runtime PM support simply by hooking onto the new "remoteproc" type - all remoteproc log messages will now carry a common name prefix instead of having a platform-specific one - having a device as part of the rproc struct makes it possible to simplify refcounting (see subsequent patch) Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and discussing these ideas in one of the remoteproc review threads and to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out with the (upcoming) runtime PM support for remoteproc. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-03-06remoteproc: remove the hardcoded vring alignmentOhad Ben-Cohen
Remove the hardcoded vring alignment of 4096 bytes, and instead utilize tha vring alignment as specified in the resource table. This is needed for remote processors that have rigid memory requirement, and which have found the alignment of 4096 bytes to be excessively big. 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-06remoteproc: remove the single rpmsg vdev limitationOhad Ben-Cohen
Now that the resource table supports publishing a virtio device in a single resource entry, firmware images can start supporting more than a single vdev. This patch removes the single vdev limitation of the remoteproc framework so multi-vdev firmwares can be leveraged: VDEV resource entries are parsed when the rproc is registered, and as a result their vrings are set up and the virtio devices are registered (and they go away when the rproc goes away). Moreover, we no longer only support VIRTIO_ID_RPMSG vdevs; any virtio device type goes now. As a result, there's no more any rpmsg-specific APIs or code in remoteproc: it all becomes generic virtio handling. 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-06remoteproc: resource table overhaulOhad Ben-Cohen
The resource table is an array of 'struct fw_resource' members, where each resource entry is expressed as a single member of that array. This approach got us this far, but it has a few drawbacks: 1. Different resource entries end up overloading the same members of 'struct fw_resource' with different meanings. The resulting code is error prone and hard to read and maintain. 2. It's impossible to extend 'struct fw_resource' without breaking the existing firmware images (and we already want to: we can't introduce the new virito device resource entry with the current scheme). 3. It doesn't scale: 'struct fw_resource' must be as big as the largest resource entry type. As a result, smaller resource entries end up utilizing only small part of it. This is fixed by defining a dedicated structure for every resource type, and then converting the resource table to a list of type-value members. Instead of a rigid array of homogeneous structs, the resource table is turned into a collection of heterogeneous structures. This way: 1. Resource entries consume exactly the amount of bytes they need. 2. It's easy to extend: just create a new resource entry structure, and assign it a new type. 3. The code is easier to read and maintain: the structures' members names are meaningful. While we're at it, this patch has several other resource table changes: 1. The resource table gains a simple header which contains the number of entries in the table and their offsets within the table. This makes the parsing code simpler and easier to read. 2. A version member is added to the resource table. Should we change the format again, we'll bump up this version to prevent breakage with existing firmware images. 3. The VRING and VIRTIO_DEV resource entries are combined to a single VDEV entry. This paves the way to supporting multiple VDEV entries. 4. Since we don't really support 64-bit rprocs yet, convert two stray u64 members to u32. 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-22remoteproc: s/big switch/lookup table/Ohad Ben-Cohen
A lookup table would be easier to extend, and the resulting code is a bit cleaner. Reported-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-02-08remoteproc: remove unused resource typeOhad Ben-Cohen
RSC_VIRTIO_CFG isn't being used, so remove it. Originally it was introduced to overcome a resource table limitation that prevented describing a virtio device in a single resource table entry. The plan though is to describe resource table entries in a TLV fashion, where each entry will consume the amount of space it requires, so the original limitation is anyway temporary. Reported-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
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>