linux-toradex.git/include/linux/remoteproc.h, branch v3.7.3

remtoteproc: maintain max notifyid

2012-09-18T18:55:52+00:00

Some of the rproc drivers (STE modem specifically) needs to know
the range of the notification IDs used for notifying the device.

Maintain a variable in struct rproc holding the largest allocated
notification id, so low-level rproc drivers could access it.

Signed-off-by: Sjur Brændeland 
[ohad: rebase, slightly edit commit log]
Signed-off-by: Ohad Ben-Cohen

remoteproc: create a 'recovery' debugfs entry

2012-09-18T09:53:41+00:00

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 > /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 > /remoteproc/remoteproc0/recovery

- enabling recovery:
$ echo enabled > /remoteproc/remoteproc0/recovery

Signed-off-by: Fernando Guzman Lugo 
[ohad: some white space, commentary and commit log changes]
Signed-off-by: Ohad Ben-Cohen

remoteproc: add actual recovery implementation

2012-09-18T09:53:33+00:00

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 
[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

remoteproc: add rproc_report_crash function to notify rproc crashes

2012-09-18T09:53:22+00:00

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 
[ohad: some commentary, white space and commit log changes]
Signed-off-by: Ohad Ben-Cohen

remoteproc: Support custom firmware handlers

2012-07-15T08:39:01+00:00

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 
[ohad: namespace fixes, whitespace fixes, style fixes]
Signed-off-by: Ohad Ben-Cohen

remoteproc: adopt the driver core's alloc/add/del/put naming

2012-07-05T21:53:27+00:00

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 .

Cc: Russell King 
Cc: Fernando Guzman Lugo 
Cc: Sjur Brændeland 
Reviewed-by: Linus Walleij 
Acked-by: Stephen Boyd 
Signed-off-by: Ohad Ben-Cohen

remoteproc: remove the get_by_name/put API

2012-07-05T21:53:27+00:00

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 
Cc: Loic Pallardy 
Cc: Ludovic BARRE 
Cc: Michal Simek 
Cc: Fernando Guzman Lugo 
Cc: Suman Anna 
Cc: Mark Grosen 
Acked-by: Stephen Boyd 
Signed-off-by: Ohad Ben-Cohen

remoteproc: remove the now-redundant kref

2012-07-05T21:53:25+00:00

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 
Cc: Fernando Guzman Lugo 
Signed-off-by: Ohad Ben-Cohen

remoteproc: maintain a generic child device for each rproc

2012-07-05T21:53:03+00:00

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  for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo  for trying them out
with the (upcoming) runtime PM support for remoteproc.

Cc: Fernando Guzman Lugo 
Reviewed-by: Stephen Boyd 
Signed-off-by: Ohad Ben-Cohen

remoteproc: remove the hardcoded vring alignment

2012-03-06T17:14:37+00:00

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 
Cc: Brian Swetland 
Cc: Iliyan Malchev 
Cc: Arnd Bergmann 
Cc: Grant Likely 
Cc: Rusty Russell 
Cc: Mark Grosen 
Cc: John Williams 
Cc: Michal Simek 
Cc: Loic PALLARDY 
Cc: Ludovic BARRE 
Cc: Omar Ramirez Luna 
Cc: Guzman Lugo Fernando 
Cc: Anna Suman 
Cc: Clark Rob 
Cc: Stephen Boyd 
Cc: Saravana Kannan 
Cc: David Brown 
Cc: Kieran Bingham 
Cc: Tony Lindgren