The mapping from enum port to whatever port numbering scheme is used by
the SWSCI Display Power State Notification is odd, and the memory of it
has faded. In any case, the parameter only has space for ports numbered
[0..4], and UBSAN reports bit shift beyond it when the platform has port
F or
Add a reusable function for checking the SWSCI function.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 30 +--
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
Newer platforms aren't supposed to have mailbox #2 or SWSCI
support. Bail out early from encoder notify if that is the case,
skipping the out-of-bounds checks and debug messages.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 6 ++
1 file
Opregion Mailbox #2 is obsolete for SWSCI usage in opregion v2.x, and
repurposed in opregion v3.x. Warn about obsole mailbox presence in v2.x,
and ignore with an error for v3.x.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 14 +++---
Start debug logging about the presence of the new Mailbox #2 for
backlight. Actual support is to be added later.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git
Fix the UBSAN reported bit shift out of bounds first, as it's stable
backport material. Clean some stuff up after that.
Jani Nikula (5):
drm/i915/opregion: check port number bounds for SWSCI display power
state
drm/i915/opregion: abstract the check for valid swsci function
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98837/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98837/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11077_full -> Patchwork_21993_full
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98837/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/i915_gem_evict.c:150: warning:
On 1/7/22 6:26 PM, José Expósito wrote:
Hi Simon,
On Wed, Jan 05, 2022 at 11:54:43PM +, Simon Ser wrote:
Pushed patches 1 & 2 to drm-misc-next. Thanks for your contribution!
Thanks a lot for the review and for applying the changes, appreciate it.
Is there something that needs to
On 1/13/22 12:44, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some
== Series Details ==
Series: drm/i915/opregion: fixes and cleanups
URL : https://patchwork.freedesktop.org/series/98836/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11077 -> Patchwork_21992
Summary
---
**FAILURE**
Previously, short term pinning in execbuf was required because i915_vma was
effectively independent from objects, and has its own refcount, locking,
lifetime rules and pinning.
This series removes the separate locking, by requiring vma->obj->resv to be
held when pinning and unbinding. This will
On 1/13/22 12:44, Maarten Lankhorst wrote:
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Changes since v1:
- Remove -ENOSPC warning, can still
On 13.01.2022 00:26, Matthew Brost wrote:
> On Thu, Jan 13, 2022 at 12:21:17AM +0100, Michal Wajdeczko wrote:
>> On 11.01.2022 17:30, Matthew Brost wrote:
...
>>> @@ -1863,6 +1861,33 @@ static void guc_submit_request(struct i915_request
>>> *rq)
>>> spin_unlock_irqrestore(_engine->lock,
On 1/13/22 12:44, Maarten Lankhorst wrote:
Because we will start to require the obj->resv lock for unbinding,
ensure these shrinker functions also take the lock.
Perhaps "vma eviction utilities" rather than "shrinker functions"?
This requires some function signature changes, to ensure that
On 1/13/22 12:44, Maarten Lankhorst wrote:
We want to remove more members of i915_vma, which requires the locking to be
Checkpatch.pl warning.
We want to remove more members of i915_vma, which requires the locking to be
held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to the
object may be held by
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some objects' locks.
Previously, this was spread over
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
protected by the object lock.
This removes the need to unpin, which is done by just releasing the
lock.
eb_reserve is slightly reworked for readability, but the same steps
are still done:
- First pass pins with NONBLOCK.
- Second
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Changes since v1:
- Remove -ENOSPC warning, can still happen with concurrent mmaps
where we can't
Because we will start to require the obj->resv lock for unbinding,
ensure these shrinker functions also take the lock.
This requires some function signature changes, to ensure that the
ww context is passed around, but is mostly straightforward.
Previously this was split up into several patches,
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 55
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98837/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11077 -> Patchwork_21993
On 13-01-2022 15:33, Thomas Hellström (Intel) wrote:
>
> On 1/13/22 12:44, Maarten Lankhorst wrote:
>> i915_gem_evict_vm will need to be able to evict objects that are
>> locked by the current ctx. By testing if the current context already
>> locked the object, we can do this correctly. This
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98837/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6c3515b331fc drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent
On 1/13/22 12:44, Maarten Lankhorst wrote:
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
Reviewed-by:
On Thu, 2022-01-13 at 17:56 +, Patchwork wrote:
Patch Details
Series: drm/i915/display/ehl: Update voltage swing table
URL:https://patchwork.freedesktop.org/series/98844/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21994/index.html
CI Bug Log -
On Thu, Jan 13, 2022 at 11:59:35AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The capture test was still using old style ring_id and ring_name
> (derived from the engine structure at the higher level). Update it to
> just take the engine structure directly.
>
>
On Thu, Jan 13, 2022 at 06:58:47PM +0200, Jani Nikula wrote:
> On Wed, 12 Jan 2022, Rodrigo Vivi wrote:
> > I understand that I'm late to the fun here, but I got myself wondering if
> > we couldn't separated the registers in a "regs" directory
> > and find some way to organize them in IP blocks
== Series Details ==
Series: drm/i915: Flip guc_id allocation partition (rev5)
URL : https://patchwork.freedesktop.org/series/98751/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11079 -> Patchwork_22000
Summary
---
On 1/13/2022 12:10, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the
On Thu, Jan 06, 2022 at 12:02:36PM -0800, Juston Li wrote:
> Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock during
> PXP suspend") but to fix the same warning for unbind during shutdown:
>
> [ cut here ]
> RPM wakelock ref not held during HW access
>
On 1/13/2022 12:30, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:41AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The hang test was relying on context persitence for no particular
reason. That is, it would set a bunch of background spinners running
then immediately
On Thu, Jan 13, 2022 at 12:50:29PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A lot of tests use almost identical code for creating a batch buffer
> which does a single write to memory and another is about to be added.
> Instead, move the most generic version into a common
On 1/13/2022 13:06, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:44AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b23f83ef9a7b5414e2a10100adc4291f
== Series Details ==
Series: drm/i915: Flip guc_id allocation partition (rev5)
URL : https://patchwork.freedesktop.org/series/98751/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079_full -> Patchwork_22000_full
Summary
On Thu, Jan 13, 2022 at 01:26:53PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The global context used by all the subtests for causing hangs is
> marked as unbannable. However, some of the subtests set background
> spinners running on all engines using a freshly created
On Thu, Jan 13, 2022 at 11:59:45AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Various tests want to configure engine properties such as pre-emption
> timeout and heartbeat interval. Some don't bother to restore the
> original values again afterwards. So, add a helper to
On Thu, Jan 13, 2022 at 11:59:46AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Some platforms have very long timeouts configured for some engines.
> Some have them disabled completely. That makes for a very slow (or
> broken) hangman test. So explicitly configure the
On Thu, Jan 13, 2022 at 11:59:47AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The test was updated some engine properties but not restoring them
> afterwards. That would leave the system in a non-default state which
> could potentially affect subsequent tests. Fix it by
On Wed, Jan 12, 2022 at 05:28:29PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 12, 2022 at 07:06:45PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 12, 2022 at 04:21:28PM -0800, Lucas De Marchi wrote:
> > > On Wed, Jan 12, 2022 at 06:08:05PM -0600, Bjorn Helgaas wrote:
> > > > On Wed, Jan 12, 2022
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough
On Thu, Jan 13, 2022 at 11:59:43AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The global context used by all the subtests for causing hangs is
> marked as unbannable. However, some of the subtests set background
> spinners running on all engines using a freshly created
On 1/13/2022 13:01, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:43AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
v2: Use _device_coherent instead of _wc for
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough
On Thu, 2022-01-13 at 19:59 +, Patchwork wrote:
Patch Details
Series: drm/i915/display/adlp: Implement new step in the TC voltage swing prog
sequence
URL:https://patchwork.freedesktop.org/series/98853/
State: success
Details:
On Thu, Jan 13, 2022 at 11:59:41AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The hang test was relying on context persitence for no particular
> reason. That is, it would set a bunch of background spinners running
> then immediately destroy the active contexts but expect
On Thu, Jan 13, 2022 at 12:42:28PM -0800, John Harrison wrote:
> On 1/13/2022 12:30, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 11:59:41AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > The hang test was relying on context persitence for no particular
> > >
On Thu, Jan 13, 2022 at 11:59:42AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> As opposed to only on the non-target engines. This means that there is
> some other workload present for the scheduler to switch between and so
> detet the hang immediately.
>
> Signed-off-by:
On Thu, Jan 13, 2022 at 11:59:44AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The update to use intel_ctx_t missed a line that configures the
> context to allow hanging. Fix that.
>
> Fixes: 09c36188b23f83ef9a7b5414e2a10100adc4291f
Typically I thought the Fixes comment
On Thu, Jan 13, 2022 at 11:59:38AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The hangman framework sets up a context that is valid for all engines
> and has things like banning disabled. The 'unterminated' test then
> ignores it and uses the default context. Fix that.
>
On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A lot of tests use almost identical code for creating a batch buffer
> which does a single write to memory and another is about to be added.
> Instead, move the most generic version into a common
On Thu, Jan 13, 2022 at 11:59:40AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Added a an extra step to the i915_hangman tests to check that the
> system is still alive after the hang and recovery. This submits a
> simple batch to each engine which does a write to memory
On Thu, Jan 13, 2022 at 12:27:00PM -0800, John Harrison wrote:
> On 1/13/2022 12:10, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > A lot of tests use almost identical code for creating a batch buffer
> >
On 1/13/2022 12:23, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 12:27:00PM -0800, John Harrison wrote:
On 1/13/2022 12:10, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
A lot of tests use almost identical code for
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed
From: John Harrison
The hangman framework sets up a context that is valid for all engines
and has things like banning disabled. The 'unterminated' test then
ignores it and uses the default context. Fix that.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 1 +
1 file changed, 1
From: John Harrison
The test was updated some engine properties but not restoring them
afterwards. That would leave the system in a non-default state which
could potentially affect subsequent tests. Fix it by using the new
save/restore engine properties helper functions.
Signed-off-by: John
From: John Harrison
Although the hangman test was ensuring that *some* reset functionality
was enabled, it did not differentiate what kind. The infrastructure
required to choose between per engine reset or full GT reset was
recently added. So update this test to use it as well.
Signed-off-by:
From: John Harrison
The capture test was still using old style ring_id and ring_name
(derived from the engine structure at the higher level). Update it to
just take the engine structure directly.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 10 +-
1 file changed, 5
From: John Harrison
The hang test was relying on context persitence for no particular
reason. That is, it would set a bunch of background spinners running
then immediately destroy the active contexts but expect the spinners
to keep spinning. With the current implementation of context
persistence
From: John Harrison
As opposed to only on the non-target engines. This means that there is
some other workload present for the scheduler to switch between and so
detet the hang immediately.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 10 ++
1 file changed, 6
From: John Harrison
Various tests want to configure engine properties such as pre-emption
timeout and heartbeat interval. Some don't bother to restore the
original values again afterwards. So, add a helper to make it easier
to do this.
v2: Fix for platforms with no pre-emption capability.
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b23f83ef9a7b5414e2a10100adc4291f
Signed-off-by: John Harrison
---
tests/i915/gem_exec_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed
From: John Harrison
Some platforms have very long timeouts configured for some engines.
Some have them disabled completely. That makes for a very slow (or
broken) hangman test. So explicitly configure the engines to have
reasonable settings first.
Signed-off-by: John Harrison
---
== Series Details ==
Series: Remove some hacks required for GuC 62.0.0 (rev2)
URL : https://patchwork.freedesktop.org/series/98773/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079_full -> Patchwork_21999_full
Summary
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough
From: John Harrison
The above function was checking for valid rings via the old interface.
The new scheme is to check for engines on contexts as there are now
more engines than could be supported.
Signed-off-by: John Harrison
---
lib/igt_gt.c | 6 +++---
lib/igt_gt.h
From: John Harrison
Some of the IGT framework relies on receving a uevent when a hang
occurs. So add a test that this actually works.
While testing this, noticed that hangs could sometimes be missed
because the uevent was (presumably) still in flight by the time the
handler was de-registered.
From: John Harrison
The hangman framework sets up a context that is valid for all engines
and has things like banning disabled. The 'unterminated' test then
ignores it and uses the default context. Fix that.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
From: John Harrison
The capture test was still using old style ring_id and ring_name
(derived from the engine structure at the higher level). Update it to
just take the engine structure directly.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/i915_hangman.c | 10
From: John Harrison
Some platforms have very long timeouts configured for some engines.
Some have them disabled completely. That makes for a very slow (or
broken) hangman test. So explicitly configure the engines to have
reasonable settings first.
Signed-off-by: John Harrison
Reviewed-by:
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b ("tests/i915/gem_exec_fence: Convert to intel_ctx_t (v2)")
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/gem_exec_fence.c | 2 +-
From: John Harrison
The test was updated some engine properties but not restoring them
afterwards. That would leave the system in a non-default state which
could potentially affect subsequent tests. Fix it by using the new
save/restore engine properties helper functions.
Signed-off-by: John
From: John Harrison
The hang test was relying on context persitence for no particular
reason. That is, it would set a bunch of background spinners running
then immediately destroy the active contexts but expect the spinners
to keep spinning. With the current implementation of context
persistence
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
v2: Use _device_coherent instead of _wc for
From: John Harrison
As opposed to only on the non-target engines. This means that there is
some other workload present for the scheduler to switch between and so
detet the hang immediately.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/i915_hangman.c | 10 ++
From: John Harrison
Although the hangman test was ensuring that *some* reset functionality
was enabled, it did not differentiate what kind. The infrastructure
required to choose between per engine reset or full GT reset was
recently added. So update this test to use it as well.
Signed-off-by:
From: John Harrison
Various tests want to configure engine properties such as pre-emption
timeout and heartbeat interval. Some don't bother to restore the
original values again afterwards. So, add a helper to make it easier
to do this.
v2: Fix for platforms with no pre-emption capability.
From: John Harrison
Fix a bunch of issues with i915_hangman and gem_exec_capture with the
ultimate aim of making them pass on GuC enabled platforms.
v2: Fixes to the store code. Add engine properties management.
v3: Fix for platforms without pre-emption.
v4: Simplify anti-ban code, support
From: John Harrison
Added descriptions of the various sub-tests and the test as a whole.
v2: Added missing linefeed (spotted by Petri)
Signed-off-by: John Harrison
Reviewed-by: Petri Latvala
---
tests/i915/i915_hangman.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> On 1/11/2022 15:11, Matthew Brost wrote:
> > Add a cancel request selftest that results in an engine reset to cancel
> > the request as it is non-preemptable. Also insert a NOP request after
> > the cancelled request and confirm that
== Series Details ==
Series: drm/i915/display/ehl: Update voltage swing table
URL : https://patchwork.freedesktop.org/series/98844/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079_full -> Patchwork_21994_full
Summary
Move the multi-lrc guc_id from the lower allocation partition (0 to
number of multi-lrc guc_ids) to upper allocation partition (number of
single-lrc to max guc_ids).
This will help when a native driver transitions to a PF after driver
load time. If the perma-pin guc_ids (kernel contexts) are in a
From: John Harrison
Fix a bunch of issues with i915_hangman and gem_exec_capture with the
ultimate aim of making them pass on GuC enabled platforms.
v2: Fixes to the store code. Add engine properties management.
Signed-off-by: John Harrison
John Harrison (15):
tests/i915/i915_hangman: Add
From: John Harrison
Although the hangman test was ensuring that *some* reset functionality
was enabled, it did not differentiate what kind. The infrastructure
required to choose between per engine reset or full GT reset was
recently added. So update this test to use it as well.
Signed-off-by:
From: John Harrison
The capture test was still using old style ring_id and ring_name
(derived from the engine structure at the higher level). Update it to
just take the engine structure directly.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 10 +-
1 file changed, 5
From: John Harrison
The hang test was relying on context persitence for no particular
reason. That is, it would set a bunch of background spinners running
then immediately destroy the active contexts but expect the spinners
to keep spinning. With the current implementation of context
persistence
From: John Harrison
The hangman framework sets up a context that is valid for all engines
and has things like banning disabled. The 'unterminated' test then
ignores it and uses the default context. Fix that.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 1 +
1 file changed, 1
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough
From: John Harrison
Some platforms have very long timeouts configured for some engines.
Some have them disabled completely. That makes for a very slow (or
broken) hangman test. So explicitly configure the engines to have
reasonable settings first.
Signed-off-by: John Harrison
---
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b23f83ef9a7b5414e2a10100adc4291f
Signed-off-by: John Harrison
---
tests/i915/gem_exec_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: John Harrison
The test was updated some engine properties but not restoring them
afterwards. That would leave the system in a non-default state which
could potentially affect subsequent tests. Fix it by using the new
save/restore engine properties helper functions.
Signed-off-by: John
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
Signed-off-by: John Harrison
---
From: John Harrison
Some of the IGT framework relies on receving a uevent when a hang
occurs. So add a test that this actually works.
While testing this, noticed that hangs could sometimes be missed
because the uevent was (presumably) still in flight by the time the
handler was de-registered.
1 - 100 of 156 matches
Mail list logo
