linux-toradex.git/include/linux/remoteproc.h, branch v4.6-rc3

remoteproc: add a rproc ops for performing address translation

2015-06-17T06:57:12+00:00

The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.

A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories.

While at this, also update the rproc_da_to_va() documentation since it
is an exported function.

Signed-off-by: Suman Anna 
Signed-off-by: Dave Gerlach 
Signed-off-by: Ohad Ben-Cohen

remoteproc: introduce rproc_get_by_phandle API

2015-06-16T18:12:52+00:00

Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.

This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
remove the get_by_name/put API") for the ref counting but is modified
to use a simple list and locking mechanism and has rproc_get_by_name
replaced with an rproc_get_by_phandle API.

Signed-off-by: Dave Gerlach 
Signed-off-by: Suman Anna 
[fix order of Signed-off-by tags]
Signed-off-by: Ohad Ben-Cohen

remoteproc: add IOMMU hardware capability flag

2015-03-12T08:43:26+00:00

The remoteproc framework currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for processors that
do not have an IOMMU. Replace this logic instead by using a h/w
capability flag for the presence of IOMMU in the rproc structure.

This issue is seen on OMAP platforms when trying to add a remoteproc
driver for a small Cortex M3 called the WkupM3 used for suspend /
resume management on TI AM335/AM437x SoCs. This processor does not
have an MMU. Same is the case with another processor subsystem
PRU-ICSS on AM335/AM437x. All these are platform devices, and the
current iommu_present check will not scale for the same kernel image
to support OMAP4/OMAP5 and AM335/AM437x.

The existing platform implementation drivers - OMAP remoteproc, STE
Modem remoteproc and DA8xx remoteproc, are updated as well to properly
configure the newly added rproc field.

Cc: Robert Tivy 
Cc: Linus Walleij 
Signed-off-by: Suman Anna 
[small change in the commit title and in a single comment]
Signed-off-by: Ohad Ben-Cohen

remoteproc: support virtio config space.

2013-04-07T11:06:17+00:00

Support virtio configuration space and device status. The virtio
device can now access the resource table in shared memory.

Signed-off-by: Sjur Brændeland 
Acked-by: Ido Yariv 
[rebase and style changes]
Signed-off-by: Ohad Ben-Cohen

remoteproc: perserve resource table data

2013-04-07T11:06:07+00:00

Copy resource table from first to second firmware loading.
After firmware is loaded to memory, update the vdevs resource
pointer to the resource table kept in device memory.

Signed-off-by: Sjur Brændeland 
Acked-by: Ido Yariv 
[rebase, terminology and style changes]
Signed-off-by: Ohad Ben-Cohen

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