Linux-remoteproc Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
@ 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:44 ` [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop Evan Green
  0 siblings, 2 replies; 9+ messages in thread
From: Sibi Sankar @ 2020-06-02 16:32 UTC (permalink / raw)
  To: bjorn.andersson
  Cc: agross, linux-arm-msm, linux-remoteproc, linux-kernel, evgreen,
	ohad, rohitkr, Sibi Sankar, stable

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: stable@vger.kernel.org
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/remoteproc/qcom_q6v5.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 111a442c993c4..fd6fd36268d93 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -153,6 +153,8 @@ int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5)
 {
 	int ret;
 
+	q6v5->running = false;
+
 	qcom_smem_state_update_bits(q6v5->state,
 				    BIT(q6v5->stop_bit), BIT(q6v5->stop_bit));
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 2/2] remoteproc: qcom_q6v5_mss: Remove redundant running state
  2020-06-02 16:32 [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop Sibi Sankar
@ 2020-06-02 16:32 ` 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
  1 sibling, 2 replies; 9+ messages in thread
From: Sibi Sankar @ 2020-06-02 16:32 UTC (permalink / raw)
  To: bjorn.andersson
  Cc: agross, linux-arm-msm, linux-remoteproc, linux-kernel, evgreen,
	ohad, rohitkr, Sibi Sankar

Remove the redundant running state, as an equivalent is maintained in
the common q6v5 resource handling helpers.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/remoteproc/qcom_q6v5_mss.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index feb70283b6a21..702352cd66188 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -178,8 +178,6 @@ struct q6v5 {
 	int active_reg_count;
 	int proxy_reg_count;
 
-	bool running;
-
 	bool dump_mba_loaded;
 	unsigned long dump_segment_mask;
 	unsigned long dump_complete_mask;
@@ -1275,7 +1273,6 @@ static int q6v5_start(struct rproc *rproc)
 
 	/* Reset Dump Segment Mask */
 	qproc->dump_segment_mask = 0;
-	qproc->running = true;
 
 	return 0;
 
@@ -1290,8 +1287,6 @@ static int q6v5_stop(struct rproc *rproc)
 	struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
 	int ret;
 
-	qproc->running = false;
-
 	ret = qcom_q6v5_request_stop(&qproc->q6v5);
 	if (ret == -ETIMEDOUT)
 		dev_err(qproc->dev, "timed out on wait\n");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] remoteproc: qcom_q6v5_mss: Remove redundant running state
  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
  1 sibling, 0 replies; 9+ messages in thread
From: Evan Green @ 2020-06-02 17:39 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Andy Gross, linux-arm-msm, linux-remoteproc,
	LKML, Ohad Ben Cohen, rohitkr

On Tue, Jun 2, 2020 at 9:33 AM Sibi Sankar <sibis@codeaurora.org> wrote:
>
> Remove the redundant running state, as an equivalent is maintained in
> the common q6v5 resource handling helpers.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

This variable was written to and never read, sigh. Thanks for cleaning it up.

Reviewed-by: Evan Green <evgreen@chromium.org>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
  2020-06-02 16:32 [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop Sibi Sankar
  2020-06-02 16:32 ` [PATCH 2/2] remoteproc: qcom_q6v5_mss: Remove redundant running state Sibi Sankar
@ 2020-06-02 17:44 ` Evan Green
  2020-06-03  5:29   ` Sibi Sankar
  1 sibling, 1 reply; 9+ messages in thread
From: Evan Green @ 2020-06-02 17:44 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Andy Gross, linux-arm-msm, linux-remoteproc,
	LKML, Ohad Ben Cohen, rohitkr, stable

On Tue, Jun 2, 2020 at 9:33 AM Sibi Sankar <sibis@codeaurora.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: stable@vger.kernel.org
> Signed-off-by: Sibi Sankar <sibis@codeaurora.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?

I just worry this will mask real issues that happen during graceful shutdown.
-Evan

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
  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
  2020-06-03 22:33     ` Evan Green
  0 siblings, 1 reply; 9+ messages in thread
From: Sibi Sankar @ 2020-06-03  5:29 UTC (permalink / raw)
  To: Evan Green
  Cc: Bjorn Andersson, Andy Gross, linux-arm-msm, linux-remoteproc,
	LKML, Ohad Ben Cohen, rohitkr, stable, linux-kernel-owner

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 <sibis@codeaurora.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: stable@vger.kernel.org
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
  2020-06-03  5:29   ` Sibi Sankar
@ 2020-06-03 22:33     ` Evan Green
  2020-06-04 18:50       ` Sibi Sankar
  2020-07-28  6:19       ` Bjorn Andersson
  0 siblings, 2 replies; 9+ messages in thread
From: Evan Green @ 2020-06-03 22:33 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Andy Gross, linux-arm-msm, linux-remoteproc,
	LKML, Ohad Ben Cohen, rohitkr, stable, linux-kernel-owner

On Tue, Jun 2, 2020 at 10:29 PM Sibi Sankar <sibis@codeaurora.org> wrote:
>
> 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 <sibis@codeaurora.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: stable@vger.kernel.org
> >> Signed-off-by: Sibi Sankar <sibis@codeaurora.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.

So you're saying that the intention of the ->running check already in
q6v5_wdog_interrupt() was to allow either the stop-ack or wdog
interrupt to complete the stop. This patch just fixes a regression
introduced during the refactor.
This patch seems ok to me then. It still sort of seems like a bug that
the modem responds arbitrarily in one of two ways, even to a "harsh"
shutdown request.

I wasn't aware of QCOM_SYSMON. Reading it now, It seems like kind of a
lot... do I really need all this? Can I get by with just remoteproc
stops?
Anyway, for this patch:

Reviewed-by: Evan Green <evgreen@chromium.org>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
  2020-06-03 22:33     ` Evan Green
@ 2020-06-04 18:50       ` Sibi Sankar
  2020-07-28  6:19       ` Bjorn Andersson
  1 sibling, 0 replies; 9+ messages in thread
From: Sibi Sankar @ 2020-06-04 18:50 UTC (permalink / raw)
  To: Evan Green
  Cc: Bjorn Andersson, Andy Gross, linux-arm-msm, linux-remoteproc,
	LKML, Ohad Ben Cohen, rohitkr, stable, linux-kernel-owner

On 2020-06-04 04:03, Evan Green wrote:
> On Tue, Jun 2, 2020 at 10:29 PM Sibi Sankar <sibis@codeaurora.org> 
> wrote:
>> 
>> 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 <sibis@codeaurora.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: stable@vger.kernel.org
>> >> Signed-off-by: Sibi Sankar <sibis@codeaurora.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.
> 
> So you're saying that the intention of the ->running check already in
> q6v5_wdog_interrupt() was to allow either the stop-ack or wdog
> interrupt to complete the stop. This patch just fixes a regression
> introduced during the refactor.
> This patch seems ok to me then. It still sort of seems like a bug that
> the modem responds arbitrarily in one of two ways, even to a "harsh"
> shutdown request.
> 
> I wasn't aware of QCOM_SYSMON. Reading it now, It seems like kind of a

TL;DR
Sysmon when enabled adds a lookup
for qmi service 43 (Subsystem
control service). When we shutdown
the modem, we send a SSCTL_SHUTDOWN_REQ
to the service and the modem responds
with a shutdown-ack interrupt. If you
have rmtfs running with -v turned on
you can notice pending efs transactions
being completed followed by a bye I guess.

> lot... do I really need all this? Can I get by with just remoteproc
> stops?
> Anyway, for this patch:
> 
> Reviewed-by: Evan Green <evgreen@chromium.org>

Thanks for the review!

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
  2020-06-03 22:33     ` Evan Green
  2020-06-04 18:50       ` Sibi Sankar
@ 2020-07-28  6:19       ` Bjorn Andersson
  1 sibling, 0 replies; 9+ messages in thread
From: Bjorn Andersson @ 2020-07-28  6:19 UTC (permalink / raw)
  To: Evan Green
  Cc: Sibi Sankar, Andy Gross, linux-arm-msm, linux-remoteproc, LKML,
	Ohad Ben Cohen, rohitkr, stable, linux-kernel-owner

On Wed 03 Jun 15:33 PDT 2020, Evan Green wrote:

> On Tue, Jun 2, 2020 at 10:29 PM Sibi Sankar <sibis@codeaurora.org> wrote:
> >
> > 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 <sibis@codeaurora.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: stable@vger.kernel.org
> > >> Signed-off-by: Sibi Sankar <sibis@codeaurora.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.
> 
> So you're saying that the intention of the ->running check already in
> q6v5_wdog_interrupt() was to allow either the stop-ack or wdog
> interrupt to complete the stop. This patch just fixes a regression
> introduced during the refactor.
> This patch seems ok to me then. It still sort of seems like a bug that
> the modem responds arbitrarily in one of two ways, even to a "harsh"
> shutdown request.
> 

I think the patch properly fixes this regression, but I share your
concern about the fact that we omit an entire category of
shutdown-related crashes from being reported.

The problem I presume with the current behavior is that the shutdown
will race against the crash handler - which might boot the remoteproc up
again while the shutdown is progressing.

So I'm okay with this fix for the immediate problem, but think it would
be nice if we could report the issue appropriately and then finalize the
shutdown.

> I wasn't aware of QCOM_SYSMON. Reading it now, It seems like kind of a
> lot... do I really need all this? Can I get by with just remoteproc
> stops?

It used to be that we set one bit in shared memory and sent an
interrupt and the modem would set another bit and interrupt us back when
it was done shutting down...

> Anyway, for this patch:
> 
> Reviewed-by: Evan Green <evgreen@chromium.org>

Thanks,
Bjorn

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] remoteproc: qcom_q6v5_mss: Remove redundant running state
  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
  1 sibling, 0 replies; 9+ messages in thread
From: Bjorn Andersson @ 2020-07-28  6:20 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: agross, linux-arm-msm, linux-remoteproc, linux-kernel, evgreen,
	ohad, rohitkr

On Tue 02 Jun 09:32 PDT 2020, Sibi Sankar wrote:

> Remove the redundant running state, as an equivalent is maintained in
> the common q6v5 resource handling helpers.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index feb70283b6a21..702352cd66188 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -178,8 +178,6 @@ struct q6v5 {
>  	int active_reg_count;
>  	int proxy_reg_count;
>  
> -	bool running;
> -
>  	bool dump_mba_loaded;
>  	unsigned long dump_segment_mask;
>  	unsigned long dump_complete_mask;
> @@ -1275,7 +1273,6 @@ static int q6v5_start(struct rproc *rproc)
>  
>  	/* Reset Dump Segment Mask */
>  	qproc->dump_segment_mask = 0;
> -	qproc->running = true;
>  
>  	return 0;
>  
> @@ -1290,8 +1287,6 @@ static int q6v5_stop(struct rproc *rproc)
>  	struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
>  	int ret;
>  
> -	qproc->running = false;
> -
>  	ret = qcom_q6v5_request_stop(&qproc->q6v5);
>  	if (ret == -ETIMEDOUT)
>  		dev_err(qproc->dev, "timed out on wait\n");
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-02 16:32 [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop 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
2020-06-03 22:33     ` Evan Green
2020-06-04 18:50       ` Sibi Sankar
2020-07-28  6:19       ` Bjorn Andersson

Linux-remoteproc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-remoteproc/0 linux-remoteproc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-remoteproc linux-remoteproc/ https://lore.kernel.org/linux-remoteproc \
		linux-remoteproc@vger.kernel.org
	public-inbox-index linux-remoteproc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-remoteproc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git