6582db31eb1e89ef6b08242a16a781849dada810 |
|
10-Jun-2012 |
Sjur Brændeland <sjur.brandeland@stericsson.com> |
remoteproc: fix missing fault indication in error-path commit 30338cf09f82523d8747670f7363cc8af347c79f upstream. If rproc_find_rsc_table() fails, rproc_fw_boot() must set return-value before jumping to clean_up label. Otherwise no error value is returned. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
d186a40464141d201f93ee87e0be6f0d2ef029d6 |
|
10-Jun-2012 |
Sjur Brændeland <sjur.brandeland@stericsson.com> |
remoteproc: fix print format warnings commit e981f6d41acda2ae8c05e60feb2cb97772b4a6e6 upstream. Fix compile warnings from GCC 4.6.1 when printing values of type size_t. drivers/remoteproc/remoteproc_core.c:251:6: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘size_t’ [-Wformat] drivers/remoteproc/remoteproc_core.c:938:9: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘size_t’ [-Wformat] drivers/remoteproc/remoteproc_core.c:1023:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat] Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
6fd98c124c66b0b0001bc4217392d891b1ad4a02 |
|
13-May-2012 |
Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com> |
remoteproc: fix off-by-one bug in __rproc_free_vrings Fix a nasty off-by-one bug in __rproc_free_vrings which resulted in a memory leak and (for some platforms) failures to reload the remote processor. Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com> [ohad@wizery.com: reword commit log, stick with the for loop] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
1e3e2c7c46b2e6e90f3a26ba9be6326c00ca31e4 |
|
13-Feb-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: cleanup resource table parsing paths rproc_handle_resources() looks for the resource table and then invokes a resource handler function which it took as a parameter. This works, but it's a bit unintuitive to follow. Instead of passing around function pointers, this patch changes rproc_handle_resource() to just find and return the resource table, and then the calling sites of rproc_handle_resource() invoke their resource handlers directly. 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>
|
63140e0ed2e69bdafe62bc19fd6551d9213f80a7 |
|
29-Feb-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: remove the hardcoded vring alignment 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>
|
7a186941626d19f668b08108db158379b32e6e02 |
|
13-Feb-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: remove the single rpmsg vdev limitation 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>
|
fd2c15ec1dd3c2fdfc6ff03bb9644da9d530e3b9 |
|
01-Feb-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: resource table overhaul 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>
|
40b78b2cc75315a76ab1863be744d8580030f924 |
|
13-Feb-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: make sure we're parsing a 32bit firmware Make sure we're parsing a 32bit image, since we only support the ELF32 binary format at this point. This should prevent unexpected behavior with non 32bit binaries. 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>
|
e12bc14b88d44e5c1456dccb59ff58103f6c6edc |
|
31-Jan-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: s/big switch/lookup table/ 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>
|
cf59d3e9a715fd2b6ff96e4a3a130fceded09a64 |
|
31-Jan-2012 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: bail out if firmware has different endianess At this point we don't support remote processors that have a different endianess than the host. Look out for these unsupported scenarios, and bail out if encountered. Reported-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Mark Grosen <mgrosen@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca>
|
489d129a2f7abd04054fad44e589989f3fa7fd7c |
|
21-Dec-2011 |
Ohad Ben-Cohen <ohad@wizery.com> |
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>
|
9bc91231178d8ca3dd07f90493941bdb17eef86d |
|
13-Dec-2011 |
Ohad Ben-Cohen <ohad@wizery.com> |
remoteproc: look for truncated firmware images Make sure firmware isn't truncated before accessing its data. Reported-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
7d2d3956fbc1aa9a3ccdc9389b88505232764d4f |
|
13-Dec-2011 |
Mark Grosen <mgrosen@ti.com> |
remoteproc: avoid registering a virtio device if not supported Let remoteproc know when the firmware doesn't support any virtio functionality, so registering a virtio device can be avoided. This is needed for remote processors that doesn't require any virtio-based communications, but are still controlled via remoteproc. [ohad@wizery.com: write commit log] Signed-off-by: Mark Grosen <mgrosen@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
0798e1da7a1cc467f56bfa5149a0eede5ae38f72 |
|
13-Dec-2011 |
Mark Grosen <mgrosen@ti.com> |
remoteproc: do not require an iommu Not all remote processors employ an IOMMU, so do not error out on !iommu_present(). Note: we currently still use iommu_present() to tell whether we need to configure an IOMMU or not. That works for simple cases, but will easily fail with more complicated ones (e.g. where an IOMMU exists, but not all remote processors use it). When those use cases show up, we will solve them by introducing something like remoteproc hw capabilities. [ohad@wizery.com: write commit log] Signed-off-by: Mark Grosen <mgrosen@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
|
400e64df6b237eb36b127efd72000a2794f9eec1 |
|
20-Oct-2011 |
Ohad Ben-Cohen <ohad@wizery.com> |
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>
|