author | Suman Anna <s-anna@ti.com> | |
Mon, 8 Oct 2018 22:55:32 +0000 (17:55 -0500) | ||
committer | Suman Anna <s-anna@ti.com> | |
Tue, 22 Jan 2019 23:57:07 +0000 (17:57 -0600) | ||
commit | 20afed1b45bfa0e75ae4c7a9ce9ad59803e7d791 | |
tree | d9b9fc2a863831ace9a11e00a2576049bef8a5bb | tree | snapshot (tar.xz tar.gz zip) |
parent | c5ad352eb8f9bbbcfd206f33df82f28e38f4562d | commit | diff |
remoteproc: add infrastructure support to allow pre-loaded remoteprocs
The remoteproc infrastructure is enhanced to allow remoteproc drivers to
be able to connect to already loaded and/or booted remote processors. The
added infrastructure is designed to allow multiple different scenarios:
- Support userspace driven loading, with the actual boot triggered
through the kernel.
- Support remote processors loaded and booted by bootloaders, with
resource table either directly provided by the remoteproc driver or
by remoteproc core by requesting the firmware and processing only
the resource table.
Support for these features are provided through two new fields in the
rproc structure - 'skip_firmware_request' and 'skip_load'. These fields
are expected to be set to true as per the mode/need required by the
remoteproc drivers before a rproc_add() call. The remoteproc core skips
looking for firmware and/or loading any firmware segments using these two
state flags. The default behavior is unchanged.
The interface and implementation details for either of the above scenarios
is left to the individual remoteproc drivers. This design will be used
to achieve the following different usecases on TI SoCs:
- Allow the TI Keystone remoteproc driver to support a userspace based
loader. The remoteproc driver is expected to invoke rproc_boot() and
rproc_shutdown() for triggering the boot and shutdown of the remote
processor after the loading is completed and the resource table
information is published to the remoteproc driver. The resource
table is processed in-line during the rproc_boot() invocation.
- Allow the K3 R5F remoteproc driver to be invoked in an IPC-only mode
(No load, boot or error recovery functionality, but only establish
IPC mechanism). The driver relies on still using the regular state
machine flow for creating the virtio devices. The rproc .start() and
.stop() ops are not bypassed, and the actual boot bypass is implemented
within the driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc infrastructure is enhanced to allow remoteproc drivers to
be able to connect to already loaded and/or booted remote processors. The
added infrastructure is designed to allow multiple different scenarios:
- Support userspace driven loading, with the actual boot triggered
through the kernel.
- Support remote processors loaded and booted by bootloaders, with
resource table either directly provided by the remoteproc driver or
by remoteproc core by requesting the firmware and processing only
the resource table.
Support for these features are provided through two new fields in the
rproc structure - 'skip_firmware_request' and 'skip_load'. These fields
are expected to be set to true as per the mode/need required by the
remoteproc drivers before a rproc_add() call. The remoteproc core skips
looking for firmware and/or loading any firmware segments using these two
state flags. The default behavior is unchanged.
The interface and implementation details for either of the above scenarios
is left to the individual remoteproc drivers. This design will be used
to achieve the following different usecases on TI SoCs:
- Allow the TI Keystone remoteproc driver to support a userspace based
loader. The remoteproc driver is expected to invoke rproc_boot() and
rproc_shutdown() for triggering the boot and shutdown of the remote
processor after the loading is completed and the resource table
information is published to the remoteproc driver. The resource
table is processed in-line during the rproc_boot() invocation.
- Allow the K3 R5F remoteproc driver to be invoked in an IPC-only mode
(No load, boot or error recovery functionality, but only establish
IPC mechanism). The driver relies on still using the regular state
machine flow for creating the virtio devices. The rproc .start() and
.stop() ops are not bypassed, and the actual boot bypass is implemented
within the driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
drivers/remoteproc/remoteproc_core.c | diff | blob | history | |
include/linux/remoteproc.h | diff | blob | history |