From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Maarten Lankhorst <dev@lankhorst.se>, intel-xe@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@kernel.org>,
David Lechner <dlechner@baylibre.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [PATCH-resent-to-correct-ml 3/8] drm/xe: Add scoped guards for xe_force_wake
Date: Tue, 4 Feb 2025 17:30:32 +0100 [thread overview]
Message-ID: <2ced99ce-fd3e-4966-b093-c193b6c8b400@intel.com> (raw)
In-Reply-To: <20250204132238.162608-4-dev@lankhorst.se>
Hi Maarten,
On 04.02.2025 14:22, Maarten Lankhorst wrote:
> Instead of finding bugs where we may or may not release force_wake, I've
> decided to be inspired by the spinlock guards, and use the same ones to
> do xe_force_wake handling.
You may want to take a look at [1], which was based on [2], that
introduce fw guard class (and it was already acked and reviewed).
Merging was postponed only due to a request to prepare larger series
that would convert all existing usages to the new model.
And similar guard approach for our RPM was proposed in [3]
Michal
[1] https://patchwork.freedesktop.org/series/141516/
[2] https://patchwork.freedesktop.org/series/134958/
[3] https://patchwork.freedesktop.org/series/134955/
>
> Examples are added as documentation in xe_force_wake.c
>
> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
> ---
> drivers/gpu/drm/xe/xe_force_wake.c | 51 ++++++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_force_wake.h | 15 +++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_force_wake.c b/drivers/gpu/drm/xe/xe_force_wake.c
> index 4f6784e5abf88..805c19f6de9e7 100644
> --- a/drivers/gpu/drm/xe/xe_force_wake.c
> +++ b/drivers/gpu/drm/xe/xe_force_wake.c
> @@ -16,6 +16,57 @@
>
> #define XE_FORCE_WAKE_ACK_TIMEOUT_MS 50
>
> +/**
> + * DOC: Force wake handling
> + *
> + * Traditionally, the force wake handling has been done using the error prone
> + * set of calls:
> + *
> + * int func(struct xe_force_wake *fw)
> + * {
> + * unsigned int fw_ref = xe_force_wake_get(fw, XE_FORCEWAKE_ALL);
> + * if (!fw_ref)
> + * return -ETIMEDOUT;
> + *
> + * err = do_something();
> + *
> + * xe_force_wake_put(fw, fw_ref);
> + * return err;
> + * }
> + *
> + * A new, failure-safe approach is by using the scoped helpers,
> + * which changes the function to this:
> + *
> + * int func(struct xe_force_wake *fw)
> + * {
> + * scoped_cond_guard(xe_force_wake_get, return -ETIMEDOUT, fw, XE_FORCEWAKE_ALL) {
> + * return do_something();
> + * }
> + * }
> + *
> + * For completeness, the following options also work:
> + * void func(struct xe_force_wake *fw)
> + * {
> + * scoped_guard(xe_force_wake_get, fw, XE_FORCEWAKE_ALL) {
> + * do_something_only_if_fw_acquired();
> + * }
> + * }
> + *
> + * You can use xe_force_wake instead of force_wake_get, if the code
> + * must run but errors acquiring ignored:
> + * void func(struct xe_force_wake *fw)
> + * {
> + * scoped_guard(xe_force_wake, fw, XE_FORCEWAKE_ALL) {
> + * always_do_something_maybe_fw();
> + * }
> + *
> + * do_something_no_fw();
> + *
> + * guard(xe_force_wake)(fw, XE_FORCEWAKE_ALL);
> + * always_do_something_maybe_fw();
> + * }
> + */
> +
> static const char *str_wake_sleep(bool wake)
> {
> return wake ? "wake" : "sleep";
> diff --git a/drivers/gpu/drm/xe/xe_force_wake.h b/drivers/gpu/drm/xe/xe_force_wake.h
> index 0e3e84bfa51c3..0fb1baae0a3a3 100644
> --- a/drivers/gpu/drm/xe/xe_force_wake.h
> +++ b/drivers/gpu/drm/xe/xe_force_wake.h
> @@ -9,6 +9,8 @@
> #include "xe_assert.h"
> #include "xe_force_wake_types.h"
>
> +#include <linux/cleanup.h>
> +
> struct xe_gt;
>
> void xe_force_wake_init_gt(struct xe_gt *gt,
> @@ -61,4 +63,17 @@ xe_force_wake_ref_has_domain(unsigned int fw_ref, enum xe_force_wake_domains dom
> return fw_ref & domain;
> }
>
> +DEFINE_LOCK_GUARD_1(xe_force_wake, struct xe_force_wake,
> + _T->fw_ref = xe_force_wake_get(_T->lock, domain),
> + xe_force_wake_put(_T->lock, _T->fw_ref),
> + unsigned int fw_ref, enum xe_force_wake_domains domain);
> +
> +DEFINE_LOCK_GUARD_1_COND(xe_force_wake, _get,
> + _T->fw_ref = xe_force_wake_get_all(_T->lock, domain),
> + enum xe_force_wake_domains domain);
> +
> +/* Only useful for guard xe_force_wake, guard xe_force_wake_get gets all or nothing */
> +#define xe_force_wake_scope_has_domain(domain) \
> + (xe_force_wake_ref_has_domain(scope.fw_ref, domain))
> +
> #endif
next prev parent reply other threads:[~2025-02-04 16:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 13:22 [PATCH-resent-to-correct-ml 0/8] drm/xe: Convert xe_force_wake calls to guard helpers Maarten Lankhorst
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 1/8] header/cleanup.h: Add _init_args to DEFINE_LOCK_GUARD_1(_COND) Maarten Lankhorst
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 2/8] drm/xe/gt: Unify xe_hw_fence_irq_finish() calls Maarten Lankhorst
2025-02-04 15:20 ` Lucas De Marchi
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 3/8] drm/xe: Add scoped guards for xe_force_wake Maarten Lankhorst
2025-02-04 15:28 ` Lucas De Marchi
2025-02-04 16:30 ` Michal Wajdeczko [this message]
2025-02-04 22:28 ` Maarten Lankhorst
2025-02-04 22:49 ` Rodrigo Vivi
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 4/8] drm/xe: Add xe_force_wake_get_all Maarten Lankhorst
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 5/8] drm/xe/coredump: Use guard helpers for xe_force_wake Maarten Lankhorst
2025-02-04 15:40 ` Lucas De Marchi
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 6/8] drm/xe/gsc: Use guard helper for xe_gsc_print_info Maarten Lankhorst
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 7/8] drm/xe/vram: Use xe_force_wake guard helper Maarten Lankhorst
2025-02-04 13:22 ` [PATCH-resent-to-correct-ml 8/8] drm/xe/gt: Convert to xe_force_wake guard helpers Maarten Lankhorst
2025-02-04 15:21 ` ✓ CI.Patch_applied: success for drm/xe: Convert xe_force_wake calls to " Patchwork
2025-02-04 15:21 ` ✗ CI.checkpatch: warning " Patchwork
2025-02-04 15:22 ` ✓ CI.KUnit: success " Patchwork
2025-02-04 15:38 ` ✓ CI.Build: " Patchwork
2025-02-04 15:41 ` ✓ CI.Hooks: " Patchwork
2025-02-04 15:42 ` ✗ CI.checksparse: warning " Patchwork
2025-02-04 17:40 ` [PATCH-resent-to-correct-ml 0/8] " David Lechner
2025-02-05 20:11 ` Maarten Lankhorst
2025-02-05 6:12 ` ✓ Xe.CI.BAT: success for " Patchwork
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=2ced99ce-fd3e-4966-b093-c193b6c8b400@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=boqun.feng@gmail.com \
--cc=dev@lankhorst.se \
--cc=dlechner@baylibre.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=will@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.