author | Suman Anna <s-anna@ti.com> | |
Fri, 15 Feb 2019 19:06:08 +0000 (13:06 -0600) | ||
committer | Suman Anna <s-anna@ti.com> | |
Sun, 24 Feb 2019 01:20:48 +0000 (19:20 -0600) | ||
commit | 2794d1693b052995d7506bc975a6844fe753e3a4 | |
tree | 96a14a4082de7cdd5d454313392d6549ca8383ca | tree | snapshot (tar.xz tar.gz zip) |
parent | 6f4eac2f8710adc703e854f63992c3b6291ca273 | commit | diff |
remoteproc: Add support to handle device specific resource types
The remoteproc framework handles a fixed set of resource table entries
today. To make it scalable across multiple platforms, it makes sense
for the framework to provide a way for the device specific implementation
to define and handle vendor specific resource types. These resource types
would be very specific to an implementation instance that it does not
make sense for the framework to handle it. There can be two types of
such resources depending on whether they need to be handled prior to
the loading of the firmware segments or after. A post-loading resource
type is typically needed because it references a loaded segment pointer
for conveying the resource information.
For instance, a remoteproc implementation might want timers information
embedded in the resource table so that the driver could parse the binary
and enable accordingly. Another example would be hwspinlocks that it
is using, to properly share system wide resources. A PRU post-loading
vendor resource handler for interrupts requires the PRU event - interrupt
channel information to be loaded into device memory.
This patch adds a function pointer to the list of rproc_ops for the
driver implementation to handle such custom vendor resources, and
reuses the same handler between pre-loading and post-loading resource
types, with the sub-types in the implementation handling the processing
of those resource types.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc framework handles a fixed set of resource table entries
today. To make it scalable across multiple platforms, it makes sense
for the framework to provide a way for the device specific implementation
to define and handle vendor specific resource types. These resource types
would be very specific to an implementation instance that it does not
make sense for the framework to handle it. There can be two types of
such resources depending on whether they need to be handled prior to
the loading of the firmware segments or after. A post-loading resource
type is typically needed because it references a loaded segment pointer
for conveying the resource information.
For instance, a remoteproc implementation might want timers information
embedded in the resource table so that the driver could parse the binary
and enable accordingly. Another example would be hwspinlocks that it
is using, to properly share system wide resources. A PRU post-loading
vendor resource handler for interrupts requires the PRU event - interrupt
channel information to be loaded into device memory.
This patch adds a function pointer to the list of rproc_ops for the
driver implementation to handle such custom vendor resources, and
reuses the same handler between pre-loading and post-loading resource
types, with the sub-types in the implementation handling the processing
of those resource types.
Signed-off-by: Suman Anna <s-anna@ti.com>
drivers/remoteproc/remoteproc_core.c | diff | blob | history | |
drivers/remoteproc/remoteproc_debugfs.c | diff | blob | history | |
include/linux/remoteproc.h | diff | blob | history |