| author | Robert Tivy <rtivy@ti.com> | |
| Thu, 12 Sep 2019 17:45:08 +0000 (17:45 +0000) | ||
| committer | Suman Anna <s-anna@ti.com> | |
| Mon, 23 Sep 2019 01:46:54 +0000 (20:46 -0500) | ||
| commit | 15dfdff5383cc23ee39eb41479b72975de9c47c2 | |
| tree | 677d5fe45c56fd0aa8fd1898d9a517f957e40a90 | tree | snapshot (tar.xz tar.gz zip) |
| parent | 3b11b13599403f8d93a703b086484627fbf036ba | commit | diff |
TEMP: remoteproc: add "late attach" support
The remoteproc driver core is, in general, responsible for allocating
the memory for firmware segments, parsing and loading the firmware
segments into the allocated memory regions, mapping these memory
regions into associated IOMMUs, starting/releasing the processors
from reset, and finally establishing IPC between the host and the
remote processors.
The "late attach" feature refers to a model wherein a remote processor
has already been configured, loaded and started by some external entity
prior to kernel boot (u-boot, for example), and the remoteproc driver
needs to be configured to 'attach' or establish a connection with the
currently running code on the remote processor without resetting or
reconfiguring the device and associated peripherals. The feature is
being added to support specific use-cases (eg: "early camera" or "early
video"), requiring certain KPI criteria. The feature is currently based
on having a remote processor perform all the necessary activities to
achieve the required KPI in a stand-alone mode without having to rely
on communicating with the MPU or perform any IPC activities until the
remoteproc driver is up.
The "late attach" support in the remoteproc driver core is currently
designed to not perform the loading of the firmware segments, or
programming of the IOMMUs. The driver though still goes through the
sequence of processing the firmware to set up the correct virtio
based IPC transports, and allocating the required memory segments
to mark these memory regions as used/reserved from kernel in the
corresponding rproc device's CMA pools. The driver expects the
allocator to not perform any memory initialization, to avoid wiping
out the pre-loaded code. Virtio-based IPC with the remote processors
is established once the driver completes processing the firmware,
just as in a regular boot.
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
The remoteproc driver core is, in general, responsible for allocating
the memory for firmware segments, parsing and loading the firmware
segments into the allocated memory regions, mapping these memory
regions into associated IOMMUs, starting/releasing the processors
from reset, and finally establishing IPC between the host and the
remote processors.
The "late attach" feature refers to a model wherein a remote processor
has already been configured, loaded and started by some external entity
prior to kernel boot (u-boot, for example), and the remoteproc driver
needs to be configured to 'attach' or establish a connection with the
currently running code on the remote processor without resetting or
reconfiguring the device and associated peripherals. The feature is
being added to support specific use-cases (eg: "early camera" or "early
video"), requiring certain KPI criteria. The feature is currently based
on having a remote processor perform all the necessary activities to
achieve the required KPI in a stand-alone mode without having to rely
on communicating with the MPU or perform any IPC activities until the
remoteproc driver is up.
The "late attach" support in the remoteproc driver core is currently
designed to not perform the loading of the firmware segments, or
programming of the IOMMUs. The driver though still goes through the
sequence of processing the firmware to set up the correct virtio
based IPC transports, and allocating the required memory segments
to mark these memory regions as used/reserved from kernel in the
corresponding rproc device's CMA pools. The driver expects the
allocator to not perform any memory initialization, to avoid wiping
out the pre-loaded code. Virtio-based IPC with the remote processors
is established once the driver completes processing the firmware,
just as in a regular boot.
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
| drivers/remoteproc/remoteproc_core.c | diff | blob | history | |
| include/linux/remoteproc.h | diff | blob | history |