Commit Graph

100 Commits

Author SHA1 Message Date
Fernando Guzman Lugo 2e37abb89a remoteproc: create a 'recovery' debugfs entry
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-18 12:53:41 +03:00
Fernando Guzman Lugo 70b85ef83c remoteproc: add actual recovery implementation
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-18 12:53:33 +03:00
Fernando Guzman Lugo 8afd519c34 remoteproc: add rproc_report_crash function to notify rproc crashes
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-09-18 12:53:22 +03:00
Sjur Brændeland a1a7e0a33a remoteproc: Add dependency to HAS_DMA
Remoteproc relies on HAS_DMA, add this dependency in Kconfig.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-18 07:05:06 +03:00
Juan Gutierrez 4980f465d2 remoteproc/omap: set bootaddr support
Some remote processors (like OMAP4's DSP) require we explicitly
set a boot address from which they'd start executing code when
taken out of reset.

Support for this is now being added to the omap-specific remoteproc
driver through a set_bootaddr function in the platform data which,
if needed, must be set according to the backend remote processor.

For OMAP4's dsp we can use the following control function:

  .set_bootaddr  = omap_ctrl_write_dsp_boot_addr

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
[ohad: slight changes to the commit log]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-09-11 15:24:14 +03:00
Linus Torvalds a9197f903f A batch of remoteproc patches for 3.6:
- custom binary format support from Sjur Brændeland
 - groundwork for recovery and runtime pm support
 - some cleanups and API simplifications
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJQD75aAAoJELLolMlTRIoMM84P/RfnGhFl/mzKmDssFtwkajIb
 HRrZ1/YWjAjnSOvD5FF+LrS4TtxPgx9747I1Xh49Uk7DHb6siNTDUNbFJNifWo7g
 TbKo3LgLllfNXnwbunIfiGqOW2HzaCVo6vhk59fL3QAsdtCDlROegt1NbOrV8T2S
 +XZlgYhhUSlIQQCgsRBVJWbwP4k5PtAYmwL1VN7ONgj2ILJDP7MhAasDMl+KeGSG
 128g+aCoIkfc9vC+ghDNAfE6DsHHeVyXAWPoWHoyjiteZ1NDkGxUBdTbsrtMYM2K
 ZguEISfVNcMSk10HhoYWtqYZfZUTEM18kOt/182CEwpRVRE34Z7fhcQCiCGX6u6v
 E+7tNj/0qow+dcj2OtS3NEePIHKcuvjBQ09b6GED+qsmC8lENo2Ly364T6JfriNl
 tv1PShvmodrBlLFusAikJKuzYFI9xgQawpL3oV0pMrEiujHqgNhuqrCQJkIWnA8d
 9At2RZAMdFBFa7gd90lPicVqPR9HcGipVk7bKRyFAoqmpPLI85Nm1r9l4TPqEXpC
 Otb373gX30yqWNRD9Hmmxx/+40S2odELEDN4wrPRF+cCAbmWtFey415gdoaqBESn
 BiTRrHxNy2+dKsCgSUQMyn59rF552qrCb31REYAyMMImpftAaWP35OREFNn6oqj2
 vzxsc4wcWZaLflrqQGj6
 =vBgg
 -----END PGP SIGNATURE-----

Merge tag 'remoteproc-for-3.6' of 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-26 16:19:08 -07:00
Sjur Brændeland 4afc89d66c remoteproc: Support custom firmware handlers
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-15 11:39:01 +03:00
Sjur Brændeland 72854fb042 remoteproc: Move Elf related functions to separate file
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-15 11:25:27 +03:00
Sjur Brændeland 3e5f9eb5d9 remoteproc: Add function rproc_get_boot_addr
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-15 11:14:45 +03:00
Sjur Brændeland bd48498487 remoteproc: Pass struct fw to load_segments and find_rsc_table.
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-15 11:14:26 +03:00
Ohad Ben-Cohen 160e7c840f remoteproc: adopt the driver core's alloc/add/del/put naming
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-06 00:53:27 +03:00
Ohad Ben-Cohen 40e575b1d0 remoteproc: remove the get_by_name/put API
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-06 00:53:27 +03:00
Ohad Ben-Cohen 0e49b72c8c remoteproc: support non-iommu carveout assignment
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-06 00:53:26 +03:00
Ohad Ben-Cohen c6b5a27628 remoteproc: simplify unregister/free interfaces
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-06 00:53:25 +03:00
Ohad Ben-Cohen 7183a2a799 remoteproc: remove the now-redundant kref
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-06 00:53:25 +03:00
Ohad Ben-Cohen b5ab5e24e9 remoteproc: maintain a generic child device for each rproc
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-06 00:53:03 +03:00
Ohad Ben-Cohen 6db20ea8d8 remoteproc: allocate vrings on demand, free when not needed
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-04 13:27:04 +03:00
Ohad Ben-Cohen e121aefa7d remoteproc: fix missing CONFIG_FW_LOADER configurations
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-04 11:01:12 +03:00
Ohad Ben-Cohen d50394266b remoteproc/omap: fix randconfig unmet direct dependencies
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-07-04 10:51:10 +03:00
Ohad Ben-Cohen 6b03976288 remoteproc/omap: fix dev_err typo
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-17 10:31:03 +03:00
Sjur Brændeland 30338cf09f remoteproc: fix missing fault indication in error-path
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-10 14:49:46 +03:00
Sjur Brændeland e981f6d41a remoteproc: fix print format warnings
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-06-10 14:49:39 +03:00
Linus Torvalds 2f83766d4b IOMMU Updates for Linux 3.5
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.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJPxfseAAoJECvwRC2XARrjvL4QAL39988y7ajHSI3ym3Dxovn9
 w8md63xKNlTpCB8NJPRIJpcGrE7QFtNXPFCagTqO713ulwCoKayEwKGOU7VQagFc
 0/JoHxE5usE5OuA6tyAJbpWK10kWKDzu6HjZfqF2yoa0q/REbsu65KsY7zc7HbpF
 qEAXX1xr9IC7GUM7gv75OR8CP2VJCW3+6VyhiD/37t3KpNwINMpRDO/eN/KiwoUI
 1t+/DVwO6pH5UrGReWrmjs/gcxFMzkeelt+iCA32kzkWLtyWjeWBujVWnFvVtpkz
 R4pV2T2jvs6fWPU5MMBXZRd5AvLLqcu/g/Yr21WYHz07jCcGxlCUp9qpnGLt2el0
 /YTY3LBZUQJ5sx3OSJV+oQVTtI5x0EkAiOrJ8Dx20wNAFqun9bhJb1WX0IXflmZc
 oC7SF5wjXq8pUQmX/wpGMbW7XYompypJGqlEsftJEytf4dfR6KJ2Vo1h3pHtpaex
 IaY6TqmdW44e0EgbFTM7RMNFtC7GrIY9NE+WKlrFtsHhUFrqt1NVBEcO3faU0ES6
 UAguFRPM/HAdkVmY620+DUT/JkEMemWq2jgWExLGLC9gI8L1Xj2cdU8esstuMUoV
 GGG4u9a5W1rALwg+zPCQGoVxPKmd6fpeC3U+Rmg2639chy+h4c/cBXkzfUsxe2lg
 wvMDVbjDN1Fz0c29YJit
 =K23I
 -----END PGP SIGNATURE-----

Merge tag 'iommu-updates-v3.5' of 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-30 08:49:28 -07:00
Linus Torvalds e8650a0823 Merge branch 'for-linus' of 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-22 19:22:50 -07:00
Ohad Ben-Cohen 77ca233235 iommu/core: pass a user-provided token to fault handlers
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-22 18:08:08 +02:00
Subramaniam Chanderashekarapuram 6fd98c124c 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>
2012-05-13 23:15:42 +03:00
Jesper Juhl 3cc6e78777 remoteproc: remove redundant NULL check before release_firmware()
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-30 13:24:45 +02:00
Stephen Boyd 234e340582 simple_open: automatically convert to simple_open()
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-04-05 15:25:50 -07:00
Ohad Ben-Cohen 1e3e2c7c46 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>
2012-03-06 19:14:44 +02:00
Ohad Ben-Cohen 63140e0ed2 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>
2012-03-06 19:14:37 +02:00
Ohad Ben-Cohen 55f34080d9 remoteproc/omap: remove the mbox_callback limitation
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-06 19:14:23 +02:00
Ohad Ben-Cohen 7a18694162 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>
2012-03-06 19:14:12 +02:00
Ohad Ben-Cohen 41a6ee09ee remoteproc: safer boot/shutdown order
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-06 19:13:53 +02:00
Ohad Ben-Cohen 04a9016e82 remoteproc: remoteproc_rpmsg -> remoteproc_virtio
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-06 19:13:45 +02:00
Ohad Ben-Cohen fd2c15ec1d 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>
2012-03-06 19:13:39 +02:00
Ohad Ben-Cohen 9cd8eb433c remoteproc/omap: two Kconfig fixes
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-28 19:09:16 +02:00
Ohad Ben-Cohen 40b78b2cc7 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>
2012-02-28 18:03:40 +02:00
Ohad Ben-Cohen e12bc14b88 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>
2012-02-22 18:28:49 +02:00
Ohad Ben-Cohen cf59d3e9a7 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>
2012-02-22 18:28:49 +02:00
Ohad Ben-Cohen dd6da1c5e9 remoteproc: don't use virtio's weak barriers
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-22 18:28:48 +02:00
Ohad Ben-Cohen 489d129a2f 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>
2012-02-22 18:28:34 +02:00
Ohad Ben-Cohen 650d65611e remoteproc: add Kconfig menu
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-08 22:54:43 +02:00
Ohad Ben-Cohen 9bc9123117 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>
2012-02-08 22:54:37 +02:00
Ohad Ben-Cohen 63d667bf53 remoteproc/omap: utilize module_platform_driver
Ditch some boilerplate code by employing the module_platform_driver
helper.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
2012-02-08 22:54:30 +02:00
Mark Grosen 7d2d3956fb 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>
2012-02-08 22:54:17 +02:00
Mark Grosen 0798e1da7a 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>
2012-02-08 22:54:11 +02:00
Ohad Ben-Cohen 34ed5a33b1 remoteproc/omap: add a remoteproc driver for OMAP4
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-08 22:53:47 +02:00
Ohad Ben-Cohen ac8954a413 remoteproc: create rpmsg virtio device
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-08 22:53:39 +02:00
Ohad Ben-Cohen 6391a70682 remoteproc: add debugfs entries
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-08 22:53:30 +02:00
Ohad Ben-Cohen 400e64df6b 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>
2012-02-08 22:52:56 +02:00