All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] remoteproc: block premature rproc booting
Date: Thu, 24 May 2012 02:15:54 -0700	[thread overview]
Message-ID: <4FBDFC4A.1060602@codeaurora.org> (raw)
In-Reply-To: <1337687472-23009-1-git-send-email-ohad@wizery.com>

On 5/22/2012 4:51 AM, Ohad Ben-Cohen wrote:
> When an rproc instance is registered, remoteproc asynchronously
> loads its firmware in order to tell which vdevs it supports.
>
> Later on those vdevs are registered, and when probed, their drivers
> usually trigger powering on of the remote processor.
>
> OTOH, non-standard scenarios might involve early invocation of
> rproc_boot even before the asynchronous fw loading has completed.
>
> We're not sure we really want to support those scenarios, but right
> now we do (e.g. via rproc_get_by_name), so let's simply fix this race
> by blocking those premature rproc_boot() flows until the async fw
> loading is completed.
>
> Reported-and-tested-by: Sjur Brandeland <sjur.brandeland@stericsson.com>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
>  drivers/remoteproc/remoteproc_core.c |   12 ++++++++++++
>  1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 40e2b2d..464ea4f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1141,6 +1141,18 @@ int rproc_boot(struct rproc *rproc)
>  
>  	dev = rproc->dev;
>  
> +	/*
> +	 * if asynchronoush fw loading is underway, wait up to 65 secs
> +	 * (just a bit more than the firmware request's timeout)
> +	 */
> +	ret = wait_for_completion_interruptible_timeout(
> +					&rproc->firmware_loading_complete,
> +					msecs_to_jiffies(65000));

The request_firmware timeout is defaulted to 60 seconds but not
necessarily 60 if the user has changed the timeout in sysfs.

Why does this need to be a timeout at all? Presumably
request_firmware_nowait() in rproc_register() will timeout and complete
the firmware_loading_complete completion variable. Would it suffice to
have some new rproc->state like RPROC_UNKNOWN that we set in
rproc_register() before adding it to the list of rprocs? If we find the
firmware then we set it to RPROC_READY or RPROC_REGISTERED? Then we
wait_for_completion() and check the state, failing if it's still in the
unknown state.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] remoteproc: block premature rproc booting
Date: Thu, 24 May 2012 02:15:54 -0700	[thread overview]
Message-ID: <4FBDFC4A.1060602@codeaurora.org> (raw)
In-Reply-To: <1337687472-23009-1-git-send-email-ohad@wizery.com>

On 5/22/2012 4:51 AM, Ohad Ben-Cohen wrote:
> When an rproc instance is registered, remoteproc asynchronously
> loads its firmware in order to tell which vdevs it supports.
>
> Later on those vdevs are registered, and when probed, their drivers
> usually trigger powering on of the remote processor.
>
> OTOH, non-standard scenarios might involve early invocation of
> rproc_boot even before the asynchronous fw loading has completed.
>
> We're not sure we really want to support those scenarios, but right
> now we do (e.g. via rproc_get_by_name), so let's simply fix this race
> by blocking those premature rproc_boot() flows until the async fw
> loading is completed.
>
> Reported-and-tested-by: Sjur Brandeland <sjur.brandeland@stericsson.com>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
>  drivers/remoteproc/remoteproc_core.c |   12 ++++++++++++
>  1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 40e2b2d..464ea4f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1141,6 +1141,18 @@ int rproc_boot(struct rproc *rproc)
>  
>  	dev = rproc->dev;
>  
> +	/*
> +	 * if asynchronoush fw loading is underway, wait up to 65 secs
> +	 * (just a bit more than the firmware request's timeout)
> +	 */
> +	ret = wait_for_completion_interruptible_timeout(
> +					&rproc->firmware_loading_complete,
> +					msecs_to_jiffies(65000));

The request_firmware timeout is defaulted to 60 seconds but not
necessarily 60 if the user has changed the timeout in sysfs.

Why does this need to be a timeout at all? Presumably
request_firmware_nowait() in rproc_register() will timeout and complete
the firmware_loading_complete completion variable. Would it suffice to
have some new rproc->state like RPROC_UNKNOWN that we set in
rproc_register() before adding it to the list of rprocs? If we find the
firmware then we set it to RPROC_READY or RPROC_REGISTERED? Then we
wait_for_completion() and check the state, failing if it's still in the
unknown state.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  reply	other threads:[~2012-05-24  9:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-22 11:51 [PATCH] remoteproc: block premature rproc booting Ohad Ben-Cohen
2012-05-22 11:51 ` Ohad Ben-Cohen
2012-05-22 11:51 ` Ohad Ben-Cohen
2012-05-24  9:15 ` Stephen Boyd [this message]
2012-05-24  9:15   ` Stephen Boyd
2012-05-24 20:11   ` Ohad Ben-Cohen
2012-05-24 20:11     ` Ohad Ben-Cohen
2012-06-04 21:23     ` Stephen Boyd
2012-06-04 21:23       ` Stephen Boyd
2012-06-05 10:57       ` Ohad Ben-Cohen
2012-06-05 10:57         ` Ohad Ben-Cohen
2012-06-06  3:25         ` Stephen Boyd
2012-06-06  3:25           ` Stephen Boyd
2012-06-06  5:44           ` Ohad Ben-Cohen
2012-06-06  5:44             ` Ohad Ben-Cohen
2012-06-06  5:44             ` Ohad Ben-Cohen
2012-07-02 12:25         ` Ohad Ben-Cohen
2012-07-02 12:25           ` Ohad Ben-Cohen
2012-07-02 15:15           ` Sjur BRENDELAND
2012-07-02 15:15             ` Sjur BRENDELAND
2012-07-02 15:19             ` Ohad Ben-Cohen
2012-07-02 15:19               ` Ohad Ben-Cohen
     [not found] <81C3A93C17462B4BBD7E272753C10579232F86B623@EXDCVYMBSTM005.EQ1STM.local>
2012-06-29 14:56 ` Ohad Ben-Cohen
2012-07-02  6:08   ` Preetham-rao K
2012-07-02 21:10     ` Guzman Lugo, Fernando

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBDFC4A.1060602@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ohad@wizery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.