aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSuman Anna2017-03-09 20:35:20 -0600
committerSuman Anna2019-03-11 12:00:24 -0500
commit81d5a33c5aa79a15d3e1ebca8c5f226bb68b954a (patch)
treecc74c6aeb8d7d43e6d76dca86840e8ec51b2e4ea
parent7f275d21e2401b65379fd6fa9744cbea7f92fe2f (diff)
downloadremoteproc-81d5a33c5aa79a15d3e1ebca8c5f226bb68b954a.tar.gz
remoteproc-81d5a33c5aa79a15d3e1ebca8c5f226bb68b954a.tar.xz
remoteproc-81d5a33c5aa79a15d3e1ebca8c5f226bb68b954a.zip
remoteproc: fix multiple back-to-back error recoveries
The remoteproc core uses a dedicated work item per remote processor to perform an error recovery of that processor. This work item is always scheduled upon notification of an error at the moment. The error recovery process itself is performed when the workqueue gets scheduled and executes the work function, but an error recovery needs to be performed only once if there are multiple notifications while an existing error recovery is in progress. Fix this by adding a check to make sure the remote processor error recovery work item is not already running or scheduled. This fixes an issue with error recovery upon MMU Faults on OMAP IPU remote processors. An MMU fault on OMAP IPU sends two error notifications - one a direct interrupt from the MMU, and the second a mailbox-based crash notification after the remote processor has collected some backtrace. The mailbox based interrupt mechanism, added in commit 7f275d21e240 ("remoteproc/omap: report device exceptions and trigger recovery"), is used for Attribute MMU (AMMU) faults and other internal exceptions on the IPU. The backtrace collection on the IPU remote processor is triggered by the same interrupt which cannot be differentiated between an MMU fault and an AMMU fault. The remoteproc core changes in 4.9 kernel around the boot sequences has now caused the second notification to trigger a secondary error recovery, which was avoided in previous kernels due to the event detection in the work-function itself. The newer code sequences changes the timing w.r.t previous kernels where the recovery process was performed a bit later due to the asynchronous firmware loading. Signed-off-by: Suman Anna <s-anna@ti.com>
-rw-r--r--drivers/remoteproc/remoteproc_core.c5
1 files changed, 3 insertions, 2 deletions
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 30e02198bb30..9e33dbee6e20 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -2037,8 +2037,9 @@ void rproc_report_crash(struct rproc *rproc, enum rproc_crash_type type)
2037 dev_err(&rproc->dev, "crash detected in %s: type %s\n", 2037 dev_err(&rproc->dev, "crash detected in %s: type %s\n",
2038 rproc->name, rproc_crash_to_string(type)); 2038 rproc->name, rproc_crash_to_string(type));
2039 2039
2040 /* create a new task to handle the error */ 2040 /* create a new task to handle the error if not scheduled already */
2041 schedule_work(&rproc->crash_handler); 2041 if (!work_busy(&rproc->crash_handler))
2042 schedule_work(&rproc->crash_handler);
2042} 2043}
2043EXPORT_SYMBOL(rproc_report_crash); 2044EXPORT_SYMBOL(rproc_report_crash);
2044 2045