From: John Harrison
There is a module parameter for controlling what GuC/HuC features are
enabled. Setting to -1 means 'use the default'. However, the default
is not well defined, out of date and needs to be different across
platforms.
Signed-off-by: John Harrison
CC: Daniele Ceraolo Spurio
--
From: John Harrison
Various UMDs need to know the L3 bank count. So add a query API for it.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_gt.c | 15 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
drivers/gpu/drm/i915/i915_query.c | 22 ++
drive
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interes
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC. Further information
can be calculated dynamically from fuse registers.
Signed-off-by: John Harri
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
This patch also adds a header file which lists all the attribute values
curre
From: Rodrigo Vivi
All the static platform configuration per SKU is moving to
this KVL table. User Space components can query and parse
it to find the proper hw configuration instead of having
to hardcode it.
Add a query as both an example of how to fetch the table and to
validate the KLV conten
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. New interfaces have been added to the KMD to return
this informatio. So, add some tests for the new interfaces.
Signed-off-by: John Harrison
John Harrison (1):
tests/i915/query: Add test
From: John Harrison
Various UMDs need to know the L3 bank count. So a query API has been
added for it. Test that query.
Signed-off-by: John Harrison
---
include/drm-uapi/i915_drm.h | 1 +
tests/i915/i915_query.c | 35 +++
2 files changed, 36 insertions(+)
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So, until sw arch
approves a new algorithm and it is implemented in GuC, stop running
the test.
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So, until sw arch
approves a new algorithm and it is implemented in GuC, stop running
the test.
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So, until sw arch
approves a new algorithm and it is implemented in GuC, stop running
the test.
From: John Harrison
Fix a bunch of issues with gem_exec_capture with the ultimate aim of
making it pass on GuC enabled platforms.
Signed-off-by: John Harrison
John Harrison (8):
tests/i915/gem_exec_capture: Remove pointless assert
tests/i915/gem_exec_capture: Cope with larger page sizes
From: John Harrison
The 'many' test ended with an 'assert(count)', presumably meaning to
ensure that some objects were actually captured. However, 'count' is
the number of objects created not how many were captured. Plus, there
is already a 'require(count > 1)' at the start and count is invarient
From: John Harrison
The sysfs file read helper does not actually report any errors if a
realloc fails. It just silently returns a 'valid' but truncated
buffer. This then leads to the decode of the buffer failing in random
ways. So, add a check for ENOMEM being generated during the read.
Signed-o
From: John Harrison
The decode of the error capture contents was happening in two
different sub-tests with two very different pieces of code. One being
much more extensive than the other (actually decodes and verifies the
contents of the captured buffers rather than just the address). So,
move th
From: John Harrison
At some point, larger than 4KB page sizes were added to the i915
driver. This included adding an informational line to the buffer
entries in error capture logs. However, the error capture test was not
updated to skip this string, thus it would silently abort processing.
Signe
From: John Harrison
The syfs helper functions were all using basic 'int' data types for
sizs, offsets, etc. when reading from sysfs. This works fine for
little files, but not for large error capture logs (which can be
gigabytes in sizes).
Signed-off-by: John Harrison
---
lib/igt_sysfs.c | 17 +
From: John Harrison
Some of the capture tests were using explicit contexts, some not. Some
were poking the per engine pre-emption timeout, some not. This would
lead to sporadic failures due to random timeouts, contexts being
banned depending upon how many subtests were run and/or how many
engines
From: John Harrison
When GuC submission is enabled, GuC itself manages hang detection and
recovery. Therefore, any test that relies on being able to trigger an
engine reset in the driver will fail. Full GT resets can still be
triggered by the driver. However, in that situation detecting the
speci
From: John Harrison
With GuC submission, engine resets are handled entirely within GuC
rather than within i915. Traditionally, IGT has disallowed engine
based resets becuase they don't send the uevent which IGT uses to
check for unexpected resets. However, it is important to be able to
test all r
From: John Harrison
When i915 receives a context reset notification from GuC, it triggers
an error capture before resetting any outstanding requsts of that
context. Unfortunately, the error capture is not a time bound
operation. In certain situations it can take a long time, particularly
when mul
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A new interface has been added to the KMD to return
this information. So, add a test for the new interface.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
Rodrigo Vivi (1):
test
From: Rodrigo Vivi
Newer platforms have an embedded table giving details about that
platform's hardware configuration. This table can be retrieved from
the KMD via the existing query API. So add a test for it as both an
example of how to fetch the table and to validate the contents as much
as is
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.
Test-with: 20210915215558.2473428-2-john.c.harri...@intel.com
UMD: https://github.com/intel/comp
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interes
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Mich
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.
v2: Add a kerneldoc comment.
Test-with: 20210915215558.2473428-2-john.c.harri...@intel.com
UMD:
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Mich
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interes
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A new interface has been added to the KMD to return
this information. So, add a test for the new interfaces.
Signed-off-by: John Harrison
Rodrigo Vivi (1):
tests/i915/query: Query, parse
From: Rodrigo Vivi
Newer platforms have an embedded table giving details about that
platform's hardware configuration. This table can be retrieved from
the KMD via the query API. So add a test for it as both an example of
how to fetch the table and to validate the contents as much as
possible.
S
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Mich
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interes
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.
Test-with: 20210727002812.43469-2-john.c.harri...@intel.com
UMD: https://github.com/intel/comput
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Mich
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.
Test-with: 20210727002812.43469-2-john.c.harri...@intel.com
UMD: https://github.com/intel/comput
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interes
From: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index b9f66dbd46bb..a61e23deeb00 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++
From: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 3 +
drivers/gpu/drm/i915/i915_gpu_error.c | 97 +
drivers/gpu/drm/i915/i915_gpu_error.h | 3 +
3 files changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/
From: Venkata Sandeep Dhanalakota
Defining vma on stack can cause stack overflow, if
vma gets populated with new fields.
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 18 ++
From: Daniele Ceraolo Spurio
The firmware binary has to be loaded from lmem and the recommendation is
to put all other objects in there as well. Note that we don't fall back
to system memory if the allocation in lmem fails because all objects are
allocated during driver load and if we have issues
From: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8290bdadd167..a530a65e6f2a 100644
--- a/drivers/gpu/dr
From: Matthew Brost
Add DG1 GuC / HuC firmware defs
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(+)
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 f8cb00ffb506..a685d563df7
From: John Harrison
Minimum set of patches to enable GuC submission on DG1 and enable it by
default.
A little difficult to test as IGTs do not work with DG1 due to a bunch
of uAPI features being disabled (e.g. relocations, caching memory
options, etc...). Hence extra patches at the end to enable
From: Matthew Brost
Enable GuC submission by default on DG1
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index b104fb7607
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.
Test-with: 20210727002812.43469-2-john.c.harri...@intel.com
UMD: https://github.com/intel/comput
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Mich
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interes
From: John Harrison
Minimum set of patches to enable GuC submission on DG1 and enable it by
default.
A little difficult to test as IGTs do not work with DG1 due to a bunch
of uAPI features being disabled (e.g. relocations, caching memory
options, etc...). Hence extra patches at the end to enable
From: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2f2434b52317..390019fdcd6b 100644
--- a/drivers/gpu/dr
From: Venkata Sandeep Dhanalakota
Defining vma on stack can cause stack overflow, if
vma gets populated with new fields.
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 18 ++
From: Matthew Brost
Enable GuC submission by default on DG1
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 86c318516e
From: Matthew Brost
Add DG1 GuC / HuC firmware defs
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(+)
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 f8cb00ffb506..a685d563df7
From: Vinay Belgaumkar
Seeing these errors when GT is likely in suspend state-
"RPM wakelock ref not held during HW access"
Ensure GT is awake before trying to access HW registers. Avoid
reading the register if that is not the case.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/
From: Daniele Ceraolo Spurio
The firmware binary has to be loaded from lmem and the recommendation is
to put all other objects in there as well. Note that we don't fall back
to system memory if the allocation in lmem fails because all objects are
allocated during driver load and if we have issues
From: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index b9f66dbd46bb..a61e23deeb00 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++
From: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 3 +
drivers/gpu/drm/i915/i915_gpu_error.c | 97 +
drivers/gpu/drm/i915/i915_gpu_error.h | 3 +
3 files changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/
The following changes since commit 0f66b74b6267fce66395316308d88b0535aa3df2:
cypress: update firmware for cyw54591 pcie (2021-06-09 07:12:02 -0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware adlp_updates
for you to fetch changes up to 38983b6f28e0
From: John Harrison
There is a new HuC version available for TGL and compatible platforms,
so switch to using it. Also, there is now a GuC and HuC for ADL-P, so
use those too.
Signed-off-by: John Harrison
John Harrison (2):
drm/i915/huc: Update TGL and friends to HuC 7.9.3
drm/i915/adlp:
From: John Harrison
Add ADL-P to the list of supported GuC and HuC firmware versions. For
HuC, it reuses the existing TGL firmware file. For GuC, there is a
dedicated firmware release.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
1 file changed, 1 insertion(
From: John Harrison
A new HuC is available for TGL and compatible platforms, so switch to
using it.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/dr
The following changes since commit d79c26779d459063b8052b7fe0a48bce4e08d0d9:
amdgpu: update vcn firmware for green sardine for 21.20 (2021-06-29 07:26:03
-0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware guc_62.0_huc_7.9
for you to fetch changes
The following changes since commit d79c26779d459063b8052b7fe0a48bce4e08d0d9:
amdgpu: update vcn firmware for green sardine for 21.20 (2021-06-29 07:26:03
-0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware guc_62.0_huc_7.9
for you to fetch changes
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
ATS has lots of extra media engines. This series adds support for them.
Note, a recent GuC FW is required - 32.0.3 is known to be good.
Version 31.0.1 causes a hang when i915 initialised the fifth VCS
engine.
v2: Clean up the I915_MAX_ENGINES define. Make assumptions about A
From: John Harrison
ATS has lots of extra media engines. This patch adds the interrupt
handler support for them.
v2: Changed debugfs to assume ATS always has VCSx8 + VECSx4
irrespective of fusings. [Tvrtko Ursulin]
v3: Changed interrupt masking to check for the presence of each pair
of engines
From: John Harrison
The current GuC FW release (31.0.1) dies when presented with too many
media engines. The issue was fixed by 32.0.3 (which is the next FW the
driver is intending to switch to). It is desirable to merge the the
patches which allow use of the new engines before the new GuC FW
pat
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
The intended usage model for struct fence is that the signalled status
should be set on demand rather than polled. That is, there should not
be a need for a 'signaled' function to be called everytime the status
is queried. Instead, 'something' should be done to enable a signal
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
Newer hardware has support for making LRI accesses to MMIO registers
relative to the engine that is executing the LRI instruction. This is
required for things like hardware based load balancing across engines.
John Harrison (2):
drm/i915: Engine relative MMIO
drm/i915: En
From: John Harrison
Gen12 introduces a completely new and different scheme for
implementing engine relative MMIO accesses - MI_LRI_MMIO_REMAP. This
requires using the base address of instance zero of the relevant
engine class. And then, it is only valid if the register in
question falls within a
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
Newer hardware has support for making LRI accesses to MMIO registers
relative to the engine that is executing the LRI instruction. This is
required for things like hardware based load balancing across engines.
John Harrison (2):
drm/i915: Engine relative MMIO
drm/i915: En
From: John Harrison
Gen12 introduces a completely new and different scheme for
implementing engine relative MMIO accesses - MI_LRI_MMIO_REMAP. This
requires using the base address of instance zero of the relevant
engine class. And then, it is only valid if the register in
question falls within a
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engi
From: John Harrison
Newer hardware adds flags to the whitelist work-around register. These
allow per access direction privileges and ranges.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 ++
From: John Harrison
Updated whitelist table for ICL.
v2: Reduce changes to just those required for media driver until
the selftest can be updated to support the new features of the
other entries.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
From: "Robert M. Fosha"
Updates the live_workarounds selftest to handle whitelisted
registers that are flagged as read only.
Signed-off-by: Robert M. Fosha
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/selftest_workarounds.c| 43 +--
1 file changed, 39 insertions(+)
From: John Harrison
Newer hardware requires setting up whitelists on engines other than
render. So, extend the whitelist code to support all engines.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds
From: John Harrison
Recent hardware adds support for finer-grained control over
whitelisting, allowing registers to be whitelisted independently
for reads and/or writes. This series will add the basic plumbing
to support that.
John Harrison (3):
drm/i915: Support flags in whitlist WAs
drm/i9
From: John Harrison
Newer hardware supports extra feature in the whitelist registers. This
patch updates the selftest to test that entries marked as read only
are actually read only.
Also updated the read/write access definitions to make it clearer that
they are an enum field not a set of single
From: John Harrison
Follow up patch to earlier whitelist updates. This series adds some
extra sanity checking to the driver and improves the self-test.
John Harrison (2):
drm/i915: Add test for invalid flag bits in whitelist entries
drm/i915: Implement read-only support in whitelist selftest
From: John Harrison
As per review feedback by Tvrtko, added a check that no invalid bits
are being set in the whitelist flags fields.
Also updated the read/write access definitions to make it clearer that
they are an enum field not a set of single bit flags.
Signed-off-by: John Harrison
CC: Tv
From: John Harrison
Newer hardware supports extra feature in the whitelist registers. This
patch updates the selftest to test that entries marked as read only
are actually read only.
Signed-off-by: John Harrison
CC: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/selftest_workarounds.c| 43 +++
From: John Harrison
There is a debug message in the workaround initialisation path that
reports how many entries were added of each type. However, whitelist
workarounds exist for multiple engines but the type name is just
'whitelist'. Tvrtko suggested adding the engine name to make the
message mo
From: Vinay Belgaumkar
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so that Punit will pay heed to our request.
Signed-off-by: Vinay Belgaumkar
---
dr
From: John Harrison
Fix a potential null pointer dereference, improve debug crash reports,
improve code separation.
v2: Reposting as reduced set of patches due to CI failures.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/uc: Allow platforms to have GuC but not HuC
drm/i915/g
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
Reviewed-by:
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigge
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log_debu
From: John Harrison
Fix a potential null pointer dereference, improve debug crash reports,
improve code separation, improve GuC log read speed.
Signed-off-by: John Harrison
John Harrison (4):
drm/i915/uc: Allow platforms to have GuC but not HuC
drm/i915/guc: Speed up GuC log dumps
drm/
From: John Harrison
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits. That means reading the log from graphics memory many times -
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
Reviewed-by:
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigge
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log_debu
From: John Harrison
Allow engine resets on RCS, report problems with engine resets,
improve GuC log usability.
Signed-off-by: John Harrison
John Harrison (4):
drm/i915/guc: Speed up GuC log dumps
drm/i915/guc: Increase GuC log size for CONFIG_DEBUG_GEM
drm/i915/guc: Flag an error if an
1 - 100 of 1554 matches
Mail list logo
