mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Tomer Tayar <ttayar@habana.ai>
Subject: [PATCH 14/26] habanalabs: skip device idle check in hpriv_release if in reset
Date: Thu,  8 Dec 2022 17:13:38 +0200	[thread overview]
Message-ID: <20221208151350.1833823-14-ogabbay@kernel.org> (raw)
In-Reply-To: <20221208151350.1833823-1-ogabbay@kernel.org>

From: Tomer Tayar <ttayar@habana.ai>

When user context is released and hpriv_release() is called, there is a
device idle status check, to understand if user has left the device not
idle and then a reset is required.

However, if the user process is killed because of device hard reset,
the device at this point would always be not idle, because the device
engines were already forcefully halted.

Modify hpriv_release() to skip the idle check if reset is in progress.

Signed-off-by: Tomer Tayar <ttayar@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
---
 drivers/misc/habanalabs/common/device.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/habanalabs/common/device.c b/drivers/misc/habanalabs/common/device.c
index afd9d4d46574..71f958a2e91b 100644
--- a/drivers/misc/habanalabs/common/device.c
+++ b/drivers/misc/habanalabs/common/device.c
@@ -428,8 +428,10 @@ static void hpriv_release(struct kref *ref)
 	 */
 	reset_device = hdev->reset_upon_device_release || hdev->reset_info.watchdog_active;
 
-	/* Unless device is reset in any case, check idle status and reset if device is not idle */
-	if (!reset_device && hdev->pdev && !hdev->pldm)
+	/* Check the device idle status and reset if not idle.
+	 * Skip it if already in reset, or if device is going to be reset in any case.
+	 */
+	if (!hdev->reset_info.in_reset && !reset_device && hdev->pdev && !hdev->pldm)
 		device_is_idle = hdev->asic_funcs->is_device_idle(hdev, idle_mask,
 							HL_BUSY_ENGINES_MASK_EXT_SIZE, NULL);
 	if (!device_is_idle) {
-- 
2.25.1


  parent reply	other threads:[~2022-12-08 15:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 15:13 [PATCH 01/26] habanalabs/gaudi2: fix BMON 3rd address range Oded Gabbay
2022-12-08 15:13 ` [PATCH 02/26] habanalabs: read binning info from preboot Oded Gabbay
2022-12-08 15:13 ` [PATCH 03/26] habanalabs: remove releasing of user threads from device release Oded Gabbay
2022-12-08 15:13 ` [PATCH 04/26] habanalabs: abort waiting user threads upon error Oded Gabbay
2022-12-08 15:13 ` [PATCH 05/26] habanalabs: don't notify user about clk throttling due to power Oded Gabbay
2022-12-08 15:13 ` [PATCH 06/26] habanalabs: don't allow user to destroy CB handle more than once Oded Gabbay
2022-12-08 15:13 ` [PATCH 07/26] habanalabs: use dev_dbg() when hl_mmap_mem_buf_get() fails Oded Gabbay
2022-12-08 15:13 ` [PATCH 08/26] habanalabs: make set_dram_properties an ASIC function Oded Gabbay
2022-12-08 15:13 ` [PATCH 09/26] habanalabs: fix double assignment in MMU V1 Oded Gabbay
2022-12-08 15:13 ` [PATCH 10/26] habanalabs: update DRAM props according to preboot data Oded Gabbay
2022-12-08 15:13 ` [PATCH 11/26] habanalabs/gaudi2: count interrupt causes Oded Gabbay
2022-12-08 15:13 ` [PATCH 12/26] habanalabs/gaudi2: remove duplicated event prints Oded Gabbay
2022-12-08 15:13 ` [PATCH 13/26] habanalabs: adjacent timestamps should be more accurate Oded Gabbay
2022-12-08 15:13 ` Oded Gabbay [this message]
2022-12-08 15:13 ` [PATCH 15/26] habanalabs/gaudi2: support abrupt device reset event Oded Gabbay
2022-12-08 15:13 ` [PATCH 16/26] habanalabs: define traces for COMMS protocol Oded Gabbay
2022-12-08 15:13 ` [PATCH 17/26] habanalabs: trace " Oded Gabbay
2022-12-08 15:13 ` [PATCH 18/26] habanalabs: set log level for descriptor validation to debug Oded Gabbay
2022-12-08 15:13 ` [PATCH 19/26] habanalabs: remove support to export dmabuf from handle Oded Gabbay
2022-12-08 15:13 ` [PATCH 20/26] habanalabs: helper function to validate export params Oded Gabbay
2022-12-08 15:13 ` [PATCH 21/26] habanalabs: modify export dmabuf API Oded Gabbay
2022-12-08 15:13 ` [PATCH 22/26] habanalabs: fix dmabuf to export only required size Oded Gabbay
2022-12-08 15:13 ` [PATCH 23/26] habanalabs: fix handling of wait CS for interrupting signals Oded Gabbay
2022-12-08 15:13 ` [PATCH 24/26] habanalabs: put fences in case of unexpected wait status Oded Gabbay
2022-12-08 15:13 ` [PATCH 25/26] habanalabs/gaudi2: wait for preboot ready if HW state is dirty Oded Gabbay
2022-12-08 15:13 ` [PATCH 26/26] habanalabs: fix wrong variable type used for vzalloc 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=20221208151350.1833823-14-ogabbay@kernel.org \
    --to=ogabbay@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ttayar@habana.ai \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®