* [PATCH 1/2] habanalabs: make the reset code more consistent
@ 2019-11-17 19:26 Oded Gabbay
2019-11-17 19:26 ` [PATCH 2/2] habanalabs: flush EQ workers in hard reset Oded Gabbay
0 siblings, 1 reply; 2+ messages in thread
From: Oded Gabbay @ 2019-11-17 19:26 UTC (permalink / raw)
To: linux-kernel, oshpigelman, ttayar; +Cc: gregkh
In the hl_device_reset we ask about the hard_reset argument when we want to
differentiate between soft and hard reset, except for three places where
we use "from_hard_reset_thread". Replace one of those locations with the
hard_reset argument as it is guaranteed that if we reached to that
line in the code during hard_reset, it is from a kernel thread.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Tomer Tayar <ttayar@habana.ai>
---
drivers/misc/habanalabs/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index 2f5a4da707e7..80205d8584ce 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -891,7 +891,7 @@ int hl_device_reset(struct hl_device *hdev, bool hard_reset,
* can't really exit until all its CSs are done, which is what we
* do in cs rollback
*/
- if (from_hard_reset_thread)
+ if (hard_reset)
device_kill_open_processes(hdev);
/* Release kernel context */
--
2.17.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* [PATCH 2/2] habanalabs: flush EQ workers in hard reset
2019-11-17 19:26 [PATCH 1/2] habanalabs: make the reset code more consistent Oded Gabbay
@ 2019-11-17 19:26 ` Oded Gabbay
0 siblings, 0 replies; 2+ messages in thread
From: Oded Gabbay @ 2019-11-17 19:26 UTC (permalink / raw)
To: linux-kernel, oshpigelman, ttayar; +Cc: gregkh
During hard-reset, there can be multiple events received from the H/W. For
each event, the driver opens a worker thread to handle it. For some of the
events, the driver will read/write registers in the code that handles the
event.
In case of hard-reset, we must prevent reads/writes to the registers during
the reset operation because the device might get stuck if that happens.
Therefore, flush the EQ workers before resetting the device (in hard-reset
only). Additional events won't arrive as we synced and disabled the
interrupts.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Tomer Tayar <ttayar@habana.ai>
---
drivers/misc/habanalabs/device.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index 80205d8584ce..b155e9549076 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -887,13 +887,19 @@ int hl_device_reset(struct hl_device *hdev, bool hard_reset,
/* Go over all the queues, release all CS and their jobs */
hl_cs_rollback_all(hdev);
- /* Kill processes here after CS rollback. This is because the process
- * can't really exit until all its CSs are done, which is what we
- * do in cs rollback
- */
- if (hard_reset)
+ if (hard_reset) {
+ /* Kill processes here after CS rollback. This is because the
+ * process can't really exit until all its CSs are done, which
+ * is what we do in cs rollback
+ */
device_kill_open_processes(hdev);
+ /* Flush the Event queue workers to make sure no other thread is
+ * reading or writing to registers during the reset
+ */
+ flush_workqueue(hdev->eq_wq);
+ }
+
/* Release kernel context */
if ((hard_reset) && (hl_ctx_put(hdev->kernel_ctx) == 1))
hdev->kernel_ctx = NULL;
--
2.17.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-11-17 19:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-17 19:26 [PATCH 1/2] habanalabs: make the reset code more consistent Oded Gabbay
2019-11-17 19:26 ` [PATCH 2/2] habanalabs: flush EQ workers in hard reset Oded Gabbay
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox