On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio
On 11/9/2022 03:35, Tvrtko Ursulin wrote:
On 08/11/2022 19:37, John Harrison wrote:
On 11/8/2022 01:08, Tvrtko Ursulin wrote:
On 07/11/2022 19:45, John Harrison wrote:
On 11/7/2022 06:09, Tvrtko Ursulin wrote:
On 04/11/2022 17:45, John Harrison wrote:
On 11/4/2022 03:01, Tvrtko Ursulin
On 11/30/2022 00:30, Tvrtko Ursulin wrote:
On 29/11/2022 21:12, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never happen. But in the case when one
Engine resets or engine reset failures? Hopefully the latter.
Oops. Yes, that was meant to say "e
On 11/23/2022 12:45, Michal Wajdeczko wrote:
On 23.11.2022 02:25, John Harrison wrote:
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
e the GuC objects.
In MTL, this fixes and issue where we try to overwrite the invalidation
function twice (once for each GuC), due to the GGTT being shared between
the primary and media GTs
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: Radhakrishna Sripada
Cc: John Harrison
Cc: Ar
On 12/1/2022 04:01, Tvrtko Ursulin wrote:
On 01/12/2022 11:56, Michal Wajdeczko wrote:
On 01.12.2022 01:41, John Harrison wrote:
On 11/23/2022 12:45, Michal Wajdeczko wrote:
On 23.11.2022 02:25, John Harrison wrote:
On 11/22/2022 09:54, Michal Wajdeczko wrote:
On 18.11.2022 02:58
On 12/12/2022 17:52, Umesh Nerlige Ramappa wrote:
On Tue, Nov 29, 2022 at 01:12:52PM -0800, 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
co
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 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, it
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: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/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
an
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/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 it
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/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 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 @@ stat
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/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 sys
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
for
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 of the
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/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 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 that.
No
On 3/3/2023 11:20, Ceraolo Spurio, Daniele wrote:
On 2/17/2023 3:47 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A failure to load the GuC is occasionally observed where the GuC log
actually showed that the GuC had loaded just fine. The implication
being that the load just took
idle we already
skip the wait & reset entirely and that this reduced wait would still
likely be too long to use in resume paths, it's not worth adding support
for this reduced wait.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: John Harrison
Cc: Rodrigo Vivi
---
drivers/g
atforms it is just easier to turn 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
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
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 u
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 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 complete
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' nee
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 "GSC-enabl
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 authenticat
.
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
--- a
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
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
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 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
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
olo Spurio
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 +-
driver
e names to match meu 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 Previ
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
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-by
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
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 the
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
e names to match meu 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 Harriso
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/
: 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
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 49 +++
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
---
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/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
t
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 i
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/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 a
ff-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 1
On 15/01/2016 14:55, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> All changes to timeline value come through the user via
> fence_timeline_signal() calls. When fence_timeline_destroy() is called no
> changes on timeline->value happens hence call fence_timeline_signal() with
> no increment is
On 19/01/2016 15:23, Gustavo Padovan wrote:
> Hi Daniel,
>
> 2016-01-19 Daniel Vetter :
>
>> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> This patch series de-stage the sync framework, and in order to accomplish
>>> that
>>> a bunch of cleanup
On 12/07/2016 19:08, Gustavo Padovan wrote:
> ...
>
> +++ b/include/linux/sync_file.h
> @@ -28,6 +28,7 @@
>* @name: name of sync_file. Useful for debugging
>* @sync_file_list: membership in global file list
>* @wq: wait queue for fence signaling
> + * @ena
On Fri, Sep 12, 2014 at 05:58:09PM +0200, Christian K?nig wrote:
> pass in a list of fences to wait for before beginning a command
submission.
The Android implementation has a mechanism for combining multiple sync
points into a brand new single sync pt. Thus APIs only ever need to take
in a si
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/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
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gu
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 9/6/2023 02:17, Andi Shyti wrote:
Hi John,
static void guc_cancel_busyness_worker(struct intel_guc *guc)
{
- cancel_delayed_work_sync(&guc->timestamp.work);
+ /*
+* When intel_gt_reset was called, task will hold a lock.
+* To cacel delayed work here, the
ne to less than 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
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 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 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'
spa
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
Signed-
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
Si
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: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 "gt/intel_rc
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/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
(https://p
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
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 th
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/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
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/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 unnecessar
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 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 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 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 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
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
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
. 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
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
most atomic 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.freed
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
401 - 500 of 527 matches
Mail list logo
