From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 05/50] drm/i915: Introduce struct intel_wakeref
Date: Fri, 12 Apr 2019 13:59:30 +0100 [thread overview]
Message-ID: <9a0fa01a-fcf9-d73f-fcc7-3c5e042cceab@linux.intel.com> (raw)
In-Reply-To: <20190412085410.10392-6-chris@chris-wilson.co.uk>
On 12/04/2019 09:53, Chris Wilson wrote:
> For controlling runtime pm of the GT and engines, we would like to have
> a callback to do extra work the first time we wake up and the last time
> we drop the wakeref. This first/last access needs serialisation and so
> we encompass a mutex with the regular intel_wakeref_t tracker.
>
> v2: Drop the _once naming and report the errors.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc; Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/Makefile.header-test | 3 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +-
> drivers/gpu/drm/i915/intel_wakeref.c | 62 ++++++++++
> drivers/gpu/drm/i915/intel_wakeref.h | 133 ++++++++++++++++++++++
> 5 files changed, 199 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_wakeref.c
> create mode 100644 drivers/gpu/drm/i915/intel_wakeref.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 40130cf5c003..233bad5e361f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -50,6 +50,7 @@ i915-y += i915_drv.o \
> intel_device_info.o \
> intel_pm.o \
> intel_runtime_pm.o \
> + intel_wakeref.o \
> intel_uncore.o
>
> # core library code
> diff --git a/drivers/gpu/drm/i915/Makefile.header-test b/drivers/gpu/drm/i915/Makefile.header-test
> index 96a5d90629ec..e6b3e7588860 100644
> --- a/drivers/gpu/drm/i915/Makefile.header-test
> +++ b/drivers/gpu/drm/i915/Makefile.header-test
> @@ -31,7 +31,8 @@ header_test := \
> intel_psr.h \
> intel_sdvo.h \
> intel_sprite.h \
> - intel_tv.h
> + intel_tv.h \
> + intel_wakeref.h
>
> quiet_cmd_header_test = HDRTEST $@
> cmd_header_test = echo "\#include \"$(<F)\"" > $@
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fad5306f07da..62a7e91acd7f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -74,6 +74,7 @@
> #include "intel_opregion.h"
> #include "intel_uc.h"
> #include "intel_uncore.h"
> +#include "intel_wakeref.h"
> #include "intel_wopcm.h"
>
> #include "i915_gem.h"
> @@ -134,8 +135,6 @@ bool i915_error_injected(void);
> __i915_printk(i915, i915_error_injected() ? KERN_DEBUG : KERN_ERR, \
> fmt, ##__VA_ARGS__)
>
> -typedef depot_stack_handle_t intel_wakeref_t;
> -
> enum hpd_pin {
> HPD_NONE = 0,
> HPD_TV = HPD_NONE, /* TV is known to be unreliable */
> diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c
> new file mode 100644
> index 000000000000..f4cfaa154303
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_wakeref.c
> @@ -0,0 +1,62 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include "intel_drv.h"
> +#include "intel_wakeref.h"
> +
> +int __intel_wakeref_get_first(struct drm_i915_private *i915,
> + struct intel_wakeref *wf,
> + int (*fn)(struct intel_wakeref *wf))
> +{
> + /*
> + * Treat get/put as different subclasses, as we may need to run
> + * the put callback from under the shrinker and do not want to
> + * cross-contanimate that callback with any extra work performed
> + * upon acquiring the wakeref.
> + */
So you want to seralize the get/put callbacks but don't want lockdep to
see any chains resulting from that. Sounds worrying.
What if you moved them (callbacks) outside wf->mutex then and mandate
the callback pairs to serialize themselves?
> + mutex_lock_nested(&wf->mutex, SINGLE_DEPTH_NESTING);
> + if (!atomic_read(&wf->count)) {
> + int err;
> +
> + wf->wakeref = intel_runtime_pm_get(i915);
> +
> + err = fn(wf);
> + if (unlikely(err)) {
> + intel_runtime_pm_put(i915, wf->wakeref);
> + mutex_unlock(&wf->mutex);
> + return err;
> + }
> +
> + smp_mb__before_atomic(); /* release wf->count */
These ones are like usually "What.." for me.
According to the docs this line would suggest you want some other memory
write to become visible before the atomic_inc below. Which one?
> + }
> + atomic_inc(&wf->count);
> + mutex_unlock(&wf->mutex);
> +
> + return 0;
> +}
> +
> +int __intel_wakeref_put_last(struct drm_i915_private *i915,
> + struct intel_wakeref *wf,
> + int (*fn)(struct intel_wakeref *wf))
> +{
> + int err;
> +
> + err = fn(wf);
> + if (likely(!err))
> + intel_runtime_pm_put(i915, wf->wakeref);
> + else
> + atomic_inc(&wf->count);
> + mutex_unlock(&wf->mutex);
> +
> + return err;
> +}
> +
> +void __intel_wakeref_init(struct intel_wakeref *wf,
> + struct lock_class_key *key)
> +{
> + __mutex_init(&wf->mutex, "wakeref", key);
> + atomic_set(&wf->count, 0);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_wakeref.h b/drivers/gpu/drm/i915/intel_wakeref.h
> new file mode 100644
> index 000000000000..a979d638344b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_wakeref.h
> @@ -0,0 +1,133 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#ifndef INTEL_WAKEREF_H
> +#define INTEL_WAKEREF_H
> +
> +#include <linux/atomic.h>
> +#include <linux/mutex.h>
> +#include <linux/stackdepot.h>
> +
> +struct drm_i915_private;
> +
> +typedef depot_stack_handle_t intel_wakeref_t;
> +
> +struct intel_wakeref {
> + atomic_t count;
> + struct mutex mutex;
> + intel_wakeref_t wakeref;
> +};
> +
> +void __intel_wakeref_init(struct intel_wakeref *wf,
> + struct lock_class_key *key);
> +#define intel_wakeref_init(wf) do { \
> + static struct lock_class_key __key; \
> + \
> + __intel_wakeref_init((wf), &__key); \
> +} while (0)
> +
> +int __intel_wakeref_get_first(struct drm_i915_private *i915,
> + struct intel_wakeref *wf,
> + int (*fn)(struct intel_wakeref *wf));
> +int __intel_wakeref_put_last(struct drm_i915_private *i915,
> + struct intel_wakeref *wf,
> + int (*fn)(struct intel_wakeref *wf));
> +
> +/**
> + * intel_wakeref_get: Acquire the wakeref
> + * @i915: the drm_i915_private device
> + * @wf: the wakeref
> + * @fn: callback for acquired the wakeref, called only on first acquire.
> + *
> + * Acquire a hold on the wakeref. The first user to do so, will acquire
> + * the runtime pm wakeref and then call the @fn underneath the wakeref
> + * mutex.
> + *
> + * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
> + * will be released and the acquisition unwound, and an error reported.
> + *
> + * Returns: 0 if the wakeref was acquired successfully, or a negative error
> + * code otherwise.
> + */
> +static inline int
> +intel_wakeref_get(struct drm_i915_private *i915,
> + struct intel_wakeref *wf,
> + int (*fn)(struct intel_wakeref *wf))
> +{
> + if (unlikely(!atomic_inc_not_zero(&wf->count)))
> + return __intel_wakeref_get_first(i915, wf, fn);
> +
> + return 0;
> +}
> +
> +/**
> + * intel_wakeref_put: Release the wakeref
> + * @i915: the drm_i915_private device
> + * @wf: the wakeref
> + * @fn: callback for releasing the wakeref, called only on final release.
> + *
> + * Release our hold on the wakeref. When there are no more users,
> + * the runtime pm wakeref will be released after the @fn callback is called
> + * underneath the wakeref mutex.
> + *
> + * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
> + * is retained and an error reported.
> + *
> + * Returns: 0 if the wakeref was released successfully, or a negative error
> + * code otherwise.
> + */
> +static inline int
> +intel_wakeref_put(struct drm_i915_private *i915,
> + struct intel_wakeref *wf,
> + int (*fn)(struct intel_wakeref *wf))
> +{
> + if (atomic_dec_and_mutex_lock(&wf->count, &wf->mutex))
> + return __intel_wakeref_put_last(i915, wf, fn);
> +
> + return 0;
> +}
> +
> +/**
> + * intel_wakeref_lock: Lock the wakeref (mutex)
> + * @wf: the wakeref
> + *
> + * Locks the wakeref to prevent it being acquired or released. New users
> + * can still adjust the counter, but the wakeref itself (and callback)
> + * cannot be acquired or released.
> + */
> +static inline void
> +intel_wakeref_lock(struct intel_wakeref *wf)
> + __acquires(wf->mutex)
> +{
> + mutex_lock(&wf->mutex);
> +}
> +
> +/**
> + * intel_wakeref_unlock: Unlock the wakeref
> + * @wf: the wakeref
> + *
> + * Releases a previously acquired intel_wakeref_lock().
> + */
> +static inline void
> +intel_wakeref_unlock(struct intel_wakeref *wf)
> + __releases(wf->mutex)
> +{
> + mutex_unlock(&wf->mutex);
> +}
> +
> +/**
> + * intel_wakeref_active: Query whether the wakeref is currently held
> + * @wf: the wakeref
> + *
> + * Returns: true if the wakeref is currently held.
> + */
> +static inline bool
> +intel_wakeref_active(struct intel_wakeref *wf)
> +{
> + return atomic_read(&wf->count);
> +}
> +
> +#endif /* INTEL_WAKEREF_H */
>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-04-12 12:59 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-12 8:53 Excuse the preemption, I can see you are busy Chris Wilson
2019-04-12 8:53 ` [PATCH 01/50] drm/i915: Introduce struct class_instance for engines across the uAPI Chris Wilson
2019-04-15 8:26 ` Andi Shyti
2019-04-12 8:53 ` [PATCH 02/50] drm/i915: Mark up ips for RCU protection Chris Wilson
2019-04-16 12:35 ` Mika Kuoppala
2019-04-12 8:53 ` [PATCH 03/50] drm/i915: Store the default sseu setup on the engine Chris Wilson
2019-04-12 8:53 ` [PATCH 04/50] drm/i915: Move GraphicsTechnology files under gt/ Chris Wilson
2019-04-12 8:53 ` [PATCH 05/50] drm/i915: Introduce struct intel_wakeref Chris Wilson
2019-04-12 12:59 ` Tvrtko Ursulin [this message]
2019-04-12 13:12 ` Chris Wilson
2019-04-12 8:53 ` [PATCH 06/50] drm/i915: Pull the GEM powermangement coupling into its own file Chris Wilson
2019-04-12 8:53 ` [PATCH 07/50] drm/i915: Introduce context->enter() and context->exit() Chris Wilson
2019-04-12 13:00 ` Tvrtko Ursulin
2019-04-12 8:53 ` [PATCH 08/50] drm/i915: Pass intel_context to i915_request_create() Chris Wilson
2019-04-12 8:53 ` [PATCH 09/50] drm/i915: Invert the GEM wakeref hierarchy Chris Wilson
2019-04-12 8:53 ` [PATCH 10/50] drm/i915/gvt: Pin the per-engine GVT shadow contexts Chris Wilson
2019-04-12 8:53 ` [PATCH 11/50] drm/i915: Explicitly pin the logical context for execbuf Chris Wilson
2019-04-12 8:53 ` [PATCH 12/50] drm/i915: Export intel_context_instance() Chris Wilson
2019-04-12 8:53 ` [PATCH 13/50] drm/i915/selftests: Use the real kernel context for sseu isolation tests Chris Wilson
2019-04-12 8:53 ` [PATCH 14/50] drm/i915/selftests: Pass around intel_context for sseu Chris Wilson
2019-04-12 8:53 ` [PATCH 15/50] drm/i915: Pass intel_context to intel_context_pin_lock() Chris Wilson
2019-04-12 8:53 ` [PATCH 16/50] drm/i915: Split engine setup/init into two phases Chris Wilson
2019-04-12 8:53 ` [PATCH 17/50] drm/i915: Switch back to an array of logical per-engine HW contexts Chris Wilson
2019-04-12 13:31 ` Tvrtko Ursulin
2019-04-12 13:43 ` Chris Wilson
2019-04-12 14:37 ` Tvrtko Ursulin
2019-04-12 14:58 ` [PATCH v5] " Chris Wilson
2019-04-15 11:00 ` Tvrtko Ursulin
2019-04-15 11:02 ` Tvrtko Ursulin
2019-04-12 8:53 ` [PATCH 18/50] drm/i915: Remove intel_context.active_link Chris Wilson
2019-04-15 11:10 ` Tvrtko Ursulin
2019-04-15 12:42 ` Chris Wilson
2019-04-15 12:57 ` Tvrtko Ursulin
2019-04-12 8:53 ` [PATCH 19/50] drm/i915: Move i915_request_alloc into selftests/ Chris Wilson
2019-04-12 8:53 ` [PATCH 20/50] drm/i915: Allow multiple user handles to the same VM Chris Wilson
2019-04-12 8:53 ` [PATCH 21/50] drm/i915: Restore control over ppgtt for context creation ABI Chris Wilson
2019-04-12 8:53 ` [PATCH 22/50] drm/i915: Allow a context to define its set of engines Chris Wilson
2019-04-15 12:19 ` Tvrtko Ursulin
2019-04-15 12:31 ` Chris Wilson
2019-04-12 8:53 ` [PATCH 23/50] drm/i915: Re-expose SINGLE_TIMELINE flags for context creation Chris Wilson
2019-04-12 8:53 ` [PATCH 24/50] drm/i915: Allow userspace to clone contexts on creation Chris Wilson
2019-04-15 12:56 ` Tvrtko Ursulin
2019-04-17 7:53 ` Chris Wilson
2019-04-17 8:03 ` Tvrtko Ursulin
2019-04-12 8:53 ` [PATCH 25/50] drm/i915: Load balancing across a virtual engine Chris Wilson
2019-04-12 8:53 ` [PATCH 26/50] drm/i915: Apply an execution_mask to the virtual_engine Chris Wilson
2019-04-12 8:53 ` [PATCH 27/50] drm/i915: Extend execution fence to support a callback Chris Wilson
2019-04-12 8:53 ` [PATCH 28/50] drm/i915/execlists: Virtual engine bonding Chris Wilson
2019-04-12 8:53 ` [PATCH 29/50] drm/i915: Allow specification of parallel execbuf Chris Wilson
2019-04-12 8:53 ` [PATCH 30/50] drm/i915: Split GEM object type definition to its own header Chris Wilson
2019-04-12 8:53 ` [PATCH 31/50] drm/i915: Pull GEM ioctls interface to its own file Chris Wilson
2019-04-12 8:53 ` [PATCH 32/50] drm/i915: Move object->pages API to i915_gem_object.[ch] Chris Wilson
2019-04-12 8:53 ` [PATCH 33/50] drm/i915: Move shmem object setup to its own file Chris Wilson
2019-04-12 8:53 ` [PATCH 34/50] drm/i915: Move phys objects " Chris Wilson
2019-04-12 8:53 ` [PATCH 35/50] drm/i915: Move mmap and friends " Chris Wilson
2019-04-12 8:53 ` [PATCH 36/50] drm/i915: Move GEM domain management " Chris Wilson
2019-04-12 8:53 ` [PATCH 37/50] drm/i915: Move more GEM objects under gem/ Chris Wilson
2019-04-12 8:53 ` [PATCH 38/50] drm/i915: Pull scatterlist utils out of i915_gem.h Chris Wilson
2019-04-17 11:11 ` Matthew Auld
2019-04-17 11:17 ` Chris Wilson
2019-04-12 8:53 ` [PATCH 39/50] drm/i915: Move GEM object domain management from struct_mutex to local Chris Wilson
2019-04-12 15:03 ` Matthew Auld
2019-04-12 8:54 ` [PATCH 40/50] drm/i915: Move GEM object waiting to its own file Chris Wilson
2019-04-12 8:54 ` [PATCH 41/50] drm/i915: Move GEM object busy checking " Chris Wilson
2019-04-12 8:54 ` [PATCH 42/50] drm/i915: Move GEM client throttling " Chris Wilson
2019-04-12 8:54 ` [PATCH 43/50] drm/i915: Drop the deferred active reference Chris Wilson
2019-04-12 8:54 ` [PATCH 44/50] lockdep Chris Wilson
2019-04-12 8:54 ` [PATCH 45/50] drm/i915: Move object close under its own lock Chris Wilson
2019-04-12 8:54 ` [PATCH 46/50] drm/i915: Rename intel_context.active to .inflight Chris Wilson
2019-04-12 8:54 ` [PATCH 47/50] drm/i915: Keep contexts pinned until after the next kernel context switch Chris Wilson
2019-04-12 8:54 ` [PATCH 48/50] drm/i915: Stop retiring along engine Chris Wilson
2019-04-12 8:54 ` [PATCH 49/50] drm/i915: Replace engine->timeline with a plain list Chris Wilson
2019-04-12 13:29 ` [PATCH] " Chris Wilson
2019-04-12 8:54 ` [PATCH 50/50] drm/i915/execlists: Preempt-to-busy Chris Wilson
2019-04-12 10:14 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/50] drm/i915: Introduce struct class_instance for engines across the uAPI Patchwork
2019-04-12 10:30 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-04-12 12:11 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-04-12 12:18 ` Chris Wilson
2019-04-12 15:31 ` ✗ Fi.CI.BAT: failure for series starting with [01/50] drm/i915: Introduce struct class_instance for engines across the uAPI (rev3) 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=9a0fa01a-fcf9-d73f-fcc7-3c5e042cceab@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox