aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMathieu Poirier <[email protected]>2020-07-14 13:50:33 -0600
committerBjorn Andersson <[email protected]>2020-07-16 23:06:12 -0700
commite3d2193959824e2119996fe361f92b34750de2b0 (patch)
tree72d0f430803014c5e4153b8f4d3b534239fc0c05
parent0f9dc562b721aa1c0190ffe9f32aa0fcd7b8f2e8 (diff)
remoteproc: Refactor function rproc_trigger_auto_boot()
Refactor function rproc_trigger_auto_boot() to properly deal with scenarios where the remoteproc core needs to attach with a remote processor that has already been booted by an external entity. Signed-off-by: Mathieu Poirier <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Tested-by: Arnaud Pouliquen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
-rw-r--r--drivers/remoteproc/remoteproc_core.c9
1 files changed, 9 insertions, 0 deletions
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 1e9fc3112385..1f73dc13ca93 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1572,6 +1572,15 @@ static int rproc_trigger_auto_boot(struct rproc *rproc)
int ret;
/*
+ * Since the remote processor is in a detached state, it has already
+ * been booted by another entity. As such there is no point in waiting
+ * for a firmware image to be loaded, we can simply initiate the process
+ * of attaching to it immediately.
+ */
+ if (rproc->state == RPROC_DETACHED)
+ return rproc_boot(rproc);
+
+ /*
* We're initiating an asynchronous firmware loading, so we can
* be built-in kernel code, without hanging the boot process.
*/