dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: dri-devel@lists.freedesktop.org
Cc: Tomer Tayar <ttayar@habana.ai>
Subject: [PATCH 01/12] accel/habanalabs: prevent immediate hard reset due to 2 adjacent H/W events
Date: Thu,  8 Jun 2023 16:38:38 +0300	[thread overview]
Message-ID: <20230608133849.2739411-1-ogabbay@kernel.org> (raw)

From: Tomer Tayar <ttayar@habana.ai>

When a H/W event is received while a user is registered to events, no
immediate hard reset will happen, and instead the user will be notified
and will have some time to handle it and eventually release the
device, after which the reset will be done.
If a user, as part of the handling and as part of the cleanup steps
towards releasing the device, unregisters from receiving those events,
and at that time an adjacent H/W event is received, it will be assumed
that the user is not registered to events and thus an immediate hard
reset is required.

To prevent such an unwanted immediate reset, modify the driver to
perform it if the user is not registered to events AND we don't already
have a pending reset for a previous H/W event.

Signed-off-by: Tomer Tayar <ttayar@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
---
 drivers/accel/habanalabs/common/device.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/accel/habanalabs/common/device.c b/drivers/accel/habanalabs/common/device.c
index b97339d1f7c6..1e61e79c42e5 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -1916,7 +1916,16 @@ int hl_device_cond_reset(struct hl_device *hdev, u32 flags, u64 event_mask)
 	}
 
 	ctx = hl_get_compute_ctx(hdev);
-	if (!ctx || !ctx->hpriv->notifier_event.eventfd)
+	if (!ctx)
+		goto device_reset;
+
+	/*
+	 * There is no point in postponing the reset if user is not registered for events.
+	 * However if no eventfd_ctx exists but the device release watchdog is already scheduled, it
+	 * just implies that user has unregistered as part of handling a previous event. In this
+	 * case an immediate reset is not required.
+	 */
+	if (!ctx->hpriv->notifier_event.eventfd && !hdev->reset_info.watchdog_active)
 		goto device_reset;
 
 	/* Schedule the device release watchdog work unless reset is already in progress or if the
-- 
2.40.1


             reply	other threads:[~2023-06-08 13:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08 13:38 Oded Gabbay [this message]
2023-06-08 13:38 ` [PATCH 02/12] accel/habanalabs: update pending reset flags with new reset requests Oded Gabbay
2023-06-08 13:38 ` [PATCH 03/12] accel/habanalabs: notify user about undefined opcode event Oded Gabbay
2023-06-08 13:38 ` [PATCH 04/12] accel/habanalabs: print task name and request code upon ioctl failure Oded Gabbay
2023-06-08 13:38 ` [PATCH 05/12] accel/habanalabs: print task name upon creation of a user context Oded Gabbay
2023-06-08 13:38 ` [PATCH 06/12] accel/habanalabs: set device status 'malfunction' while in rmmod Oded Gabbay
2023-06-08 13:38 ` [PATCH 07/12] accel/habanalabs: stop fetching MME SBTE error cause Oded Gabbay
2023-06-08 13:38 ` [PATCH 08/12] accel/habanalabs: handle arc farm razwi Oded Gabbay
2023-06-08 13:38 ` [PATCH 09/12] accel/habanalabs: fix standalone preboot descriptor request Oded Gabbay
2023-06-08 13:38 ` [PATCH 10/12] accel/habanalabs: print return code when process termination fails Oded Gabbay
2023-06-08 13:38 ` [PATCH 11/12] accel/habanalabs: call put_pid after hpriv list is updated Oded Gabbay
2023-06-08 13:38 ` [PATCH 12/12] accel/habanalabs: rename fd_list to hpriv_list 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=20230608133849.2739411-1-ogabbay@kernel.org \
    --to=ogabbay@kernel.org \
    --cc=dri-devel@lists.freedesktop.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