diff options
| author | Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> | 2026-05-06 08:01:03 +0300 |
|---|---|---|
| committer | Mathieu Poirier <mathieu.poirier@linaro.org> | 2026-05-25 18:39:07 +0300 |
| commit | 0590420c2f90de497d342c9a41a618f46f4d09ab (patch) | |
| tree | 0e00601c25a322e145908c878ea7e7a4484b9838 /include/linux/panic.h | |
| parent | a48df51d23138388900995add2854cda4aa68e55 (diff) | |
| download | linux-0590420c2f90de497d342c9a41a618f46f4d09ab.tar.xz | |
remoteproc: Move resource table data structure to its own header
The resource table data structure has traditionally been associated with
the remoteproc framework, where the resource table is included as a
section within the remote processor firmware binary. However, it is also
possible to obtain the resource table through other means—such as from a
reserved memory region populated by the boot firmware, statically
maintained driver data, or via a secure SMC call—when it is not embedded
in the firmware.
There are multiple Qualcomm remote processors (e.g., Venus, Iris, GPU,
etc.) in the upstream kernel that do not use the remoteproc framework to
manage their lifecycle for various reasons.
When Linux is running at EL2, similar to the Qualcomm PAS driver
(qcom_q6v5_pas.c), client drivers for subsystems like video and GPU may
also want to use the resource table SMC call to retrieve and map
resources before they are used by the remote processor.
In such cases, the resource table data structure is no longer tightly
coupled with the remoteproc headers. Client drivers that do not use the
remoteproc framework should still be able to parse the resource table
obtained through alternative means. Therefore, there is a need to
decouple the resource table definitions from the remoteproc headers.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260506050107.1985033-2-mukesh.ojha@oss.qualcomm.com
Diffstat (limited to 'include/linux/panic.h')
0 files changed, 0 insertions, 0 deletions
