From: John Harrison
If a high priority task was to continuously submit batch buffers to
the driver, it could starve out any lower priority task from getting
any GPU time at all. To prevent this, the priority of a queued batch
buffer is bumped each time it does not get submitted to the hardware.
From: John Harrison
The scheduler keeps its own lock on various DRM objects in order to
guarantee safe access long after the original execbuff IOCTL has
completed. This is especially important when pre-emption is enabled as
the batch buffer might need to be submitted to the hardware multiple
time
From: John Harrison
The seqno value cannot always be used when debugging issues via trace
points. This is because it can be reset back to start, especially
during TDR type tests. Also, when the scheduler arrives the seqno is
only valid while a given request is executing on the hardware. While
the
From: John Harrison
The scheduler has always tracked batch buffer dependencies based on
DRM object usage. This means that it will not submit a batch on one
ring that has outstanding dependencies still executing on other rings.
This is exactly the same synchronisation performed by
i915_gem_object_
From: John Harrison
Ring space is reserved when constructing a request to ensure that the
subsequent 'add_request()' call cannot fail due to waiting for space
on a busy or broken GPU. However, the scheduler jumps in to the middle
of the execbuffer process between request creation and request
subm
From: Dave Gordon
Keep a local copy of the request pointer in the _final() functions
rather than dereferencing the params block repeatedly.
v3: New patch in series.
For: VIZ-1587
Signed-off-by: Dave Gordon
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
with their submission to the hardware. This basically means splitting
the execbuffer() function in half. This change rearranges some code
ready for the split to occur.
For: VIZ-1587
Signed-off-by: John Harr
From: John Harrison
The seqno value is now only used for the final test for completion of
a request. It is no longer used to track the request through the
software stack. Thus it is no longer necessary to allocate the seqno
immediately with the request. Instead, it can be done lazily and left
unt
From: John Harrison
The GPU scheduler has added an execution priority level to the context
object. There is an IOCTL interface to allow user apps/libraries to
set this priority. This patch updates the context paramter IOCTL test
to include the new interface.
For: VIZ-1587
Signed-off-by: John Har
From: John Harrison
A major point of the GPU scheduler is that it re-orders batch buffers
after they have been submitted to the driver. This leads to requests
completing out of order. In turn, this means that the retire
processing can no longer assume that all completed entries are at the
front o
From: John Harrison
MMIO flips are the preferred mechanism now but more importantly, pipe
based flips cause issues for the scheduler. Specifically, submitting
work to the rings around the side of the scheduler could cause that
work to be lost if the scheduler generates a pre-emption event on that
From: John Harrison
Updated the execbuffer() code to pass the packaged up batch buffer
information to the scheduler rather than calling execbuffer_final()
directly. The scheduler queue() code is currently a stub which simply
chains on to _final() immediately.
For: VIZ-1587
Signed-off-by: John Ha
From: John Harrison
Added trace points to the scheduler to track all the various events,
node state transitions and other interesting things that occur.
v2: Updated for new request completion tracking implementation.
v3: Updated for changes to node kill code.
v4: Wrapped some long lines to kee
From: John Harrison
Now that all the scheduler patches have been applied, it is safe to enable.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/driver
From: John Harrison
One of the major purposes of the GPU scheduler is to avoid stalling
the CPU when the GPU is busy and unable to accept more work. This
change adds support to the ring submission code to allow a ring space
check to be performed before attempting to submit a batch buffer to
the h
From: John Harrison
A later patch in this series re-organises the batch buffer submission
code. Part of that is to reduce the scope of a pm_get/put pair.
Specifically, they previously wrapped the entire submission path from
the very start to the very end, now they only wrap the actual hardware
su
From: John Harrison
The TDR code needs to know what the scheduler is up to in order to
work out whether a ring is really hung or not.
v4: Removed some unnecessary braces to keep the style checker happy.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 30
From: John Harrison
To aid with debugging issues related to the scheduler, it can be
useful to ensure that all batch buffers are submitted immediately
rather than queued until later. This change adds an override flag via
the module parameter to force instant submission.
For: VIZ-1587
Signed-off-
From: John Harrison
The scheduler needs to do interrupt triggered work that is too complex
to do in the interrupt handler. Thus it requires a deferred work
handler to process such tasks asynchronously.
v2: Updated to reduce mutex lock usage. The lock is now only held for
the minimum time within
From: John Harrison
When requesting that all GPU work is completed, it is now necessary to
get the scheduler involved in order to flush out work that queued and
not yet submitted.
v2: Updated to add support for flushing the scheduler queue by time
stamp rather than just doing a blanket flush.
v
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
from their subsequent submission to the hardware. This means that an
application which is continuously submitting buffers as fast as it can
could potentialy flood the driver. To prevent this, the driver now
From: John Harrison
Added a facility for triggering the scheduler state dump via a debugfs
entry.
v2: New patch in series.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 +
drivers/gpu/drm/i915/i915_scheduler.c | 9 ++
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
with submission of batch buffers to the hardware. Thus it is possible
for an application to close its DRM file handle while there is still
work outstanding. That means the scheduler needs to know about file
From: John Harrison
Initial creation of scheduler source files. Note that this patch
implements most of the scheduler functionality but does not hook it in
to the driver yet. It also leaves the scheduler code in 'pass through'
mode so that even when it is hooked in, it will not actually do very
m
From: John Harrison
When debugging batch buffer submission issues, it is useful to be able
to see what the current state of the scheduler is. This change adds
functions for decoding the internal scheduler state and reporting it.
v3: Updated a debug message with the new state_str() function.
v4:
From: John Harrison
The scheduler needs to know when requests have completed so that it
can keep its own internal state up to date and can submit new requests
to the hardware from its queue.
v2: Updated due to changes in request handling. The operation is now
reversed from before. Rather than th
From: Dave Gordon
Added an interface for user land applications/libraries/services to
set their GPU scheduler priority. This extends the existing context
parameter IOCTL interface to add a scheduler priority parameter. The
range is +/-1023 with +ve numbers meaning higher priority. Only
system pro
From: John Harrison
It is useful for know what the scheduler is doing for both debugging
and performance analysis purposes. This change adds a bunch of
counters and such that keep track of various scheduler operations
(batches submitted, completed, flush requests, etc.). The data can
then be read
From: John Harrison
Hardware sempahores require seqno values to be continuously
incrementing. However, the scheduler's reordering of batch buffers
means that the seqno values going through the hardware could be out of
order. Thus semaphores can not be used.
On the other hand, the scheduler super
From: John Harrison
When the seqno wraps around zero, the entire GPU is forced to be idle
for some reason (possibly only to work around issues with hardware
semaphores but no-one seems too sure!). This causes a problem if the
force idle occurs at an inopportune moment such as in the middle of
sub
From: John Harrison
If a given context submits too many hanging batch buffers then it will
be banned and no further batch buffers will be accepted for it.
However, it is possible that a large number of buffers may already
have been accepted and are sat in the scheduler waiting to be
executed. Thi
From: John Harrison
It is useful to be able to see what seqnos have actually popped out of
the hardware when viewing the scheduler status.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 10 ++
drivers/gpu/drm/i915/i915_scheduler.h | 1 +
2 files
From: John Harrison
It can be useful to be able to disable certain features (e.g. the
entire scheduler) via a module parameter for debugging purposes. A
parameter has the advantage of not being a compile time switch but
without implying that it can be changed dynamically at runtime.
For: VIZ-158
From: John Harrison
There are various parameters within the scheduler which can be tuned
to improve performance, reduce memory footprint, etc. This change adds
support for altering these via debugfs.
v2: Updated for priorities now being signed values.
For: VIZ-1587
Signed-off-by: John Harrison
From: John Harrison
The reserved space code was not cleaning up properly in the case where
the intel_ring_begin() call failed. This led to WARN_ONs firing about
a double reserve call when running the gem_reset_stats IGT test.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_lrc.c
From: Maarten Lankhorst
This allows users of dma fences to create a android fence.
v0.2: Added kerneldoc. (Tvrtko Ursulin).
v0.4: Updated comments from review feedback by Maarten.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Tvrtko Ursulin
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jes
From: John Harrison
There are useful statistics and debug information about fences that
can be returned via the scheduler's existing reporting mechanisms
(sysfs and debug output). These changes were previously part of the
patches that originally added those mechanisms. However, as the sync
framew
From: John Harrison
This patch set was originally part of the struct fence and scheduler
patch sets. However, it relies on de-staging the sync framework and
that is now being done by another group. Hence these patches had to be
split out into a separate series that can be merged after the de-stag
From: Maarten Lankhorst
Debug output assumes all sync points are built on top of Android sync
points and when we start creating them from dma-fences will NULL ptr deref
unless taught about this.
v0.4: Corrected patch ownership.
v0.5: Removed redundant braces to keep style checker happy
Signed-
From: John Harrison
The sync framework is now used by the i915 driver. Therefore it can be
moved out of staging and into the regular tree. Also, the public
interfaces can actually be made public and exported.
v0.3: New patch for series.
Signed-off-by: John Harrison
Signed-off-by: Geoff Miller
From: Peter Lawthers
In the 3.14 kernel, a signaled fence was indicated by the status field
== 1. In 4.x, a status == 0 indicates signaled, status < 0 indicates error,
and status > 0 indicates active.
This patch wraps the check for a signaled fence in a function so that
callers no longer needs t
From: John Harrison
The scheduler now supports sync framework fences being associated with
batch buffers. The execbuff IOCTL allows such fences to be passed in
from user land. This patch wires the two together so that the IOCTL no
longer needs to stall on the fence immediately. Instead the stall
From: John Harrison
The sync code has a facility for dumping current state information via
debugfs. It also has a way to re-use the same code for dumping to the
kernel log on an internal error. However, the redirection was rather
clunky and split the output across multiple prints at arbitrary
bou
From: John Harrison
There is a sync framework to allow work for multiple independent
systems to be synchronised with each other but without stalling
the CPU whether in the application or the driver. This patch adds
support for this framework to the GPU scheduler.
Batch buffers can now have sync
From: John Harrison
Various projects desire a mechanism for managing dependencies between
work items asynchronously. This can also include work items across
complete different and independent systems. For example, an
application wants to retrieve a frame from a video in device,
using it for rende
From: John Harrison
Note, this is a work in progress. It is being posted now as there is
work going on to change the debugging interface used by this test. So
it would be useful to get some comments on whether the proposed
changes will cause a problem for this test or whether the test itself
shou
From: John Harrison
There is a mutex_lock in the GuC send action code path to ensure
serialised access to the host-to-GuC mechanism. Acquiring the lock
apparently sees random stalls of around 6ms. That is even when the
lock is definitely not acquired by any other thread. In the case of
sending pr
From: John Harrison
The 'request pre-emption' GuC command seems to be slower than other
commands. It typically takes 20-30us on a GP-MRB system (BXT). That
means that the super-fast busy-spin wait in the GuC send action code
hits the 10us time out. It then drops through to the more system
friendl
From: John Harrison
While working on a customer project, it was noticed that the time
taken to issue a pre-emption request to the GuC would vary quite
significantly. The correct case was low microseconds but the worst
case was tens of milliseconds. Two separate issues were identified as
causing t
From: John Harrison
Back in the days of 4.11, there was a nested_enable_signaling()
function as part of the GuC submission path. It contained a BUG_ON to
ensure that the request being processed had not already been signaled.
However, there was a race condition that causes that BUG_ON to be hit.
W
From: John Harrison
The call to enable signaling was occuring after the request had been
sent to the GuC for execution on the hardware. That means that it is
possible for the request to actually complete before the code to
enable signaling has executed.
Potentially that means the request could b
From: John Harrison
There are various statistics being calculated multiple times in
multiple places while the log file is being read in. Some of these are
then re-calculated when the database is munged to correct various
issues with the logs. This patch consolidates the calculations into a
separa
From: John Harrison
Add an extra level to the databse key sort so that the ordering is
deterministic. If the time stamp matches, it now compares the key
itself as well (context/seqno). This makes it much easier to determine
if a change has actually broken anything. Previously back to back runs
wi
From: John Harrison
Cache the key count value rather than querying the hash every time.
Also assert that the database does not magically change size after the
fixups.
Signed-off-by: John Harrison
Cc: Tvrtko Ursulin
---
scripts/trace.pl | 9 ++---
1 file changed, 6 insertions(+), 3 deletio
From: John Harrison
The trace.pl script calculates a bunch of statistics. It also
re-generates some timestamp values to correct issues with the log
being processed. These operations were all mixed up together thus some
were done multiple times (with different results each time). Whereas
some stat
From: John Harrison
Delay the auto-generation of end/notify values until the point where
everything is known. As opposed to potentially generating them
multiple times with differing values.
Signed-off-by: John Harrison
Cc: Tvrtko Ursulin
---
scripts/trace.pl | 31 ++---
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 with 'last' still being NULL. The test would attempt to continue
but using a null pointer. Fix that by aborting the test if it fails t
From: John Harrison
If GuC hits an internal error (and survives long enough to report it
to the KMD), it is basically toast and will stop until a GT reset and
subsequent GuC reload is performed. Previously, the KMD just printed
an error message and then waited for the heartbeat to eventually kick
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 30 +--
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/inte
From: John Harrison
The GuC error capture list creation was including Gen8 registers on Xe
platforms. While fixing that, it was noticed that there were other
issues. The platform naming was wrong, the naming of lists was
misleading, the steered register code was duplicated and steered
registers w
From: John Harrison
Remove 99% duplicated steered register list code. Also, include the
pre-Xe steered registers in the pre-Xe list generation.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 112 +-
1 file changed, 29 insertions(+), 83 deletion
From: John Harrison
Fix Xe_LP name.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 44 +--
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ca
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.
Signed-off-by: John Harrison
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers for GuC error state
capture.
From: John Harrison
Don't use GEN9 as a prefix for register lists that contain all GEN8
registers.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_g
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.
Signed-off-by: John Harrison
John Harrison (2):
drm/i915: Dump error capture to kernel log
drm/i915/guc: Dump error ca
From: John Harrison
In the past, There have been sporadic CTB failures which proved hard
to reproduce manually. The most effective solution was to dump the GuC
log at the point of failure and let the CI system do the repro. It is
preferable not to dump the GuC log via dmesg for all issues as it i
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 for things like retrieving
GuC logs as GuC operation can't be tracked by adding printk or ftrace
entries.
From: John Harrison
GuC based register dumps in error capture logs were basically broken
for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
[IGT] gem_exec_balancer: starting subtest hang
[drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
[drm] GT0: GUC: No regi
From: John Harrison
Enhance the firmware table verification code to catch more potential
errors and to generally improve the code itself.
Track patch level version even on reduced version files to allow user
notification of missing bug fixes.
Detect another immediate failure case when loading G
From: John Harrison
Explain another potential firmware failure mode and early exit the
long wait if hit.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 ++
2 files changed, 7 insertions(+)
diff --
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 reported if it was older. However,
the patch version should really be tracked as well for the same
reasons. The K
From: John Harrison
It was noticed that duplicte entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
Ensure they don't by tweaking the table validation code to reject
d
From: John Harrison
If the GuC load is taking an excessively long time, the wait loop
currently prints the GT frequency. Extend that to include the GuC
status as well so we can see if the GuC is actually making progress or
not.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_
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 should be a selftest. But either way, the
first step is pulling it out into a separate function that can be
ca
From: John Harrison
In the past, There have been sporadic CTB failures which proved hard
to reproduce manually. The most effective solution was to dump the GuC
log at the point of failure and let the CI system do the repro. It is
preferable not to dump the GuC log via dmesg for all issues as it i
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.
v2: Extra CONFIG wrapping (review feedback from Rodrigo)
Signed-off-by: John Harrison
John Harrison (2):
drm/i915: Dump
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 for things like retrieving
GuC logs as GuC operation can't be tracked by adding printk or ftrace
entries.
From: John Harrison
If the GuC load is taking an excessively long time, the wait loop
currently prints the GT frequency. Extend that to include the GuC
status as well so we can see if the GuC is actually making progress or
not.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
-
From: John Harrison
Enhance the firmware table verification code to catch more potential
errors and to generally improve the code itself.
Track patch level version even on reduced version files to allow user
notification of missing bug fixes.
Detect another immediate failure case when loading G
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 reported if it was older. However,
the patch version should really be tracked as well for the same
reasons. The K
From: John Harrison
Explain another potential firmware failure mode and early exit the
long wait if hit.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 ++
2 fi
From: John Harrison
It was noticed that duplicate entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
Ensure they don't by tweaking the table validation code to reject
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 such occurences as a failure and logs a bug
about it (or fails the pre-merge testing).
Signed-off-by: John Harri
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 into a separate function that is only
called once per blob type at init time.
Also, drop the CONFIG_SELFTEST r
From: John Harrison
Dan Carpenter pointed out that 'err' was not being set in the case
where the GuC firmware version range check fails. Fix that.
Note that while this is bug fix for a previous patch (see Fixes tag
below). It is an exceedingly low risk bug. The range check is
asserting that the
From: John Harrison
The buffer decoding code doesn't cope well with unknown buffers. So
add an entry for the GuC CTB so that it gets decoded correctly.
Signed-off-by: John Harrison
---
tools/intel_error_decode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/intel_error_decode.c b/t
From: John Harrison
The error capture decoder was reporting invalid errors in batch
buffers and getting confused about the prescence of the GuC CTB. So
fix those up.
Signed-off-by: John Harrison
John Harrison (2):
lib/intel_decode: Decode Gen12 ring/batch instructions correctly
tools/inte
From: John Harrison
Some MI_ instructions have changed (or are just new) for Gen12. So
update the decoder code to match.
Signed-off-by: John Harrison
---
lib/i915/intel_decode.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/i915/intel_decode.c b/lib/i
From: John Harrison
Rename the 'default_' register list prefix to 'gen8_' as that is the
more accurate name.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/g
From: John Harrison
GuC based register dumps in error capture logs were basically broken
for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
[IGT] gem_exec_balancer: starting subtest hang
[drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
[drm] GT0: GUC: No regi
From: John Harrison
Remove 99% duplicated steered register list code. Also, include the
pre-Xe steered registers in the pre-Xe list generation.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 112 +-
1 file changed, 29
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.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers for
From: John Harrison
The GuC error capture list creation was including Gen8 registers on Xe
platforms. While fixing that, it was noticed that there were other
issues. The platform naming was wrong, the naming of lists was
misleading, the steered register code was duplicated and steered
registers w
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
Don't add Xe only GSC registers to pre-Xe devices that don't
even have a GSC engine.
Fix Xe_LP name.
Don't use GEN9 as a prefix for register lists that contain all GEN8
registers.
Rename the 'default
From: John Harrison
Explain another potential firmware failure mode and early exit the
long wait if hit.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 ++
2 fi
From: John Harrison
Enhance the firmware table verification code to catch more potential
errors and to generally improve the code itself.
Track patch level version even on reduced version files to allow user
notification of missing bug fixes.
Detect another immediate failure case when loading G
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 reported if it was older. However,
the patch version should really be tracked as well for the same
reasons. The K
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 into a separate function that is only
called once per blob type at init time.
Also, drop the CONFIG_SELFTEST r
From: John Harrison
It was noticed that duplicate entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
Ensure they don't by tweaking the table validation code to reject
From: John Harrison
If the GuC load is taking an excessively long time, the wait loop
currently prints the GT frequency. Extend that to include the GuC
status as well so we can see if the GuC is actually making progress or
not.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
-
701 - 800 of 1556 matches
Mail list logo
