summaryrefslogtreecommitdiff
path: root/drivers/remoteproc
AgeCommit message (Collapse)AuthorFilesLines
2012-07-27Merge tag 'remoteproc-for-3.6' of ↵Linus Torvalds7-561/+587
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc Pull remoteproc update from Ohad Ben-Cohen: - custom binary format support from Sjur Brændeland - groundwork for recovery and runtime pm support - some cleanups and API simplifications Fix up conflicts in drivers/remoteproc/remoteproc_core.c due to clashes with earlier cleanups by Sjur Brændeland (with part of the cleanups moved into the new remoteproc_elf_loader.c file). * tag 'remoteproc-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc: MAINTAINERS: add remoteproc's git remoteproc: Support custom firmware handlers remoteproc: Move Elf related functions to separate file remoteproc: Add function rproc_get_boot_addr remoteproc: Pass struct fw to load_segments and find_rsc_table. remoteproc: adopt the driver core's alloc/add/del/put naming remoteproc: remove the get_by_name/put API remoteproc: support non-iommu carveout assignment remoteproc: simplify unregister/free interfaces remoteproc: remove the now-redundant kref remoteproc: maintain a generic child device for each rproc remoteproc: allocate vrings on demand, free when not needed
2012-07-15remoteproc: Support custom firmware handlersSjur Brændeland3-16/+77
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-15remoteproc: Move Elf related functions to separate fileSjur Brændeland4-248/+300
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-15remoteproc: Add function rproc_get_boot_addrSjur Brændeland1-9/+19
Prepare for introduction of custom firmware loaders by moving the function operating on ELF data-structures into separate functions. Move lookup of the boot_addr in the ELF binary to the function rproc_get_boot_addr(). Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> [rproc_get_boot_addr's kerneldoc: add missing @rproc line] [rproc_get_boot_addr's kerneldoc: minor style changes] Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-15remoteproc: Pass struct fw to load_segments and find_rsc_table.Sjur Brændeland1-12/+12
Prepare for introduction of custom firmware loaders by changing the functions rproc_find_rcs_table() and rproc_load_segments() to use struct firmware as parameter. When the custom loader framework is introduced all calls into the firmware specific function must use struct firmware as parameter. Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06remoteproc: adopt the driver core's alloc/add/del/put namingOhad Ben-Cohen2-20/+20
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-Cohen1-130/+0
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: support non-iommu carveout assignmentOhad Ben-Cohen1-15/+19
Publish carveout addresses on non-iommu setups too. Reported-and-acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06remoteproc: simplify unregister/free interfacesOhad Ben-Cohen2-18/+12
Simplify the unregister/free interfaces, and make them easier to understand and use, by moving to a symmetric and consistent alloc() -> register() -> unregister() -> free() flow. To create and register an rproc instance, one needed to invoke rproc_alloc() followed by rproc_register(). To unregister and free an rproc instance, one now needs to invoke rproc_unregister() followed by rproc_free(). Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-06remoteproc: remove the now-redundant krefOhad Ben-Cohen2-43/+15
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-Cohen4-58/+111
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-07-04remoteproc: allocate vrings on demand, free when not neededOhad Ben-Cohen3-57/+67
Dynamically allocate the vrings' DMA when the remote processor is about to be powered on (i.e. when ->find_vqs() is invoked), and release them as soon as it is powered off (i.e. when ->del_vqs() is invoked). The obvious and immediate benefit is better memory utilization, since memory for the vrings is now only allocated when the relevant remote processor is used. Additionally, this approach also makes recovery of a (crashing) remote processor easier: one just needs to remove the relevant vdevs, and the entire vrings cleanup takes place automagically. Tested-by: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-04remoteproc: fix missing CONFIG_FW_LOADER configurationsOhad Ben-Cohen1-0/+1
Remoteproc requires user space firmware loading support, so let's select FW_LOADER explicitly to avoid painful misconfigurations (which only show up in runtime). Cc: stable <stable@vger.kernel.org> Reported-by: Mark Grosen <mgrosen@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-07-04remoteproc/omap: fix randconfig unmet direct dependenciesOhad Ben-Cohen1-0/+1
OMAP_REMOTEPROC selects REMOTEPROC and RPMSG, both of which depend on EXPERIMENTAL, so let's have OMAP_REMOTEPROC depend on EXPERIMENTAL too, in order to avoid the below randconfig warnings. warning: (OMAP_REMOTEPROC) selects REMOTEPROC which has unmet direct dependencies (EXPERIMENTAL) warning: (OMAP_REMOTEPROC) selects RPMSG which has unmet direct dependencies (EXPERIMENTAL) Cc: stable <stable@vger.kernel.org> Reported-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-06-17remoteproc/omap: fix dev_err typoOhad Ben-Cohen1-1/+1
For some reason one of the dev_err invocations is using a wrong device so fix that. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: stable@vger.kernel.org
2012-06-10remoteproc: fix missing fault indication in error-pathSjur Brændeland1-1/+3
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> Cc: stable@vger.kernel.org
2012-06-10remoteproc: fix print format warningsSjur Brændeland1-3/+3
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> Cc: stable@vger.kernel.org
2012-05-30Merge tag 'iommu-updates-v3.5' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull IOMMU updates from Joerg Roedel: "Not much stuff this time. The only change to the IOMMU core code is the addition of a handle to the fault handling code. A few updates to the AMD IOMMU driver to work around new errata. The other patches are mostly fixes and enhancements to the existing ARM IOMMU drivers and documentation updates. A new IOMMU driver for the Exynos platform was also underway but got merged via the Samsung tree and is not part of this tree." * tag 'iommu-updates-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: Documentation: kernel-parameters.txt Add amd_iommu_dump iommu/core: pass a user-provided token to fault handlers iommu/tegra: gart: Fix register offset correctly iommu: OMAP: device detach on domain destroy iommu: tegra/gart: Add device tree support iommu: tegra/gart: use correct gart_device iommu/tegra: smmu: Print device name correctly iommu/amd: Add workaround for event log erratum iommu/amd: Check for the right TLP prefix bit dma-debug: release free_entries_lock before saving stack trace
2012-05-23Merge branch 'for-linus' of ↵Linus Torvalds1-2/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull trivial updates from Jiri Kosina: "As usual, it's mostly typo fixes, redundant code elimination and some documentation updates." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (57 commits) edac, mips: don't change code that has been removed in edac/mips tree xtensa: Change mail addresses of Hannes Weiner and Oskar Schirmer lib: Change mail address of Oskar Schirmer net: Change mail address of Oskar Schirmer arm/m68k: Change mail address of Sebastian Hess i2c: Change mail address of Oskar Schirmer net: Fix tcp_build_and_update_options comment in struct tcp_sock atomic64_32.h: fix parameter naming mismatch Kconfig: replace "--- help ---" with "---help---" c2port: fix bogus Kconfig "default no" edac: Fix spelling errors. qla1280: Remove redundant NULL check before release_firmware() call remoteproc: remove redundant NULL check before release_firmware() qla2xxx: Remove redundant NULL check before release_firmware() call. aic94xx: Get rid of redundant NULL check before release_firmware() call tehuti: delete redundant NULL check before release_firmware() qlogic: get rid of a redundant test for NULL before call to release_firmware() bna: remove redundant NULL test before release_firmware() tg3: remove redundant NULL test before release_firmware() call typhoon: get rid of redundant conditional before all to release_firmware() ...
2012-05-22iommu/core: pass a user-provided token to fault handlersOhad Ben-Cohen1-2/+2
Sometimes a single IOMMU user may have to deal with several different IOMMU devices (e.g. remoteproc). When an IOMMU fault happens, such users have to regain their context in order to deal with the fault. Users can't use the private fields of neither the iommu_domain nor the IOMMU device, because those are already used by the IOMMU core and low level driver (respectively). This patch just simply allows users to pass a private token (most notably their own context pointer) to iommu_set_fault_handler(), and then makes sure it is provided back to the users whenever an IOMMU fault happens. The patch also adopts remoteproc to the new fault handling interface, but the real functionality using this (recovery of remote processors) will only be added later in a subsequent patch set. Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2012-05-14remoteproc: fix off-by-one bug in __rproc_free_vringsSubramaniam Chanderashekarapuram1-1/+1
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>
2012-04-30remoteproc: remove redundant NULL check before release_firmware()Jesper Juhl1-2/+1
release_firmware deals gracefully with NULL pointers, so checking first is redundant. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-04-06simple_open: automatically convert to simple_open()Stephen Boyd1-10/+3
Many users of debugfs copy the implementation of default_open() when they want to support a custom read/write function op. This leads to a proliferation of the default_open() implementation across the entire tree. Now that the common implementation has been consolidated into libfs we can replace all the users of this function with simple_open(). This replacement was done with the following semantic patch: <smpl> @ open @ identifier open_f != simple_open; identifier i, f; @@ -int open_f(struct inode *i, struct file *f) -{ ( -if (i->i_private) -f->private_data = i->i_private; | -f->private_data = i->i_private; ) -return 0; -} @ has_open depends on open @ identifier fops; identifier open.open_f; @@ struct file_operations fops = { ... -.open = open_f, +.open = simple_open, ... }; </smpl> [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-06remoteproc: cleanup resource table parsing pathsOhad Ben-Cohen1-33/+39
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>
2012-03-06remoteproc: remove the hardcoded vring alignmentOhad Ben-Cohen2-6/+8
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/omap: remove the mbox_callback limitationOhad Ben-Cohen1-10/+1
Now that remoteproc supports any number of virtio devices, the previous sanity check in omap_rproc_mbox_callback doesn't make sense anymore. Remove that so we can start supporting multiple vdevs. 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-Cohen3-220/+218
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: safer boot/shutdown orderOhad Ben-Cohen1-10/+10
Boot the remote processor only after setting up the virtqueues, and shut it down before deleting them. Remote processors should obey virtio status changes, and therefore not manipulate/trigger the virtqueues while the virtio driver isn't ready, but it's just safer not to rely on that (plus a vq access might already be inflight while a vdev status is changed). We also don't have yet status change notifications, but that's a temporary limitation. 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: remoteproc_rpmsg -> remoteproc_virtioOhad Ben-Cohen2-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-03-06remoteproc: resource table overhaulOhad Ben-Cohen1-97/+209
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-28remoteproc/omap: two Kconfig fixesOhad Ben-Cohen1-2/+1
1. Depend on OMAP_IOMMU instead of selecting it, to fix an unmet direct dependency of it (and its imminent build error) 2. Set default to 'no' (achieved implicitly by dropping the 'default' line) Reported-by: Russell King <linux@arm.linux.org.uk> 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> Cc: Russell King <linux@arm.linux.org.uk>
2012-02-28remoteproc: make sure we're parsing a 32bit firmwareOhad Ben-Cohen1-0/+8
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>
2012-02-22remoteproc: s/big switch/lookup table/Ohad Ben-Cohen1-22/+23
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-22remoteproc: bail out if firmware has different endianessOhad Ben-Cohen1-0/+11
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>
2012-02-22remoteproc: don't use virtio's weak barriersOhad Ben-Cohen1-1/+5
When creating a virtqueue for rpmsg, tell virtio we're not interested in "weak" smp barriers, since we're talking to a real device. On ARM, this means using a DSB instead of a DMB, which is needed for platforms that kick the remote processor using some kind of a mailbox device mapped to Device memory (otherwise the kick can jump ahead and wake the remote processor before it has observed the changes to the vrings). Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-02-22remoteproc: depend on EXPERIMENTALOhad Ben-Cohen2-1/+5
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>
2012-02-09remoteproc: add Kconfig menuOhad Ben-Cohen1-0/+4
Add a dedicated Kconfig menu for the remoteproc drivers, so they don't show up in the main driver menu. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-02-09remoteproc: look for truncated firmware imagesOhad Ben-Cohen1-5/+30
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>
2012-02-09remoteproc/omap: utilize module_platform_driverOhad Ben-Cohen1-12/+1
Ditch some boilerplate code by employing the module_platform_driver helper. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-02-09remoteproc: avoid registering a virtio device if not supportedMark Grosen1-1/+1
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>
2012-02-09remoteproc: do not require an iommuMark Grosen1-2/+2
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>
2012-02-09remoteproc/omap: add a remoteproc driver for OMAP4Ohad Ben-Cohen4-0/+340
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-Cohen2-0/+296
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-Cohen2-0/+180
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-Cohen4-0/+1463
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>