On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> Refactor function rproc_trigger_auto_boot() so that it can deal with
> scenarios where the remote processor is already running. As such give
> it a new name to better represent the capabilities and add a call to
> rproc_boot() if instructed by the platform code to synchronise with the
> remote processor rather than boot it from scratch.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>
> ---
> drivers/remoteproc/remoteproc_core.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index e90a21de9de1..9de0e2b7ca2b 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1457,10 +1457,17 @@ static void rproc_auto_boot_callback(const struct firmware *fw, void *context)
> release_firmware(fw);
> }
>
> -static int rproc_trigger_auto_boot(struct rproc *rproc)
> +static int rproc_trigger_auto_initiate(struct rproc *rproc)
> {
> int ret;
>
> + /*
> + * If the remote processor is already booted, all we need to do is
> + * synchronise it it. No point in dealing with a firmware image.
typo: suppress double "it" and double space.
> + */
> + if (rproc_needs_syncing(rproc))
> + return rproc_boot(rproc);
> +
> /*
> * We're initiating an asynchronous firmware loading, so we can
> * be built-in kernel code, without hanging the boot process.
> @@ -1971,9 +1978,12 @@ int rproc_add(struct rproc *rproc)
> /* create debugfs entries */
> rproc_create_debug_dir(rproc);
>
> - /* if rproc is marked always-on, request it to boot */
> + /*
> + * If the auto boot flag is set, request to boot the remote
> + * processor or synchronise with it.
> + */
> if (rproc->auto_boot) {
> - ret = rproc_trigger_auto_boot(rproc);
> + ret = rproc_trigger_auto_initiate(rproc);
> if (ret < 0)
> return ret;
> }
>
