From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Maria Yu <quic_aiquny@quicinc.com>
Cc: linux-remoteproc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_clew@quicinc.com
Subject: Re: [PATCH v4] remoteproc: core: do pm relax when in RPROC_OFFLINE
Date: Wed, 12 Oct 2022 14:43:44 -0600 [thread overview]
Message-ID: <20221012204344.GA1178915@p14s> (raw)
In-Reply-To: <1663312351-28476-1-git-send-email-quic_aiquny@quicinc.com>
Please add what has changed from one version to another, either in a cover
letter or after the "Signed-off-by". There are many examples on how to do that
on the mailing list.
On Fri, Sep 16, 2022 at 03:12:31PM +0800, Maria Yu wrote:
> RPROC_OFFLINE state indicate there is no recovery process
> is in progress and no chance to do the pm_relax.
> Because when recovering from crash, rproc->lock is held and
> state is RPROC_CRASHED -> RPROC_OFFLINE -> RPROC_RUNNING,
> and then unlock rproc->lock.
You are correct - because the lock is held rproc->state should be set to RPROC_RUNNING
when rproc_trigger_recovery() returns. If that is not the case then something
went wrong.
Function rproc_stop() sets rproc->state to RPROC_OFFLINE just before returning,
so we know the remote processor was stopped. Therefore if rproc->state is set
to RPROC_OFFLINE something went wrong in either request_firmware() or
rproc_start(). Either way the remote processor is offline and the system probably
in an unknown/unstable. As such I don't see how calling pm_relax() can help
things along.
I suggest spending time understanding what leads to the failure when recovering
from a crash and address that problem(s).
Thanks,
Mathieu
> When the state is in RPROC_OFFLINE it means separate request
> of rproc_stop was done and no need to hold the wakeup source
> in crash handler to recover any more.
>
> Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index e5279ed9a8d7..6bc7b8b7d01e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1956,6 +1956,17 @@ static void rproc_crash_handler_work(struct work_struct *work)
> if (rproc->state == RPROC_CRASHED || rproc->state == RPROC_OFFLINE) {
> /* handle only the first crash detected */
> mutex_unlock(&rproc->lock);
> + /*
> + * RPROC_OFFLINE state indicate there is no recovery process
> + * is in progress and no chance to have pm_relax in place.
> + * Because when recovering from crash, rproc->lock is held and
> + * state is RPROC_CRASHED -> RPROC_OFFLINE -> RPROC_RUNNING,
> + * and then unlock rproc->lock.
> + * RPROC_OFFLINE is only an intermediate state in recovery
> + * process.
> + */
> + if (rproc->state == RPROC_OFFLINE)
> + pm_relax(rproc->dev.parent);
> return;
> }
>
> --
> 2.7.4
>
next prev parent reply other threads:[~2022-10-12 20:44 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-09 8:33 [PATCH v1] remoteproc: core: do pm relax when not first crash Maria Yu
2022-09-09 19:23 ` Mathieu Poirier
2022-09-13 11:03 ` Aiqun(Maria) Yu
2022-09-15 10:04 ` [PATCH v2] remoteproc: core: do pm relax when in RPROC_OFFLINE Maria Yu
2022-09-15 12:47 ` Mukesh Ojha
2022-09-16 1:34 ` Aiqun(Maria) Yu
2022-09-16 1:36 ` [PATCH v3] " Maria Yu
2022-09-16 7:12 ` [PATCH v4] " Maria Yu
2022-09-16 8:47 ` Mukesh Ojha
2022-10-12 20:43 ` Mathieu Poirier [this message]
2022-10-13 1:40 ` Aiqun(Maria) Yu
2022-10-13 17:34 ` Mathieu Poirier
2022-10-13 18:03 ` Mathieu Poirier
2022-10-20 5:52 ` Aiqun(Maria) Yu
2022-10-21 19:34 ` Mathieu Poirier
2022-10-24 3:17 ` Aiqun(Maria) Yu
2022-10-28 15:31 ` Arnaud POULIQUEN
2022-10-31 1:08 ` Aiqun(Maria) Yu
2022-11-01 20:11 ` Mathieu Poirier
2022-11-02 10:53 ` Aiqun(Maria) Yu
2022-11-02 18:03 ` Mathieu Poirier
2022-11-03 2:03 ` Aiqun(Maria) Yu
2022-11-04 15:59 ` Mathieu Poirier
2022-11-07 1:14 ` Aiqun(Maria) Yu
2022-11-10 20:50 ` Mathieu Poirier
2022-11-11 0:52 ` Aiqun(Maria) Yu
2022-11-14 21:18 ` Mathieu Poirier
2022-11-15 1:30 ` Aiqun(Maria) Yu
2022-11-18 18:52 ` Mathieu Poirier
2022-11-21 1:43 ` Aiqun(Maria) Yu
2022-11-25 18:37 ` Mathieu Poirier
2022-11-28 2:18 ` Aiqun(Maria) Yu
2022-12-01 23:00 ` Mathieu Poirier
2022-12-02 1:17 ` Aiqun(Maria) Yu
2022-09-16 17:05 ` [PATCH v1] remoteproc: core: do pm relax when not first crash Mathieu Poirier
2022-09-19 0:54 ` Aiqun(Maria) Yu
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=20221012204344.GA1178915@p14s \
--to=mathieu.poirier@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=quic_aiquny@quicinc.com \
--cc=quic_clew@quicinc.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.