All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: <Intel-GFX@Lists.FreeDesktop.Org>
Cc: DRI-Devel@Lists.FreeDesktop.Org
Subject: Re: [PATCH v4 2/7] drm/i915: Fix up locking around dumping requests lists
Date: Fri, 20 Jan 2023 15:40:29 -0800	[thread overview]
Message-ID: <95439a9b-241e-553f-1d69-762901259840@intel.com> (raw)
In-Reply-To: <20230120232831.28177-3-John.C.Harrison@Intel.com>

On 1/20/2023 15:28, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> The debugfs dump of requests was confused about what state requires
> the execlist lock versus the GuC lock. There was also a bunch of
> duplicated messy code between it and the error capture code.
>
> So refactor the hung request search into a re-usable function. And
> reduce the span of the execlist state lock to only the execlist
> specific code paths. In order to do that, also move the report of hold
> count (which is an execlist only concept) from the top level dump
> function to the lower level execlist specific function. Also, move the
> execlist specific code into the execlist source file.
>
> v2: Rename some functions and move to more appropriate files (Daniele).
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU 
reset with GuC")
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Michael Cheng <michael.cheng@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org

John.


WARNING: multiple messages have this Message-ID (diff)
From: John Harrison <john.c.harrison@intel.com>
To: <Intel-GFX@Lists.FreeDesktop.Org>
Cc: DRI-Devel@Lists.FreeDesktop.Org
Subject: Re: [Intel-gfx] [PATCH v4 2/7] drm/i915: Fix up locking around dumping requests lists
Date: Fri, 20 Jan 2023 15:40:29 -0800	[thread overview]
Message-ID: <95439a9b-241e-553f-1d69-762901259840@intel.com> (raw)
In-Reply-To: <20230120232831.28177-3-John.C.Harrison@Intel.com>

On 1/20/2023 15:28, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> The debugfs dump of requests was confused about what state requires
> the execlist lock versus the GuC lock. There was also a bunch of
> duplicated messy code between it and the error capture code.
>
> So refactor the hung request search into a re-usable function. And
> reduce the span of the execlist state lock to only the execlist
> specific code paths. In order to do that, also move the report of hold
> count (which is an execlist only concept) from the top level dump
> function to the lower level execlist specific function. Also, move the
> execlist specific code into the execlist source file.
>
> v2: Rename some functions and move to more appropriate files (Daniele).
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU 
reset with GuC")
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Michael Cheng <michael.cheng@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org

John.


  reply	other threads:[~2023-01-20 23:40 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 23:28 [PATCH v4 0/7] Allow error capture without a request & fix locking issues John.C.Harrison
2023-01-20 23:28 ` [Intel-gfx] " John.C.Harrison
2023-01-20 23:28 ` [PATCH v4 1/7] drm/i915: Fix request locking during error capture & debugfs dump John.C.Harrison
2023-01-20 23:28   ` [Intel-gfx] " John.C.Harrison
2023-01-23 17:51   ` Tvrtko Ursulin
2023-01-23 17:51     ` [Intel-gfx] " Tvrtko Ursulin
2023-01-23 20:35     ` John Harrison
2023-01-23 20:35       ` [Intel-gfx] " John Harrison
2023-01-25 22:04     ` John Harrison
2023-01-25 22:04       ` John Harrison
2023-01-20 23:28 ` [PATCH v4 2/7] drm/i915: Fix up locking around dumping requests lists John.C.Harrison
2023-01-20 23:28   ` [Intel-gfx] " John.C.Harrison
2023-01-20 23:40   ` John Harrison [this message]
2023-01-20 23:40     ` John Harrison
2023-01-24 14:40   ` Tvrtko Ursulin
2023-01-25 18:00     ` John Harrison
2023-01-25 18:12       ` Tvrtko Ursulin
2023-01-25 18:17         ` John Harrison
2023-01-25  0:31   ` Ceraolo Spurio, Daniele
2023-01-20 23:28 ` [PATCH v4 3/7] drm/i915: Allow error capture without a request John.C.Harrison
2023-01-20 23:28   ` [Intel-gfx] " John.C.Harrison
2023-01-25  0:39   ` Ceraolo Spurio, Daniele
2023-01-25  0:56     ` John Harrison
2023-01-20 23:28 ` [PATCH v4 4/7] drm/i915: Allow error capture of a pending request John.C.Harrison
2023-01-20 23:28   ` [Intel-gfx] " John.C.Harrison
2023-01-20 23:28 ` [PATCH v4 5/7] drm/i915/guc: Look for a guilty context when an engine reset fails John.C.Harrison
2023-01-20 23:28   ` [Intel-gfx] " John.C.Harrison
2023-01-20 23:28 ` [PATCH v4 6/7] drm/i915/guc: Add a debug print on GuC triggered reset John.C.Harrison
2023-01-20 23:28   ` [Intel-gfx] " John.C.Harrison
2023-01-20 23:28 ` [PATCH v4 7/7] drm/i915/guc: Rename GuC register state capture node to be more obvious John.C.Harrison
2023-01-20 23:28   ` [Intel-gfx] " John.C.Harrison
2023-01-25  0:44   ` Ceraolo Spurio, Daniele
2023-01-20 23:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Allow error capture without a request & fix locking issues (rev2) Patchwork
2023-01-21 21:41 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=95439a9b-241e-553f-1d69-762901259840@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=DRI-Devel@Lists.FreeDesktop.Org \
    --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.