From: Sibi Sankar <firstname.lastname@example.org> To: Evan Green <email@example.com> Cc: Bjorn Andersson <firstname.lastname@example.org>, Andy Gross <email@example.com>, linux-arm-msm <firstname.lastname@example.org>, email@example.com, LKML <firstname.lastname@example.org>, Ohad Ben Cohen <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop Date: Wed, 03 Jun 2020 10:59:42 +0530 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CAE=gft7sbh_S_GiRohtMmdMN9JzQhG0m3bUerwrmzhjmXucGKw@mail.gmail.com> Evan, Thanks for taking time to review the series. On 2020-06-02 23:14, Evan Green wrote: > On Tue, Jun 2, 2020 at 9:33 AM Sibi Sankar <firstname.lastname@example.org> > wrote: >> >> Sometimes the stop triggers a watchdog rather than a stop-ack. Update >> the running state to false on requesting stop to skip the watchdog >> instead. >> >> Error Logs: >> $ echo stop > /sys/class/remoteproc/remoteproc0/state >> ipa 1e40000.ipa: received modem stopping event >> remoteproc-modem: watchdog received: sys_m_smsm_mpss.c:291:APPS force >> stop >> qcom-q6v5-mss 4080000.remoteproc-modem: port failed halt >> ipa 1e40000.ipa: received modem offline event >> remoteproc0: stopped remote processor 4080000.remoteproc-modem >> >> Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource >> handling") >> Cc: email@example.com >> Signed-off-by: Sibi Sankar <firstname.lastname@example.org> >> --- > > Are you sure you want to tolerate this behavior from MSS? This is a > graceful shutdown, modem shouldn't have a problem completing the > proper handshake. If they do, isn't that a bug on the modem side? The graceful shutdown is achieved though sysmon (enabled using CONFIG_QCOM_SYSMON). When sysmon is enabled we get a shutdown-ack when we try to stop the modem, post which request stop is a basically a nop. Request stop is done to force stop the modem during failure cases (like rmtfs is not running and so on) and we do want to mask the wdog that we get during this scenario ( The locking already prevents the servicing of the wdog during shutdown, the check just prevents the scheduling of crash handler and err messages associated with it). Also this check was always present and was missed during common q6v5 resource helper migration, hence the unused running state in mss driver. > > I just worry this will mask real issues that happen during graceful > shutdown. > -Evan -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2020-06-03 5:30 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-02 16:32 Sibi Sankar 2020-06-02 16:32 ` [PATCH 2/2] remoteproc: qcom_q6v5_mss: Remove redundant running state Sibi Sankar 2020-06-02 17:39 ` Evan Green 2020-07-28 6:20 ` Bjorn Andersson 2020-06-02 17:44 ` [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop Evan Green 2020-06-03 5:29 ` Sibi Sankar [this message] 2020-06-03 22:33 ` Evan Green 2020-06-04 18:50 ` Sibi Sankar 2020-07-28 6:19 ` Bjorn Andersson
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop' \ /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
This is a public inbox, see mirroring instructions on how to clone and mirror all data and code used for this inbox