All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Dafna Hirschfeld <dhirschfeld@habana.ai>
Subject: [PATCH 8/9] habanalabs: move call to scrub_device_mem after ctx_fini
Date: Thu, 23 Jun 2022 23:42:11 +0300	[thread overview]
Message-ID: <20220623204212.1628709-8-ogabbay@kernel.org> (raw)
In-Reply-To: <20220623204212.1628709-1-ogabbay@kernel.org>

From: Dafna Hirschfeld <dhirschfeld@habana.ai>

In future ASICs, it would be possible to have a non-idle
device when context is released. We thus need to postpone the
scrubbing. Postpone it to hpriv release if reset is not executed
or to device late init if reset is executed.

Signed-off-by: Dafna Hirschfeld <dhirschfeld@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
---
 drivers/misc/habanalabs/common/context.c |  3 ---
 drivers/misc/habanalabs/common/device.c  | 16 ++++++++++++++--
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/habanalabs/common/context.c b/drivers/misc/habanalabs/common/context.c
index 60e3e3125fbc..a69c14405f41 100644
--- a/drivers/misc/habanalabs/common/context.c
+++ b/drivers/misc/habanalabs/common/context.c
@@ -106,9 +106,6 @@ static void hl_ctx_fini(struct hl_ctx *ctx)
 		hl_vm_ctx_fini(ctx);
 		hl_asid_free(hdev, ctx->asid);
 		hl_encaps_sig_mgr_fini(hdev, &ctx->sig_mgr);
-
-		/* Scrub both SRAM and DRAM */
-		hdev->asic_funcs->scrub_device_mem(hdev);
 	} else {
 		dev_dbg(hdev->dev, "closing kernel context\n");
 		hdev->asic_funcs->ctx_fini(ctx);
diff --git a/drivers/misc/habanalabs/common/device.c b/drivers/misc/habanalabs/common/device.c
index 0f804ecb6caa..1a4f3eb941a9 100644
--- a/drivers/misc/habanalabs/common/device.c
+++ b/drivers/misc/habanalabs/common/device.c
@@ -272,9 +272,15 @@ static void hpriv_release(struct kref *ref)
 	list_del(&hpriv->dev_node);
 	mutex_unlock(&hdev->fpriv_list_lock);
 
-	if ((hdev->reset_if_device_not_idle && !device_is_idle)
-			|| hdev->reset_upon_device_release)
+	if ((hdev->reset_if_device_not_idle && !device_is_idle) ||
+		hdev->reset_upon_device_release) {
 		hl_device_reset(hdev, HL_DRV_RESET_DEV_RELEASE);
+	} else {
+		int rc = hdev->asic_funcs->scrub_device_mem(hdev);
+
+		if (rc)
+			dev_err(hdev->dev, "failed to scrub memory from hpriv release (%d)\n", rc);
+	}
 
 	/* Now we can mark the compute_ctx as not active. Even if a reset is running in a different
 	 * thread, we don't care because the in_reset is marked so if a user will try to open
@@ -1459,6 +1465,12 @@ int hl_device_reset(struct hl_device *hdev, u32 flags)
 		}
 	}
 
+	rc = hdev->asic_funcs->scrub_device_mem(hdev);
+	if (rc) {
+		dev_err(hdev->dev, "scrub mem failed from device reset (%d)\n", rc);
+		return rc;
+	}
+
 	spin_lock(&hdev->reset_info.lock);
 	hdev->reset_info.is_in_soft_reset = false;
 
-- 
2.25.1


  parent reply	other threads:[~2022-06-23 20:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23 20:42 [PATCH 1/9] habanalabs: move memory_scrub_val to hdev struct Oded Gabbay
2022-06-23 20:42 ` [PATCH 2/9] habanalabs/gaudi: fix warning: var might be used uninitialized Oded Gabbay
2022-06-23 20:42 ` [PATCH 3/9] habanalabs/gaudi: fix a race condition causing DMAR error Oded Gabbay
2022-06-23 20:42 ` [PATCH 4/9] habanalabs: print if firmware is secured during load Oded Gabbay
2022-06-23 20:42 ` [PATCH 5/9] habanalabs: don't do memory scrubbing when unmapping Oded Gabbay
2022-06-23 20:42 ` [PATCH 6/9] habanalabs: don't send addr and size to scrub_device_mem cb Oded Gabbay
2022-06-23 20:42 ` [PATCH 7/9] habanalabs/gaudi: use memory_scrub_val from debugfs Oded Gabbay
2022-06-23 20:42 ` Oded Gabbay [this message]
2022-06-23 20:42 ` [PATCH 9/9] habanalabs: set default value for memory_scrub Oded Gabbay

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 \
    --in-reply-to=20220623204212.1628709-8-ogabbay@kernel.org \
    --to=ogabbay@kernel.org \
    --cc=dhirschfeld@habana.ai \
    --cc=linux-kernel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.