On 5/30/2024 02:33, Michal Wajdeczko wrote:
On 30.05.2024 09:49, Jani Nikula wrote:
On Wed, 29 May 2024, John Harrison wrote:
On 5/28/2024 06:06, Michal Wajdeczko wrote:
This drm printer wrapper can be used to increase the robustness of
the captured output generated by any other drm_printer
On 5/30/2024 00:49, Jani Nikula wrote:
On Wed, 29 May 2024, John Harrison wrote:
On 5/28/2024 06:06, Michal Wajdeczko wrote:
This drm printer wrapper can be used to increase the robustness of
the captured output generated by any other drm_printer to make sure
we didn't lost any intermediate
some crash data.
Signed-off-by: Michal Wajdeczko
Cc: Jani Nikula
Cc: John Harrison
---
v2: don't abuse prefix, use union instead (Jani)
don't use 'dp' as name, prefer 'p' (Jani)
add support for unique series identifier (John)
---
drivers/gpu/drm/drm_print.c | 14
include
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
On 5/23/2024 16:54, Daniele Ceraolo Spurio wrote:
Forwarded Message
Subject:[RFC] drm/print: Introduce drm_line_printer
Date: Tue, 14 May 2024 16:56:31 +0200
From: Michal Wajdeczko
To: dri-devel@lists.freedesktop.org
This drm printer wrapper can be used to
On 5/14/2024 13:41, Michal Wajdeczko wrote:
On 14.05.2024 20:13, John Harrison wrote:
On 5/14/2024 07:58, Michal Wajdeczko wrote:
On 13.05.2024 18:53, John Harrison wrote:
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already provide the content of the GuC log in debugsfs
On 5/14/2024 14:15, Michal Wajdeczko wrote:
On 14.05.2024 22:31, Matthew Brost wrote:
On Tue, May 14, 2024 at 11:13:14AM -0700, John Harrison wrote:
On 5/14/2024 07:58, Michal Wajdeczko wrote:
On 13.05.2024 18:53, John Harrison wrote:
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already
On 5/14/2024 07:58, Michal Wajdeczko wrote:
On 13.05.2024 18:53, John Harrison wrote:
On 5/12/2024 08:36, Michal Wajdeczko wrote:
We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale
omic copy of the log into
a temporary buffer before reading it out. Doing the read in separate
chunks is only going to make that problem even worse.
John.
Signed-off-by: Michal Wajdeczko
Cc: Lucas De Marchi
Cc: John Harrison
---
Cc: linux-fsde...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
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
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
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
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
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
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
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
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
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
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/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
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
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/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 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
u64. 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
Cc:
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
On 1/4/2024 12:34, Daniele Ceraolo Spurio wrote:
On 1/2/2024 2:22 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A failure to load the HuC is occasionally observed where the cause is
believed to be a low GT frequency leading to very long load times.
So a) increase the timeout so
On 12/5/2023 02:39, Nirmoy Das wrote:
Hi John,
On 12/5/2023 10:10 AM, John Harrison wrote:
On 12/5/2023 00:52, Nirmoy Das wrote:
gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.
Convert the log
have more success, but that is
not something that i915 currently does.
John.
v2: Improve commit message(Tvrtko)
Cc: Tvrtko Ursulin
Cc: John Harrison
Cc: Andi Shyti
Cc: Andrzej Hajda
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das
Reviewed
On 11/21/2023 10:55, Alan Previn wrote:
Add missing tag for "Wa_14019159160 - Case 2" (for existing
PXP code that ensures run alone mode bit is set to allow
PxP-decryption.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
1 file changed, 3 insertions(+), 1
On 11/9/2023 12:33, Daniele Ceraolo Spurio wrote:
On 11/6/2023 3:59 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a mechanism for reporting errors from fire and forget H2G
messages. This is the only way to find out about almost any error in
the GuC backend submission path
On 10/6/2023 17:38, Belgaumkar, Vinay wrote:
On 9/15/2023 2:55 PM, john.c.harri...@intel.com wrote:
From: John Harrison
To prevent running out of bits, new w/a enable flags are being added
via a KLV system instead of a 32 bit flags word.
Signed-off-by: John Harrison
---
.../gpu/drm/i915
On 10/6/2023 17:10, Belgaumkar, Vinay wrote:
On 9/15/2023 2:55 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Some platforms require holding RCS context switches until CCS is idle
(the reverse w/a of Wa_14014475959). Some platforms require both
versions.
Signed-off-by: John
this value to the
user as is.
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h | 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 12
drivers/gpu/drm/i915/gt
On 10/16/2023 15:55, Vinay Belgaumkar wrote:
This bit does not cause an explicit L3 flush. We already use
At all? Or only on newer hardware? And as a genuine spec change or as a
bug / workaround?
If the hardware has re-purposed the bit then it is probably worth at
least adding a comment to
On 10/12/2023 03:21, Tvrtko Ursulin wrote:
On 21/09/2023 19:20, john.c.harri...@intel.com wrote:
From: John Harrison
If an active context has been banned (e.g. Ctrl+C killed) then it is
likely to be reset as part of evicting it from the hardware. That
results in a 'ignoring context reset
On 10/10/2023 05:15, Andi Shyti wrote:
Hi,
I might have picked up the wrong series and missed some reviews
and the extra patch from Nirmoy with a real use of the
drm_dbg_ratelimited() that John was looking for.
Thanks,
Andi
I just found the original post of this from back in January
On 10/9/2023 13:02, Andi Shyti wrote:
Hi John,
...
if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
- drm_warn_once(>i915->drm, "GSC irq: intf_id %d is out of
range", intf_id);
+ gt_warn_once(gt, "GSC irq: intf_id %d is out of range",
intf_id);
On 10/9/2023 12:54, Andi Shyti wrote:
Hi John,
...
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -71,6 +71,7 @@
#include "gem/i915_gem_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_print.h"
#include
On 10/9/2023 12:50, Andi Shyti wrote:
Hi John,
...
if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
- drm_warn_once(>i915->drm, "GSC irq: intf_id %d is out of
range", intf_id);
+ gt_warn_once(gt, "GSC irq: intf_id %d is out of range",
intf_id);
On 10/9/2023 12:43, Andi Shyti wrote:
Hi John,
From: Nirmoy Das
Add a function for ratelimitted debug print.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Nirmoy Das
On 10/9/2023 09:52, Andi Shyti wrote:
Hi,
From: Nirmoy Das
Add a function for ratelimitted debug print.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Nirmoy Das
On 10/3/2023 13:58, Umesh Nerlige Ramappa wrote:
On Fri, Sep 22, 2023 at 03:25:08PM -0700, john.c.harri...@intel.com
wrote:
From: John Harrison
The GuC has been extended to support a much more friendly engine
busyness interface. So partition the old interface into a 'busy_v1'
space and add
On 10/4/2023 13:58, Andi Shyti wrote:
Hi Matt,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
On 10/4/2023 13:09, Andi Shyti wrote:
Hi John,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
On 10/4/2023 12:35, Andi Shyti wrote:
Hi John,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
On 10/4/2023 07:08, Andi Shyti wrote:
Hi Tvrtko,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing
100 characters (checkpatch).
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7061
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Andi Shyti #v1
Reviewed-by: John Harrison
Although aren't we supposed to be using %pe / PTR_ERR(ret) these days?
Not a blocker but for future reference
On 9/6/2023 02:17, Andi Shyti wrote:
Hi John,
static void guc_cancel_busyness_worker(struct intel_guc *guc)
{
- cancel_delayed_work_sync(>timestamp.work);
+ /*
+* When intel_gt_reset was called, task will hold a lock.
+* To cacel delayed work here, the
On 9/5/2023 23:50, Daniel Vetter wrote:
On Mon, Aug 28, 2023 at 04:01:38PM -0700, John Harrison wrote:
On 8/23/2023 10:37, John Harrison wrote:
On 8/23/2023 09:00, Daniel Vetter wrote:
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
On 8/11/2023 11:20, Zhanjun Dong wrote
On 8/31/2023 07:00, Andi Shyti wrote:
Hi,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a0e3ef1c65d2..600388c849f7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++
On 8/23/2023 10:37, John Harrison wrote:
On 8/23/2023 09:00, Daniel Vetter wrote:
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
On 8/11/2023 11:20, Zhanjun Dong wrote:
This attempts to avoid circular locking dependency between flush
delayed
work and intel_gt_reset.
When
On 8/23/2023 09:00, Daniel Vetter wrote:
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
On 8/11/2023 11:20, Zhanjun Dong wrote:
This attempts to avoid circular locking dependency between flush delayed
work and intel_gt_reset.
When intel_gt_reset was called, task will hold
the possible cirular locking dependency warning.
When intel_gt_reset called, reset_in_progress flag will be set, add code
to check the flag, call async verion if reset is in progress.
Signed-off-by: Zhanjun Dong
Cc: John Harrison
Cc: Andi Shyti
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gt/uc
On 8/3/2023 06:28, Andi Shyti wrote:
Hi John,
On Wed, Aug 02, 2023 at 11:49:40AM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that if the very first 'stealing' request failed to
create for some reason then the 'steal all ids' loop would immediately
exit
On 6/15/2023 14:15, Zhanjun Dong wrote:
This attempts to avoid circular locking dependency between flush delayed work
and intel_gt_reset.
Switched from cancel_delayed_work_sync to cancel_delayed_work, the non-sync
version for reset path, it is safe as the worker has the trylock code to handle
-by: Daniele Ceraolo Spurio
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 42
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 08e16017584b..f0cc5bb47fa0 100644
On 6/7/2023 12:03, Zhanjun Dong wrote:
This attempts to avoid circular locking dependency between flush delayed work
and intel_gt_reset.
Switched from cancel_delayed_work_sync to cancel_delayed_work, the non-sync
version for reset path, it is safe as the worker has the trylock code to handle
On 6/6/2023 10:53, John Harrison wrote:
On 6/5/2023 20:00, Zhanjun Dong wrote:
This attemps to avoid circular locing dependency between flush
delayed work and intel_gt_reset.
locing -> locking
WARNING: possible circular locking dependency detected
6.4.0-rc1-drmtip_1340-g31e3463b0edb+
On 6/5/2023 20:00, Zhanjun Dong wrote:
This attemps to avoid circular locing dependency between flush delayed work and
intel_gt_reset.
locing -> locking
WARNING: possible circular locking dependency detected
6.4.0-rc1-drmtip_1340-g31e3463b0edb+ #1 Not tainted
ut having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
v3: split check for GSC access, better comments (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 49 +++
-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 111 -
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 16 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
ut having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
v3: split check for GSC access, better comments (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/
defines (s/CPT/CPD/), update commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
v4: fix log for real (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan
On 5/30/2023 17:14, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 5:01 PM, John Harrison wrote:
On 5/30/2023 08:29, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
On 5/30/2023 17:11, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:51 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load
On 5/30/2023 17:06, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:30 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out
v3: add a better comment at the top of the HuC file to explain the
different approaches to load and auth (John)
v4: update call to intel_huc_is_authenticated in the pxp code to check
for GSC authentication
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed
ut having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 29 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h
defines (s/CPT/CPD/), update commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
.../drm
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 ++
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +-
drivers/gpu/drm/
Wajdeczko
Signed-off-by: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/Kconfig.debug| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 68 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 11
3 files changed, 77 insertions(+), 3 deletions
On 5/26/2023 16:55, john.c.harri...@intel.com wrote:
From: Michal Wajdeczko
Instead of printing message fence twice, include HXG header of the
unexpected message and its len.
Signed-off-by: Michal Wajdeczko
Signed-off-by: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm
and the related fence is not
stored. Instead such messages are treated as unexpected, which will
give an indication of potential GuC misprogramming that warrants extra
debugging effort.
Signed-off-by: Michal Wajdeczko
Signed-off-by: John Harrison
Reviewed-by: John Harrison
---
.../gpu/drm
On 4/28/2023 11:58, Daniele Ceraolo Spurio wrote:
Follow the same logic as DG2, so just a meu binary with no version number.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion
.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
---
drivers/gpu/drm/i915/i915_getparam.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..7aa47550e4f2 100644
On 4/28/2023 11:58, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
binaries being considered fully
On 4/28/2023 11:58, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between
On 5/2/2023 08:27, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication have contain the
have contain?
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the meu
'meu manifest'
On 4/28/2023 11:58, Daniele Ceraolo Spurio wrote:
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is
On 5/16/2023 13:52, Rodrigo Vivi wrote:
On Tue, May 16, 2023 at 12:21:05PM -0700, John Harrison wrote:
On 5/16/2023 12:17, Belgaumkar, Vinay wrote:
> On 4/18/2023 11:17 AM, [1]john.c.harri...@intel.
On 5/16/2023 12:17, Belgaumkar, Vinay wrote:
On 4/18/2023 11:17 AM, john.c.harri...@intel.com wrote:
From: John Harrison
This is useful for getting debug information out in certain
situations, such as failing kernel selftests and CI runs that don't
log error captures. It is especially useful
On 5/4/2023 13:29, Lucas De Marchi wrote:
On Thu, May 04, 2023 at 01:22:52PM -0700, john.c.harri...@intel.com
wrote:
From: John Harrison
Also switch to using reduced version file naming as it is no longer
such a work-in-progress and likely to change.
Signed-off-by: John Harrison
commit
On 4/28/2023 17:30, John Harrison wrote:
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation
On 4/28/2023 17:26, Ceraolo Spurio, Daniele wrote:
On 4/28/2023 5:16 PM, John Harrison wrote:
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
On 4/28/2023 17:19, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If the DEBUG_GEM config option is set then escalate the 'unexpected
firmware version' message from a notice to an error. This will ensure
that the CI system treats
On 4/28/2023 17:04, Ceraolo Spurio, Daniele wrote:
On 4/20/2023 6:15 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out
On 4/25/2023 11:54, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
alan:snip
@@ -177,32 +177,32 @@ static const struct
On 4/26/2023 10:29, John Harrison wrote:
On 4/25/2023 12:05, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700,john.c.harri...@intel.com wrote:
From: John Harrison
Fix Xe_LP name.
Signed-off-by: John Harrison
alan:snip
-/* GEN9/XE_LPD - Render / Compute Per-Engine
On 4/25/2023 12:05, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700,john.c.harri...@intel.com wrote:
From: John Harrison
Fix Xe_LP name.
Signed-off-by: John Harrison
alan:snip
-/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
+/* GEN8+ Render / Compute Per
On 4/25/2023 10:55, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
From: John Harrison
A pair of pre-Xe registers were being included in the Xe capture list.
GuC was rejecting those as being invalid and logging errors about
them. So, stop doing
On 4/19/2023 10:33, Ceraolo Spurio, Daniele wrote:
On 4/19/2023 10:12 AM, John Harrison wrote:
On 4/19/2023 10:02, John Harrison wrote:
On 4/18/2023 16:24, Ceraolo Spurio, Daniele wrote:
Typo doplicate in patch title
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
On 4/19/2023 10:02, John Harrison wrote:
On 4/18/2023 16:24, Ceraolo Spurio, Daniele wrote:
Typo doplicate in patch title
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that duplicte entries in the firmware table could cause
typo duplicte
On 4/18/2023 16:24, Ceraolo Spurio, Daniele wrote:
Typo doplicate in patch title
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that duplicte entries in the firmware table could cause
typo duplicte
an infinite loop in the firmware loading code
On 4/18/2023 15:46, Ceraolo Spurio, Daniele wrote:
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification
On 4/18/2023 16:14, Ceraolo Spurio, Daniele wrote:
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. Potentially
On 4/11/2023 07:41, Rodrigo Vivi wrote:
On Mon, Apr 10, 2023 at 12:25:21PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Sometimes, the only effective way to debug an issue is to dump all the
interesting information at the point of failure. So add support for
doing
On 4/3/2023 17:34, Matt Roper wrote:
On Mon, Apr 03, 2023 at 02:33:34PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
A pair of pre-Gen12 registers were being included in the Gen12 capture
list. GuC was rejecting those as being invalid and logging errors
about them. So, stop
On 3/22/2023 13:59, Ceraolo Spurio, Daniele wrote:
On 3/22/2023 12:44 PM, John Harrison wrote:
On 3/20/2023 14:10, Daniele Ceraolo Spurio wrote:
The WA states that we need to alert the GSC FW before doing a GSC
engine
reset and then wait for 200ms. The GuC owns engine reset, so on the
i915
urn it off. The default on MTL is
also for GuC to own engine reset, with i915 only covering full-GT reset.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Andi Shyti
Cc: Mika Kuoppala
Cc: Gwan-gyeong Mun
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/intel_reset.c | 35 +++--
1 - 100 of 517 matches
Mail list logo
