All of 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 11/19] drm/i915/execlists: Double check rpm wakeref
Date: Thu, 17 May 2018 12:04:15 +0100	[thread overview]
Message-ID: <df84f59f-498a-7d78-2a41-a72d67cc2ea9@linux.intel.com> (raw)
In-Reply-To: <20180517074055.14638-11-chris@chris-wilson.co.uk>


On 17/05/2018 08:40, Chris Wilson wrote:
> As we are splitting processing the CSB events from submitting the ELSP,
> we also need to duplicate the check that we hold a device wakeref for our
> hardware access to the disjoint locations.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/intel_lrc.c | 26 ++++++++++++++++----------
>   1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 4928e9ad7826..6d3b03299b0c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -449,6 +449,16 @@ static void execlists_submit_ports(struct intel_engine_cs *engine)
>   	struct execlist_port *port = execlists->port;
>   	unsigned int n;
>   
> +	/*
> +	 * We can skip acquiring intel_runtime_pm_get() here as it was taken
> +	 * on our behalf by the request (see i915_gem_mark_busy()) and it will
> +	 * not be relinquished until the device is idle (see
> +	 * i915_gem_idle_work_handler()). As a precaution, we make sure
> +	 * that all ELSP are drained i.e. we have processed the CSB,
> +	 * before allowing ourselves to idle and calling intel_runtime_pm_put().
> +	 */
> +	GEM_BUG_ON(!engine->i915->gt.awake);

Hmm.. I think it would be better to leave it in the tasklet and just add 
another instance to process_csb.

Having it only deep in execlists_submit_ports could miss confusions when 
upper layers want to submit and state say it is not possible yet.

> +
>   	/*
>   	 * ELSQ note: the submit queue is not cleared after being submitted
>   	 * to the HW so we need to make sure we always clean it up. This is
> @@ -959,6 +969,12 @@ static void process_csb(struct intel_engine_cs *engine)
>   	struct drm_i915_private *i915 = engine->i915;
>   	bool fw = false;
>   
> +	/*
> +	 * We must never release our device wakeref until after we have
> +	 * finished processing all potential interrupts from the hardware.
> +	 */
> +	GEM_BUG_ON(!engine->i915->gt.awake);
> +
>   	do {
>   		/* The HWSP contains a (cacheable) mirror of the CSB */
>   		const u32 *buf =
> @@ -1139,16 +1155,6 @@ static void execlists_submission_tasklet(unsigned long data)
>   		  engine->execlists.active,
>   		  test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted));
>   
> -	/*
> -	 * We can skip acquiring intel_runtime_pm_get() here as it was taken
> -	 * on our behalf by the request (see i915_gem_mark_busy()) and it will
> -	 * not be relinquished until the device is idle (see
> -	 * i915_gem_idle_work_handler()). As a precaution, we make sure
> -	 * that all ELSP are drained i.e. we have processed the CSB,
> -	 * before allowing ourselves to idle and calling intel_runtime_pm_put().
> -	 */
> -	GEM_BUG_ON(!engine->i915->gt.awake);
> -
>   	/*
>   	 * Prefer doing test_and_clear_bit() as a two stage operation to avoid
>   	 * imposing the cost of a locked atomic transaction when submitting a
> 

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-17 11:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17  7:40 [PATCH 01/19] drm/i915: Move request->ctx aside Chris Wilson
2018-05-17  7:40 ` [PATCH 02/19] drm/i915: Move fiddling with engine->last_retired_context Chris Wilson
2018-05-17  7:40 ` [PATCH 03/19] drm/i915: Store a pointer to intel_context in i915_request Chris Wilson
2018-05-17  7:40 ` [PATCH 04/19] drm/i915: Pull the context->pin_count dec into the common intel_context_unpin Chris Wilson
2018-05-17 10:20   ` Tvrtko Ursulin
2018-05-17 10:35     ` Chris Wilson
2018-05-17  7:40 ` [PATCH 05/19] drm/i915: Be irqsafe inside reset Chris Wilson
2018-05-17 10:27   ` Tvrtko Ursulin
2018-05-17 10:46     ` Chris Wilson
2018-05-17  7:40 ` [PATCH 06/19] drm/i915: Make intel_engine_dump irqsafe Chris Wilson
2018-05-17 10:28   ` Tvrtko Ursulin
2018-05-17  7:40 ` [PATCH 07/19] drm/i915/execlists: Handle copying default context state for atomic reset Chris Wilson
2018-05-17 10:37   ` Tvrtko Ursulin
2018-05-17  7:40 ` [PATCH 08/19] drm/i915: Allow init_breadcrumbs to be used from irq context Chris Wilson
2018-05-17 10:40   ` Tvrtko Ursulin
2018-05-17  7:40 ` [PATCH 09/19] drm/i915/execlists: HWACK checking superseded checking port[0].count Chris Wilson
2018-05-17 10:55   ` Tvrtko Ursulin
2018-05-17 17:03     ` Chris Wilson
2018-05-17  7:40 ` [PATCH 10/19] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler Chris Wilson
2018-05-17 10:58   ` Tvrtko Ursulin
2018-05-17 11:24     ` Chris Wilson
2018-05-17 13:13       ` Tvrtko Ursulin
2018-05-17  7:40 ` [PATCH 11/19] drm/i915/execlists: Double check rpm wakeref Chris Wilson
2018-05-17 11:04   ` Tvrtko Ursulin [this message]
2018-05-17  7:40 ` [PATCH 12/19] drm/i915: After reset on sanitization, reset the engine backends Chris Wilson
2018-05-17  7:40 ` [PATCH 13/19] drm/i915/execlists: Reset the CSB head tracking on reset/sanitization Chris Wilson
2018-05-17  7:40 ` [PATCH 14/19] drm/i915/execlists: Pull submit after dequeue under timeline lock Chris Wilson
2018-05-17  7:40 ` [PATCH 15/19] drm/i915/execlists: Process one CSB interrupt at a time Chris Wilson
2018-05-17  7:40 ` [PATCH 16/19] drm/i915/execlists: Unify CSB access pointers Chris Wilson
2018-05-17  7:40 ` [PATCH 17/19] drm/i915/execlists: Process the CSB directly from inside the irq handler Chris Wilson
2018-05-17  7:40 ` [PATCH 18/19] drm/i915/execlists: Direct submission (avoid tasklet/ksoftirqd) Chris Wilson
2018-05-17 13:13   ` Tvrtko Ursulin
2018-05-17 17:07     ` Chris Wilson
2018-05-18  8:06       ` Tvrtko Ursulin
2018-05-18  8:18         ` Chris Wilson
2018-05-18 19:36         ` Chris Wilson
2018-05-18 21:21     ` Chris Wilson
2018-05-17  7:40 ` [PATCH 19/19] drm/i915: Combine gt irq ack/handlers Chris Wilson
2018-05-17  8:01 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/19] drm/i915: Move request->ctx aside Patchwork
2018-05-17  8:06 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-05-17  8:16 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-17 11:05 ` ✗ Fi.CI.IGT: failure " 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=df84f59f-498a-7d78-2a41-a72d67cc2ea9@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 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.