Messages in this thread | | | Date | Tue, 13 Sep 2022 19:03:32 +0800 | Subject | Re: [PATCH v1] remoteproc: core: do pm relax when not first crash | From | "Aiqun(Maria) Yu" <> |
| |
Hi Mathieu,
pm_awake and pm_relax needed to be used as a pair. There is chance that pm_relax is not being called, and make the device always in cannot suspend state.
On 9/10/2022 3:23 AM, Mathieu Poirier wrote: > Hi Maria, > > On Fri, Sep 09, 2022 at 04:33:33PM +0800, Maria Yu wrote: >> Even if it is not first crash, need to relax the pm >> wakelock otherwise the device will stay awake. >> > > The goal is exactly to keep the device awake... > >> Signed-off-by: Maria Yu <quic_aiquny@quicinc.com> >> --- >> drivers/remoteproc/remoteproc_core.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c >> index e5279ed9a8d7..30078043e939 100644 >> --- a/drivers/remoteproc/remoteproc_core.c >> +++ b/drivers/remoteproc/remoteproc_core.c >> @@ -1956,6 +1956,7 @@ 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); >> + pm_relax(rproc->dev.parent); > > If we are here it means that rproc_crash_handler_work() has already been called > _and_ that a recovery is in process. When the first crash handler completes > pm_relax() will be called and the device will go to sleep as expected. If the rproc->state cannot be changed to running state, the device will always be awake from this return. Also APROC_OFFLINE state can be given in other path like an shutdown request is issued.
While this patch is not considering carefully as well, I think I need to upload a new patchset with an ordered workqueue to make each work have each pm_relax before return. what do you think? > > Thanks, > Mathieu > >> return; >> } >> >> -- >> 2.7.4 >>
-- Thx and BRs, Aiqun(Maria) Yu
| |