Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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