Spurio
Cc: Tvrtko Ursulin
Cc: Brian Norris
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: John Harrison
---
Note: I didn't manage to repro the reported warning, but I did confirm
that we weren't correctly calling i915_sw_fence_fini and that this patch
fixes that.
driver
On 11/22/2022 09:42, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John Harrison
Create a set of GuC printers and start using them.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 32 --
drivers/gpu/drm/i915
On 11/22/2022 09:54, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John Harrison
Re-work the existing GuC CT printers and extend as required to match
the new wrapping scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
On 12/6/2022 03:06, Tvrtko Ursulin wrote:
On 05/12/2022 18:44, Michal Wajdeczko wrote:
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
On 02/12/2022 20:14, John Harrison wrote:
[snip]
Random meaningless (to me) message that is apparently a display thing:
drm_dbg_kms(&dev_priv->drm, "
On 1/9/2023 01:38, Jani Nikula wrote:
On Fri, 06 Jan 2023, John Harrison wrote:
On 12/6/2022 03:06, Tvrtko Ursulin wrote:
On 05/12/2022 18:44, Michal Wajdeczko wrote:
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
On 02/12/2022 20:14, John Harrison wrote:
[snip]
Random meaningless (to me
On 1/9/2023 01:39, Tvrtko Ursulin wrote:
On 06/01/2023 18:57, John Harrison wrote:
On 12/6/2022 03:06, Tvrtko Ursulin wrote:
On 05/12/2022 18:44, Michal Wajdeczko wrote:
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
On 02/12/2022 20:14, John Harrison wrote:
[snip]
Random meaningless (to me
On 1/11/2023 10:07, Matthew Brost wrote:
On Wed, Jan 11, 2023 at 09:17:01AM +, Tvrtko Ursulin wrote:
On 10/01/2023 19:01, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 04:50:55PM +, Tvrtko Ursulin wrote:
On 10/01/2023 15:55, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 12:19:35PM +
On 1/12/2023 02:01, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' fro
On 1/12/2023 02:06, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state
On 1/12/2023 02:15, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much
On 1/11/2023 14:56, Jason Ekstrand wrote:
On Wed, Jan 11, 2023 at 4:32 PM Matthew Brost
wrote:
On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> tvrtko.ursu...@linux.intel.com> wrote:
>
> >
[snip]
>
On 1/13/2023 09:46, Hellstrom, Thomas wrote:
On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:
On 12/01/2023 20:40, John Harrison wrote:
On 1/12/2023 02:01, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error
On 1/13/2023 01:22, Tvrtko Ursulin wrote:
On 12/01/2023 20:59, John Harrison wrote:
On 1/12/2023 02:15, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown
On 1/16/2023 04:38, Tvrtko Ursulin wrote:
On 13/01/2023 21:29, John Harrison wrote:
On 1/13/2023 09:46, Hellstrom, Thomas wrote:
On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:
On 12/01/2023 20:40, John Harrison wrote:
On 1/12/2023 02:01, Tvrtko Ursulin wrote:
On 12/01/2023 02:53
On 1/16/2023 04:43, Tvrtko Ursulin wrote:
On 14/01/2023 01:27, John Harrison wrote:
On 1/13/2023 01:22, Tvrtko Ursulin wrote:
On 12/01/2023 20:59, John Harrison wrote:
On 1/12/2023 02:15, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
On 1/18/2023 00:29, Andy Shevchenko wrote:
On Tue, Jan 17, 2023 at 01:36:26PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking
On 1/18/2023 08:22, Tvrtko Ursulin wrote:
On 17/01/2023 21:36, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
On 1/18/2023 09:54, Andy Shevchenko wrote:
On Wed, Jan 18, 2023 at 09:34:47AM -0800, John Harrison wrote:
On 1/18/2023 00:29, Andy Shevchenko wrote:
On Tue, Jan 17, 2023 at 01:36:26PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture
On 1/19/2023 17:54, Ceraolo Spurio, Daniele wrote:
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification'
On 1/20/2023 09:36, John Harrison wrote:
On 1/19/2023 17:54, Ceraolo Spurio, Daniele wrote:
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated
On 1/19/2023 07:16, Andy Shevchenko wrote:
On Wed, Jan 18, 2023 at 10:49:55PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking
On 1/20/2023 15:28, john.c.harri...@intel.com wrote:
From: John Harrison
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
On 1/23/2023 09:51, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 31 +-
1 file changed, 15 insertions(+), 16 deletions(-)
diff
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 8
1 file changed, 4 insertions(+), 4 deletions
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 17 +
1 file changed, 9 insertions(+), 8
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 35 +++---
1 file changed, 18 insertions(+), 17 deletions(-)
diff
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 60 ---
1 file changed, 26 insertions(+), 34 deletions(-)
diff
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 74 +--
1 file changed, 36 insertions(+), 38 deletions(-)
diff
Wajdeczko
Cc: Tvrtko Ursulin
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 48
1 file changed, 48 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
b/drivers
This is actually v1 not v4. Not sure how that crept in!
John.
On 1/24/2023 12:54, john.c.harri...@intel.com wrote:
From: John Harrison
Uncore is really part of the GT. So use the GT specific debug/error
message helpers so as to get the GT index in the prints.
Signed-off-by: John Harrison
On 1/24/2023 16:39, Ceraolo Spurio, Daniele wrote:
On 1/20/2023 3:28 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification'
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
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
On 1/25/2023 10:12, Tvrtko Ursulin wrote:
On 25/01/2023 18:00, John Harrison wrote:
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock
On 1/23/2023 09:51, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
-struct i915_request *intel_context_find_active_request(struct
intel_context *ce)
+struct i915_request *intel_context_find_active_request_get(struct
intel_context *ce
On 1/24/2023 09:05, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
v2: drop now redundant "GuC" word from the message
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_
On 1/24/2023 09:05, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
v2: drop unused helpers
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 23 ---
1
On 1/24/2023 09:05, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
v2: drop redundant GuC strings, minor improvements
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 37 --
1 file
On 1/24/2023 09:05, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
v2: improve few existing messages
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61
On 1/24/2023 09:05, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
v2: pass gt to print_fw_ver
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 80 +--
1 file changed, 39 insertions
Wajdeczko
Cc: Tvrtko Ursulin
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 48
1 file changed, 48 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc
: Alan Previn
On Tue, 2023-01-24 at 16:49 -0800, Harrison, John C wrote:
From: John Harrison
Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two
On 1/28/2023 11:59, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
v2: drop redundant GuC strings, minor improvements
v3: more message improvements
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915
On 1/28/2023 11:59, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
v2: pass gt to print_fw_ver
v3: prefer guc_dbg in suspend/resume logs
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc
On 1/31/2023 04:44, Andy Shevchenko wrote:
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the usb tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_engine_cs.c
between commit:
5bc4b43d5c6c ("drm/i915: Fix up locking around dump
On 2/1/2023 07:31, Rodrigo Vivi wrote:
On Wed, Feb 01, 2023 at 03:11:31PM +1100, Stephen Rothwell wrote:
Hi all,
On Tue, 31 Jan 2023 10:27:29 -0800 John Harrison
wrote:
On 1/31/2023 04:44, Andy Shevchenko wrote:
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
Today&#
.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc
On 1/31/2024 10:48, Janusz Krzysztofik wrote:
Hi John,
On Wednesday, 10 January 2024 22:02:16 CET john.c.harri...@intel.com wrote:
From: John Harrison
The context persistence code does things like send super high priority
heartbeat pulses to ensure any leaked context can still be pre-empted
h Graunke
Cc: Jose Souza
Cc: Sagar Ghuge
Cc: Paulo Zanoni
Cc: John Harrison
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_getparam.c | 12
include/uapi/drm/i915_drm.h | 13 +
2 files changed, 25 insertions(+)
diff -
On 2/7/2024 03:36, Joonas Lahtinen wrote:
Quoting Tvrtko Ursulin (2024-02-07 10:44:01)
On 06/02/2024 20:51, Souza, Jose wrote:
On Tue, 2024-02-06 at 12:42 -0800, John Harrison wrote:
On 2/6/2024 08:33, Tvrtko Ursulin wrote:
On 01/02/2024 18:25, Souza, Jose wrote:
On Wed, 2024-01-24 at 08:55
. Which avoids the need to add any padding
too.
I don't follow how potential 8 vs 32 confusion means jump to 64?!
Compile tested only.
Signed-off-by: Tvrtko Ursulin
Cc: Kenneth Graunke
Cc: Jose Souza
Cc: Sagar Ghuge
Cc: Paulo Zanoni
Cc: John Harrison
Cc: Rodrigo Vivi
Cc: Jani Nikula
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug
On 2/7/2024 11:43, Souza, Jose wrote:
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface
On 2/7/2024 12:47, Souza, Jose wrote:
On Wed, 2024-02-07 at 11:52 -0800, John Harrison wrote:
On 2/7/2024 11:43, Souza, Jose wrote:
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56
On 2/8/2024 00:41, Tvrtko Ursulin wrote:
On 07/02/2024 19:34, John Harrison wrote:
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa
Hello,
What platform is this on? And which GuC firmware version are you using?
One thing you made need to do is force maximum GT frequency during GuC
load. That is something the i915 driver does. If the system decides the
GPU is idle and drops the frequency to minimum then it can take multiple
e for LNL and Xe (2024-01-30 09:23:50 -0800)
----
John Harrison (2):
i915: Add GuC v70.19.2 for ADL-P, DG1, DG2, MTL and TGL
xe: First GuC release for LNL and Xe
LICENSE.xe | 39 +++
On 2/15/2024 05:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS rather than the
actual number. As of now, this c
On 2/15/2024 14:34, Andi Shyti wrote:
Hi John,
On Thu, Feb 15, 2024 at 01:23:24PM -0800, John Harrison wrote:
On 2/15/2024 05:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work
On 2/19/2024 12:28, Rodrigo Vivi wrote:
On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of
d...@pm.me natur.prod...@pm.me napisał(a):
Hello,
Please see my comments below.
piątek, 9 lutego 2024 2:45 AM, John Harrison john.c.harri...@intel.com
napisał(a):
Hello,
What platform is this on? And which GuC firmware version are you using?
It's TGL. I'm using tgl_guc_70.1.1.bin
On 2/26/2024 05:25, Nilawar, Badal wrote:
Hi John,
On 04-01-2024 23:35, john.c.harri...@intel.com wrote:
From: John Harrison
Use the new w/a KLV support to enable a MTL w/a. Note, this w/a is a
super-set of Wa_16019325821, so requires turning that one as well as
setting the new flag for
I dumped them with Windows new line characters.
Here is a new log binary dump.
I moved to the newest TGL GuC firmware from linux-firmware repo.
środa, 21 lutego 2024 12:16 AM, John Harrison john.c.harri...@intel.com
napisał(a):
Hello,
Something is very corrupted with that GuC log. The log consists of
On 3/7/2024 12:02, Andi Shyti wrote:
Hi Matt,
On Wed, Mar 06, 2024 at 03:46:09PM -0800, Matt Roper wrote:
On Wed, Mar 06, 2024 at 02:22:45AM +0100, Andi Shyti wrote:
The hardware should not dynamically balance the load between CCS
engines. Wa_14019159160 recommends disabling it across all
plat
On 5/28/2024 13:21, Matt Roper wrote:
On Fri, May 24, 2024 at 06:41:20PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Enable another workaround that is implemented inside the GuC.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 1
do for the rest of the hardware.
John.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Lucas De Marchi
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Cc: John Harrison
Michal Wajdeczko (7):
drm/xe/guc: Promote GuC ABI headers to shared location
Documentation/gpu: Separate GuC ABI section
On 6/11/2024 14:45, Michal Wajdeczko wrote:
On 11.06.2024 22:32, John Harrison wrote:
On 6/11/2024 07:30, Michal Wajdeczko wrote:
There are many GuC ABI definitions named in the same way by the i915
and Xe drivers, preventing proper generation of the documentation.
Promote GuC ABI definitions
On 3/12/2024 09:24, Matt Roper wrote:
On Thu, Mar 07, 2024 at 06:01:29PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
An existing workaround has been extended in both platforms affected
and implementation complexity.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt
://gitlab.freedesktop.org/drm/intel/-/issues/10564
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Reviewed-by: John Harrison
---
.../gpu/drm/i915/selftests/i915_selftest.c| 36 ---
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests
GuC
*_reset_engines()
intel_gt_init_hw() --> GuC FW loading happens, GuC comes out of
GS_MIA_IN_RESET.
Fix the above flow so that GuC reset happens after all the
engines reset is done.
Cc: John Harrison
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_reset.c | 9 --
dr
On 4/18/2024 10:10, Nirmoy Das wrote:
__intel_gt_reset() is really for resetting engines though
the name might suggest something else. So add two helper functions
to remove confusions with no functional changes.
Technically you only added one and just moved the other :). It already
existed, it j
On 4/18/2024 10:10, Nirmoy Das wrote:
intel_engine_reset() not only reset a engine but also
tries to recover it so give it a proper name without
any functional changes.
Not seeing what the difference is. If this was a super low level
function (with an __ prefix for example) then one might expect
On 4/18/2024 10:10, Nirmoy Das wrote:
Currently intel_gt_reset() happens as follows:
reset_prepare() ---> Sends GDRST to GuC, GuC is in GS_MIA_IN_RESET
do_reset()
intel_gt_reset_all_engines()
*_engine_reset_prepare() -->RESET_CTL expects running GuC
Not technically correct. There is no d
diff simple(John)
Cc: John Harrison
Signed-off-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
.../drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/gt
CSB FIFO.
To address this issue, the GuC should be killed only after resetting
the requested engines and before calling intel_gt_init_hw().
v2: Improve commit message(John)
Cc: John Harrison
Signed-off-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_reset.c | 16
On 26/02/2015 02:26, Daniel Vetter wrote:
On Wed, Feb 25, 2015 at 11:17:00PM +0100, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:14AM +, john.c.harri...@intel.com wrote:
From: John Harrison
For some reason, the i915_add_request() call in
i915_gem_execbuffer_retire_commands() was
On 05/03/2015 14:44, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 01:06:10PM +, John Harrison wrote:
On 26/02/2015 02:26, Daniel Vetter wrote:
On Wed, Feb 25, 2015 at 11:17:00PM +0100, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:14AM +, john.c.harri...@intel.com wrote:
From
On 05/03/2015 15:22, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 02:03:03PM +, john.c.harri...@intel.com wrote:
From: John Harrison
Apparently, this has never worked reliably and is currently disabled. Also, the
gains are not particularly impressive. Thus rather than try to keep unused
On 05/03/2015 15:27, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly
allocated
request. Instead, it must be pulled from
ring->outstanding_lazy_request. This
patch fixes this so t
On 05/03/2015 16:14, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 03:06:42PM +, John Harrison wrote:
On 05/03/2015 14:44, Daniel Vetter wrote:
Imo reserving a bit of ring space for each add_request should be solid.
Userspace uses the exact same reservation logic for adding end-of-batch
On 05/03/2015 13:56, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, the ringbuf is a function of the ring and context
whereas in
legacy mode, it is derived from the ring alone. Thus the calculation
required to
determine the
On 05/03/2015 13:21, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
There is a flags word that is passed through the execbuffer code path
all the
way from initial decoding of the user parameters down to the very
final dispatch
buffer call. It is
On 06/03/2015 16:18, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 08:13:07PM +, Tomas Elf wrote:
On 05/03/2015 15:46, John Harrison wrote:
On 05/03/2015 15:27, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does
On 05/03/2015 14:49, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 01:57:31PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC submission code requires a request for tracking purposes. It does not
actually require that request to 'complete' it simply uses it for ke
On 11/03/2015 16:44, Jesse Barnes wrote:
On 03/11/2015 09:14 AM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 02:53:39PM +, John Harrison wrote:
On 05/03/2015 14:49, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 01:57:31PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The
On 10/03/2015 10:18, Daniel Vetter wrote:
On Mon, Mar 09, 2015 at 11:51:26PM +, Tomas Elf wrote:
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison
The outstanding_lazy_request is no longer used anywhere in the driver.
Everything that was looking at it now has a
On 19/03/2015 15:16, Jani Nikula wrote:
On Thu, 19 Mar 2015, "Daniel, Thomas" wrote:
- if (&request->list == &ring->request_list)
+ /* It should always be possible to find a suitable request! */
+ if (&request->list == &ring->request_list) {
+ WARN_ON(true);
On 20/03/2015 15:13, Daniel Vetter wrote:
On Thu, Mar 19, 2015 at 12:30:10PM +, john.c.harri...@intel.com wrote:
+void intel_ring_reserved_space_use(struct intel_ringbuffer *ringbuf, int size)
Just a bit of interface bikeshed - I'd drop the size parameter here. It
just duplicates what we te
On 20/03/2015 15:30, Chris Wilson wrote:
On Fri, Mar 20, 2015 at 04:23:45PM +0100, Daniel Vetter wrote:
On Thu, Mar 19, 2015 at 12:30:56PM +, john.c.harri...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6f198df..c7dca
On 19/03/2015 12:30, john.c.harri...@intel.com wrote:
+void intel_ring_reserved_space_end(struct intel_ringbuffer *ringbuf)
+{
+WARN_ON(!ringbuf->reserved_in_use);
+WARN_ON(ringbuf->tail > ringbuf->reserved_tail +
ringbuf->reserved_size);
+
+ringbuf->reserved_size = 0;
+ringbu
On 20/03/2015 16:19, John Harrison wrote:
On 19/03/2015 12:30, john.c.harri...@intel.com wrote:
+void intel_ring_reserved_space_end(struct intel_ringbuffer *ringbuf)
+{
+WARN_ON(!ringbuf->reserved_in_use);
+WARN_ON(ringbuf->tail > ringbuf->reserved_tail +
ringbuf-&g
On 23/03/2015 09:22, Daniel Vetter wrote:
On Fri, Mar 20, 2015 at 09:11:35PM +, Chris Wilson wrote:
On Fri, Mar 20, 2015 at 05:48:36PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The intended usage model for struct fence is that the signalled status should be
set on
On 01/04/2015 06:56, Daniel Vetter wrote:
On Tue, Mar 31, 2015 at 04:50:10PM +0100, Tomas Elf wrote:
On 19/03/2015 12:30, john.c.harri...@intel.com wrote:
From: John Harrison
The legacy and LRC code paths have an almost identical procedure for waiting for
space in the ring buffer. They both
On 07/04/2015 10:18, Maarten Lankhorst wrote:
Hey,
Op 20-03-15 om 18:48 schreef john.c.harri...@intel.com:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware. I.e. it solves the bas
On 19/10/2014 13:55, Daniel Vetter wrote:
On Mon, Oct 06, 2014 at 03:15:13PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
To thin commit message.
Also I wonder whethere we should track the olr state more explicitly in
the request structure instead of jumping through all these
On 19/10/2014 15:04, Daniel Vetter wrote:
On Fri, Oct 10, 2014 at 12:39:49PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
For: VIZ-4377
Signed-off-by: john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c |3 +--
drivers/gpu/drm/i915/i915_drv.h | 18
On 19/10/2014 15:09, Daniel Vetter wrote:
On Mon, Oct 06, 2014 at 03:15:24PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
For: VIZ-4377
Signed-off-by: john.c.harri...@intel.com
We have places that shovel stuff onto the ring without an explicit
add_request. Or at least we&#x
On 19/10/2014 15:12, Daniel Vetter wrote:
On Mon, Oct 06, 2014 at 03:15:25PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
For: VIZ-4377
Signed-off-by: john.c.harri...@intel.com
I think this should be split up into the different parts:
- s/obj->ring/obj->last_read_req
On 19/10/2014 15:14, Daniel Vetter wrote:
On Tue, Oct 07, 2014 at 05:47:29PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
For: VIZ-4377
Signed-off-by: john.c.harri...@intel.com
Why? If it's just for performance I think we should do this as part of the
switch to struct
801 - 900 of 1003 matches
Mail list logo
