From: John Harrison
DG2 has issues. To work around one of these the GuC must schedule
apps in an exclusive manner across both RCS and CCS. That is, if a
context from app X is running on RCS then all CCS engines must sit
idle even if there are contexts from apps Y, Z, ... waiting to run. A
certain
From: John Harrison
Enable CCS/RCS arbitration scheduling in GuC to prevent CCS starvation
on DG2.
Signed-off-by: John Harrison
John Harrison (1):
drm/i915/guc: Enable compute scheduling on DG2
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_a
From: John Harrison
Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
From: John Harrison
An earlier patch added support for compute engines. However, it missed
enabling the anti-pre-emption w/a for the new engine class. So move
the 'compute capable' flag earlier and use it for the pre-emption w/a
test.
Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS setup
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence t
From: John Harrison
A workaround was added to the driver to allow compute workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.
However, this does not work well in
From: John Harrison
Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence t
From: John Harrison
An earlier patch added support for compute engines. However, it missed
enabling the anti-pre-emption w/a for the new engine class. So move
the 'compute capable' flag earlier and use it for the pre-emption w/a
test.
Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS setup
From: John Harrison
A workaround was added to the driver to allow compute workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.
However, this does not work well in
From: John Harrison
The way delimiters (underscores and dots) were added to the UC
filenames was different for different types of delimiter. Rationalise
them to all be done the same way - implicitly in the concatenation
macro rather than explicitly in the file name prefix.
Signed-off-by: John Ha
From: John Harrison
The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.
Also, while it is guaranteed that GuC version number components are
only 8-bits in size, other firmwa
From: John Harrison
Start using the 'submission API version' for deciding which GuC API to
use in the submission code.
Correct version number manipulation code to support full 32bit
major/minor/patch components, except for GuC which is guaranteed to be
8bit safe.
Other minor code clean ups arou
From: John Harrison
As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/int
From: John Harrison
It is technically possible to get a hung context without a valid
request. In such a situation, try to provide as much information in
the error capture as possible rather than just aborting and capturing
nothing.
Similarly, in the case of a engine reset failure the GuC is not
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' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
From: John Harrison
Engine resets are supposed to never happen. But in the case when one
does (due to unknwon reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is no
From: John Harrison
The way delimiters (underscores and dots) were added to the UC
filenames was different for different types of delimiter. Rationalise
them to all be done the same way - implicitly in the concatenation
macro rather than explicitly in the file name prefix.
Signed-off-by: John Ha
From: John Harrison
Start using the 'submission API version' for deciding which GuC API to
use in the submission code.
Correct version number manipulation code to support full 32bit
major/minor/patch components, except for GuC which is guaranteed to be
8bit safe.
Other minor code clean ups arou
From: John Harrison
As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/int
From: John Harrison
The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.
Also, while it is guaranteed that GuC version number components are
only 8-bits in size, other firmwa
From: John Harrison
Fix a bunch of assorted issues with firmware loading and GuC
intialisation.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Fix missing return code checks in submission init
drm/i915/guc: Fix a static analysis warning
drm/i915/uc: Fix two issues with ov
From: John Harrison
In the case where a firmware file is too large (e.g. someone
downloaded a web page ASCII dump from github...), the firmware object
is released but the pointer is not zerod. If no other firmware file
was found then release would be called again leading to a double kfree.
Also,
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
kerne
From: John Harrison
A static analyser was complaining about not checking for null
pointers. However, the location of the complaint can only be reached
in the first place if said pointer is non-null. Basically, if we are
using a v69 GuC then the descriptor pool is guaranteed to be alocated
at star
From: John Harrison
Fix a bunch of assorted issues with firmware loading and GuC
intialisation.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Fix missing return code checks in submission init
drm/i915/guc: Fix a static analysis warning
drm/i915/uc: Fix two issues with ov
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
kerne
From: John Harrison
In the case where a firmware file is too large (e.g. someone
downloaded a web page ASCII dump from github...), the firmware object
is released but the pointer is not zerod. If no other firmware file
was found then release would be called again leading to a double kfree.
Also,
From: John Harrison
A static analyser was complaining about not checking for null
pointers. However, the location of the complaint can only be reached
in the first place if said pointer is non-null. Basically, if we are
using a v69 GuC then the descriptor pool is guaranteed to be alocated
at star
From: John Harrison
Fix for a deadlock issue between the GuC busyness stats worker and GT
resets. Also fix kernel contexts not getting the correct scheduling
priority at start of day.
Signed-off-by: John Harrison
John Harrison (2):
drm/i915/guc: Properly initialise kernel contexts
drm/i91
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wai
From: John Harrison
If a context has already been registered prior to first submission
then context init code was not being called. The noticeable effect of
that was the scheduling priority was left at zero (meaning super high
priority) instead of being set to normal. This would occur with
kernel
From: John Harrison
Some of the GuC state dump messages were adding extra line feeds. When
printing via a DRM printer to dmesg, for example, that messes up the
log formatting as it loses any prefixing from the printer. Given that
the extra line feeds are just in the middle of random bits of GuC
s
From: John Harrison
Guc submission imposes new range limits on certain scheduling
parameters. The idempotent sections of the timeslice duration and
pre-emption timeout tests was exceeding those limits and so would fail.
Reduce the excessively large value (654s) to one which does not
overflow (54
From: John Harrison
The comparison in the search for a matching register capture node was
not the most readable. It was also assuming that a zero GuC id means
invalid, which it does not. So remove one invalid term, one redundant
term and re-format to keep each term on a single line, and only one
From: John Harrison
The seqno value actually written out to memory is no longer in the
regular HWSP. Instead, it is now in its own private timeline buffer.
Thus, it is no longer visible in an error capture. So, explicitly read
the value and include that in the capture.
v2: %d -> %u (Alan)
Signe
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 ring state
registers. Unfortunately, the register state being used is only valid
i
From: John Harrison
Ecodes got lost with the switch to GuC based register lists. Put them
back.
Seqno values got lost with the switch to per context timelines. Put
those back too.
v2: Rework the timeline patch to just read the single seqno value
rather than copying the entire object (Daniele)
v
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: A
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: A
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: A
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 ever so slightly longer than the 200ms
timeout. Given that the actual time should be tens of milliseconds at
th
From: John Harrison
Add more decoding of the GuC load failures. Also include information
about GT frequency to see if timeouts are due to a failure to boost
the clocks. Finally, increase the timeout to accommodate situations
where the clock boost does fail.
v2: Reduce timeout in release builds,
From: John Harrison
There are multiple ways in which the GuC load can fail. The driver was
reporting the status register as is, but not everyone can read the
matrix unfiltered. So add decoding of the common error cases.
Also, remove the comment about interrupt based load completion
checking bein
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes:
The following changes since commit bcdcfbcf0a8f24a914b8c163906e6ce93d7f8897:
linux-firmware: Update firmware file for Intel Bluetooth AX101 (2023-03-20
08:34:27 -0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware mtl_guc_70.6.4
for you to fetch cha
The following changes since commit bcdcfbcf0a8f24a914b8c163906e6ce93d7f8897:
linux-firmware: Update firmware file for Intel Bluetooth AX101 (2023-03-20
08:34:27 -0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware mtl_guc_70.6.5
for you to fetch cha
From: John Harrison
First release of GuC for Meteorlake.
NB: As this is still pre-release and likely to change, use explicit
versioning for now. The official, full release will use reduced
version naming.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file
From: John Harrison
First release of GuC for Meteorlake.
NB: As this is still pre-release and likely to change, use explicit
versioning for now. The official, full release will use reduced
version naming.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file
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 doing it.
Signed-off-by: John Harrison
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers for GuC error state
ca
From: John Harrison
At the end of each test, IGT does a drop caches call via sysfs with
special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes problems for debugging issues when CI
catches a "can't go idle" test failure. Best case, the CI system times
ou
From: John Harrison
Fix for a deadlock issue between the GuC busyness stats worker and GT
resets. Also fix kernel contexts not getting the correct scheduling
priority at start of day.
v2: Rename existing uses of _trylock rather than adding a _noretry
version. Also improve the comment a bit.
Sig
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wai
From: John Harrison
If a context has already been registered prior to first submission
then context init code was not being called. The noticeable effect of
that was the scheduling priority was left at zero (meaning super high
priority) instead of being set to normal. This would occur with
kernel
From: John Harrison
At the end of each test, IGT does a drop caches call via debugfs with
special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes problems for debugging issues when CI
catches a "can't go idle" test failure. Best case, the CI system times
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
Use the new GT oriented output message helpers where possible.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 25 +++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 9 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 50 --
dr
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
Use the new module oriented output message helpers where possible.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 108 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 98 ++--
2 files changed, 99 insertions(+)
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 | 222 +++---
1 file changed, 113 insertions(+), 109 deletions(-)
diff --git a/drivers/g
From: John Harrison
Create a set of HuC printers and start using them.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 31 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 23 +++
2 files changed, 35 insertions(+), 19 deletions(-)
d
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/gt/uc/intel_guc.h| 35 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 8 +--
.../gpu
From: John Harrison
Start using the 'submission API version' for deciding which GuC API to
use in the submission code.
Correct version number manipulation code to support full 32bit
major/minor/patch components, except for GuC which is guaranteed to be
8bit safe.
Other minor code clean ups arou
From: John Harrison
The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.
Also, while it is guaranteed that GuC version number components are
only 8-bits in size, other firmwa
From: John Harrison
The way delimieters (underscores and dots) were added to the UC
filenames was different for different types of delimter. Rationalise
them to all be done the same way - implicitly in the concatenation
macro rather than explicitly in the file name prefix.
Signed-off-by: John Ha
From: John Harrison
As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 6 +-
drivers/gpu/drm/i
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' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
From: John Harrison
It was noticed that the table order verification step was only being
run once rather than once per firmware type. Fix that.
Note that the long term plan is to convert this code to be a mock
selftest. It is already only compiled in when selftests are enabled.
And the work invo
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
Create a set of GuC printers and start using them.
v2: Tweaks to output messages. (review feedback from Michal W).
Split definitions to separate header (review feedback from Jani).
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 33 +---
From: John Harrison
Use the new module oriented output message helpers where possible.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 110 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 99 ++--
2 files changed, 102 insertions(+
From: John Harrison
Re-work the existing GuC CT printers and extend as required to match
the new wrapping scheme.
v2: Improve probe_error definition (review feedback from MichalW).
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 218 +++---
1 file
From: John Harrison
Create a set of HuC printers and start using them.
v2: Minor tweaks (review feedback from MichalW).
Split definitions into separate header (review feedback from Jani).
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 32
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a
From: John Harrison
The stats worker thread management was mis-matched between
enable/disable call sites. Fix those up. Also, abstract the cancel
code into a helper function rather than replicating in multiple places.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission
From: John Harrison
Improve failure code handling during GuC intialisation.
Signed-off-by: John Harrison
John Harrison (2):
drm/i915/guc: Improve clean up of busyness stats worker
drm/i915/guc: Fix missing return code checks in submission init
.../gpu/drm/i915/gt/uc/intel_guc_submission
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
kerne
From: John Harrison
It is technically possible to get a hung context without a valid
request. In such a situation, try to provide as much information in
the error capture as possible rather than just aborting and capturing
nothing.
Similarly, in the case of an engine reset failure the GuC is not
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 claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that t
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' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
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 information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submi
From: John Harrison
It is technically possible to get a hung context without a valid
request. In such a situation, try to provide as much information in
the error capture as possible rather than just aborting and capturing
nothing.
Similarly, in the case of an engine reset failure the GuC is not
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
internally. So it needs to grab the reference count internally as
well. The execlist only request based
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' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
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 information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/d
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 claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that t
901 - 1000 of 1556 matches
Mail list logo
