summaryrefslogtreecommitdiff
path: root/include/uapi
diff options
context:
space:
mode:
authorMukesh Ojha <mukesh.ojha@oss.qualcomm.com>2026-05-06 08:01:03 +0300
committerMathieu Poirier <mathieu.poirier@linaro.org>2026-05-25 18:39:07 +0300
commit0590420c2f90de497d342c9a41a618f46f4d09ab (patch)
tree0e00601c25a322e145908c878ea7e7a4484b9838 /include/uapi
parenta48df51d23138388900995add2854cda4aa68e55 (diff)
downloadlinux-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/uapi')
0 files changed, 0 insertions, 0 deletions