| Age | Commit message (Collapse) | Author |
|---|
|
There is no guarantee that spinners are and will be implemented
using batches. As we have igt_spin_t, manipulate it through
igt_spin_* functions consistently and hide the batch nature.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Instead of opencoding the poll into the spinner, use
a helper to check if spinner has started.
v2: use zero as presumed offset (Chris)
v3: cleanup the relocs (Chris)
v4: leave the domains to zero, avoid relocation (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the device doesn't support contexts, we expect them to fail with
-ENODEV before reporting -EIO if wedged.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Eek, I assumed the 'banned' subtest only applied to context platforms,
it doesn't. The basic test works for all, checking whether a second
context works after the first is banned however only applies to
platforms with contexts!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Lock down the new uABI that DRM_IOCTL_I915_GEM_CONTEXT_CREATE returns
-EIO when wedged.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
In triggering the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
v2: And send an execbuf down the new context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Older platforms need to clobber the display around a reset (incl. a
modeset to off, and a modeset back on), which can be much slower than
the reset itself. Give these platforms (gen2-4) some leniency and allow
them a higher limit before declaring them a failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
As we have moved to rcu/srcu to serialise the resets, individual resets
are subject to small variations in system grace periods. Allow for this
by only expecting the median reset time to be within our target, thereby
excluding noisy outliers from perturbing our results (but keep the
maximum capped to prevent horrid failures!)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Actually measure how many batches we can fit into a ring before
blocking, or else we may end up hanging the device earlier than
expected!
v2: Mostly conservative.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109014
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
|
Check that we are allowed to hang/reset the GPU before we actually do so
for the first time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
We can already move all the tests with distinct prefixes: gem_, gen3_
and i915_.
pm_ and drv_ tests will follow in batches, so we can do the
adjustments in the reporting/filtering layer of the CI system.
v2: Fix test-list.txt generation with meson
v3: Fix docs build (Petri)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Tested-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
