summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/selftests
Commit message (Collapse)AuthorAgeFilesLines
* Merge drm-upstream/drm-next into drm-misc-nextGustavo Padovan2018-06-2016-279/+568
|\ | | | | | | | | | | | | We got a few conflicts in drm_atomic.c after merging the DRM writeback support, now we need a backmerge to unlock develop development on drm-misc-next. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
| * drm/i915/selftests: scrub 64KMatthew Auld2018-05-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We write all 4K page entries, even when using 64K pages. In order to verify that the HW isn't cheating by using the 4K PTE instead of the 64K PTE, we want to remove all the surplus entries. If the HW skipped the 64K PTE, it will read/write into the scratch page instead - which we detect as missing results during selftests. v2: much improved commentary (Chris) Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Changbin Du <changbin.du@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180511095140.25590-1-matthew.auld@intel.com
| * drm/i915/selftests: Only switch to kernel context when lockedChris Wilson2018-05-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | In igt_flush_test() we try to switch back to the kernel context, but we are only able to do so when we are called with struct_mutex held. More of my CI fallout from lockdep being temporarily suppressed :( Fixes: 4cdf65ce8cc2 ("drm/i915/selftests: Return to kernel context after each test") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180509065926.19207-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Create mock_engine() under struct_mutexChris Wilson2018-05-091-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling mock_engine() calls i915_timeline_init() and that requires struct_mutex to be held as it adds itself to the global list of timelines. This error was introduced by commit a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines") but the issue was masked in CI by the earlier lockdep spam. Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180508211056.17151-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Return to kernel context after each testChris Wilson2018-05-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | As we flush each test and wait for idle before the next, also switch back to the kernel context. This helps limit the amount of collateral damage a test may cause by resetting to the default state each time (and also helps clean up temporaries used by the test). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180508115312.12628-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Flush GPU activity before completing live_contextsChris Wilson2018-05-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | igt_ctx_exec() expects that we retire all active requests/objects before completing, so that when we clean up the files afterwards they are ready to be freed. Before we do so, it is then prudent to ensure that we have indeed retired the GPU activity, raising an error if it fails. If we do not, we run the risk of triggering an assertion when freeing the object: __i915_gem_free_objects:4793 GEM_BUG_ON(i915_gem_object_is_active(obj)) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180505091014.26126-2-chris@chris-wilson.co.uk
| * drm/i915/selftests: Refactor common flush_test()Chris Wilson2018-05-084-121/+91
| | | | | | | | | | | | | | | | | | Pull igt_flush_test() out into its own library before copying and pasting the code for a third time. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180505091014.26126-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Skip the execlists tests on !execlists machinesChris Wilson2018-05-041-0/+4
| | | | | | | | | | | | | | | | | | Ignore the tests looking at the innards of execlists and its submission tasklets on machines that don't support execlists! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180504124202.24894-1-chris@chris-wilson.co.uk
| * drm/i915: Lazily unbind vma on closeChris Wilson2018-05-042-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When userspace is passing around swapbuffers using DRI, we frequently have to open and close the same object in the foreign address space. This shows itself as the same object being rebound at roughly 30fps (with a second object also being rebound at 30fps), which involves us having to rewrite the page tables and maintain the drm_mm range manager every time. However, since the object still exists and it is only the local handle that disappears, if we are lazy and do not unbind the VMA immediately when the local user closes the object but defer it until the GPU is idle, then we can reuse the same VMA binding. We still have to be careful to mark the handle and lookup tables as closed to maintain the uABI, just allowing the underlying VMA to be resurrected if the user is able to access the same object from the same context again. If the object itself is destroyed (neither userspace keeping a handle to it), the VMA will be reaped immediately as usual. In the future, this will be even more useful as instantiating a new VMA for use on the GPU will become heavier. A nuisance indeed, so nip it in the bud. v2: s/__i915_vma_final_close/i915_vma_destroy/ etc. v3: Leave a hint as to why we deferred the unbind on close. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180503195115.22309-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: fix spelling mistake: "parmaters" -> "parameters"Colin Ian King2018-05-041-1/+1
| | | | | | | | | | | | | | | | | | Trivial fix to spelling mistake in pr_err error message Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180503154510.708-1-colin.king@canonical.com
| * drm/i915: Split i915_gem_timeline into individual timelinesChris Wilson2018-05-026-149/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to move to a more flexible timeline that doesn't assume one fence context per engine, and so allow for a single timeline to be used across a combination of engines. This means that preallocating a fence context per engine is now a hindrance, and so we want to introduce the singular timeline. From the code perspective, this has the notable advantage of clearing up a lot of mirky semantics and some clumsy pointer chasing. By splitting the timeline up into a single entity rather than an array of per-engine timelines, we can realise the goal of the previous patch of tracking the timeline alongside the ring. v2: Tweak wait_for_idle to stop the compiling thinking that ret may be uninitialised. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502163839.3248-2-chris@chris-wilson.co.uk
| * drm/i915: Move timeline from GTT to ringChris Wilson2018-05-024-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the future, we want to move a request between engines. To achieve this, we first realise that we have two timelines in effect here. The first runs through the GTT is required for ordering vma access, which is tracked currently by engine. The second is implied by sequential execution of commands inside the ringbuffer. This timeline is one that maps to userspace's expectations when submitting requests (i.e. given the same context, batch A is executed before batch B). As the rings's timelines map to userspace and the GTT timeline an implementation detail, move the timeline from the GTT into the ring itself (per-context in logical-ring-contexts/execlists, or a global per-engine timeline for the shared ringbuffers in legacy submission. The two timelines are still assumed to be equivalent at the moment (no migrating requests between engines yet) and so we can simply move from one to the other without adding extra ordering. v2: Reinforce that one isn't allowed to mix the engine execution timeline with the client timeline from userspace (on the ring). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502163839.3248-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Fix error checking for wait_var_timeoutChris Wilson2018-05-021-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old wait_on_atomic_t used a custom callback to perform the schedule(), which used my return semantics of reporting an error code on timeout. wait_var_event_timeout() uses the schedule() return semantics of reporting the remaining jiffies (1 if it timed out with 0 jiffies remaining!) and 0 on failure. This semantic mismatch lead to us falsely claiming a time out occurred. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106085 Fixes: d224985a5e31 ("sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new wait_var_event() API") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180417170638.20550-1-chris@chris-wilson.co.uk
| * Merge drm/drm-next into drm-intel-next-queuedJani Nikula2018-05-021-10/+4
| |\ | | | | | | | | | | | | | | | | | | | | | Need d224985a5e31 ("sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new wait_var_event() API") in dinq to be able to fix https://bugs.freedesktop.org/show_bug.cgi?id=106085. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Only track live rings for retiringChris Wilson2018-04-302-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list to being only gt->live_rings. v2: s/live/active/ for consistency with gt.active_requests Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-4-chris@chris-wilson.co.uk
| * | drm/i915: Retire requests along ringsChris Wilson2018-04-302-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines), leading to much hilarity in miscomputing the position of ring->head. As an added bonus, retiring along the ring reduces the penalty of having one execlists client do cleanup for another (old legacy submission shares a ring between all clients). The downside is that slow and irregular (off the critical path) process of cleaning up stale requests after userspace becomes a modicum less efficient. In the long run, it will become apparent that the ordered ring->request_list matches the ring->timeline, a fun challenge for the future will be unifying the two lists to avoid duplication! v2: We need both engine-order and ring-order processing to maintain our knowledge of where individual rings have completed upto as well as knowing what was last executing on any engine. And finally by decoupling retiring the contexts on the engine and the timelines along the rings, we do have to keep a reference to the context on each request (previously it was guaranteed by the context being pinned). v3: Not just a reference to the context, but we need to keep it pinned as we manipulate the rings; i.e. we need a pin for both the manipulation of the engine state during its retirements, and a separate pin for the manipulation of the ring state. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-3-chris@chris-wilson.co.uk
| * | drm/i915: Wrap engine->context_pin() and engine->context_unpin()Chris Wilson2018-04-301-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make life easier in upcoming patches by moving the context_pin and context_unpin vfuncs into inline helpers. v2: Fixup mock_engine to mark the context as pinned on use. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-2-chris@chris-wilson.co.uk
| * | drm/i915/selftests: Wait for idle between idle resets as wellChris Wilson2018-04-261-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though we weren't injecting guilty requests to be reset, we could still fall over the issue of resetting the same request too fast -- where the GPU refuses to start again. (Although it is interesting to note that reloading the driver is sufficient, suggesting that we could recover if we delayed the setup after reset?) Continue to paper over the problem by adding a small delay by waiting for the engine to idle between tests, and ensure that the engines are idle before starting the idle tests. v2: Replace single instance of 50 with a magic macro. References: 028666793a02 ("drm/i915/selftests: Avoid repeatedly harming the same innocent context") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411120346.27618-1-chris@chris-wilson.co.uk
| * | drm/i915/selftests: Fix uninitialized variableGustavo A. R. Silva2018-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a potential execution path in which variable err is returned without being properly initialized previously. Fix this by initializing variable err to 0. Addresses-Coverity-ID: 1468362 ("Uninitialized scalar variable") Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131545.GA4053@embeddedor.com
| * | drm/i915: Pack params to engine->schedule() into a structChris Wilson2018-04-182-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today we only want to pass along the priority to engine->schedule(), but in the future we want to have much more control over the various aspects of the GPU during a context's execution, for example controlling the frequency allowed. As we need an ever growing number of parameters for scheduling, move those into a struct for convenience. v2: Move the anonymous struct into its own function for legibility and ye olde gcc. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-3-chris@chris-wilson.co.uk
| * | drm/i915/selftests: Handle a potential failure of intel_ring_beginOscar Mateo2018-04-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Silence smatch over: drivers/gpu/drm/i915/selftests/intel_workarounds.c:58 read_nonprivs() error: 'cs' dereferencing possible ERR_PTR() by handling a potential (but unlikely) failure of intel_ring_begin. Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets") Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1523915821-30624-1-git-send-email-oscar.mateo@intel.com
| * | drm/i915: Check whitelist registers across resetsChris Wilson2018-04-142-0/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a selftest to ensure that we restore the whitelisted registers after rewrite the registers everytime they might be scrubbed, e.g. module load, reset and resume. For the other volatile workaround registers, we export their presence via debugfs and check in igt/gem_workarounds. However, we don't export the whitelist and rather than do so, let's test them directly in the kernel. The test we use is to read the registers back from the CS (this helps us be sure that the registers will be valid for MI_LRI etc). In order to generate the expected list, we split intel_whitelist_workarounds_emit into two phases, the first to build the list and the second to apply. Inside the test, we only build the list and then check that list against the hw. v2: Filter out pre-gen8 as they do not have RING_NONPRIV. v3: Drop unused engine parameter, no plans to use it now or future. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180414122754.569-1-chris@chris-wilson.co.uk
* | | dma-buf: remove kmap_atomic interfaceChristian König2018-06-201-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Neither used nor correctly implemented anywhere. Just completely remove the interface. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/226645/
* | | Merge tag 'drm-intel-next-2018-04-13' of ↵Dave Airlie2018-05-045-104/+777
|\ \ \ | |/ / | | / | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next First drm/i915 feature batch heading for v4.18: - drm-next backmerge to fix build (Rodrigo) - GPU documentation improvements (Kevin) - GuC and HuC refactoring, host/GuC communication, logging, fixes, and more (mostly Michal and Michał, also Jackie, Michel and Piotr) - PSR and PSR2 enabling and fixes (DK, José, Rodrigo and Chris) - Selftest updates (Chris, Daniele) - DPLL management refactoring (Lucas) - DP MST fixes (Lyude and DK) - Watermark refactoring and changes to support NV12 (Mahesh) - NV12 prep work (Chandra) - Icelake Combo PHY enablers (Manasi) - Perf OA refactoring and ICL enabling (Lionel) - ICL enabling (Oscar, Paulo, Nabendu, Mika, Kelvin, Michel) - Workarounds refactoring (Oscar) - HDCP fixes and improvements (Ramalingam, Radhakrishna) - Power management fixes (Imre) - Various display fixes (Maarten, Ville, Vidya, Jani, Gaurav) - debugfs for FIFO underrun clearing (Maarten) - Execlist improvements (Chris) - Reset improvements (Chris) - Plenty of things here and there I overlooked and/or didn't understand... (Everyone) Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/87lgd2cze8.fsf@intel.com
| * drm/i915: Pass the set of guilty engines to i915_reset()Chris Wilson2018-04-061-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we rely on inspecting the hangcheck state from within the i915_reset() routines to determine which engines were guilty of the hang. This is problematic for cases where we want to run i915_handle_error() and call i915_reset() independently of hangcheck. Instead of relying on the indirect parameter passing, turn it into an explicit parameter providing the set of stalled engines which then are treated as guilty until proven innocent. While we are removing the implicit stalled parameter, also make the reason into an explicit parameter to i915_reset(). We still need a back-channel for i915_handle_error() to hand over the task to the locked waiter, but let's keep that its own channel rather than incriminate another. This leaves stalled/seqno as being private to hangcheck, with no more nefarious snooping by reset, be it whole-device or per-engine. \o/ The only real issue now is that this makes it crystal clear that we don't actually do any testing of hangcheck per se in drv_selftest/live_hangcheck, merely of resets! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-2-chris@chris-wilson.co.uk
| * drm/i915: Treat i915_reset_engine() as guilty until proven innocentChris Wilson2018-04-061-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we are resetting just one engine, we know it has stalled. So we can pass the stalled parameter directly to i915_gem_reset_engine(), which alleviates the necessity to poke at the generic engine->hangcheck.stalled magic variable, leaving that under control of hangcheck as its name implies. Other than simplifying by removing the indirect parameter along this path, this allows us to introduce new reset mechanisms that run independently of hangcheck. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Rename wait_for_hang() to wait_until_running()Chris Wilson2018-04-061-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tvrtko mentioned that wait_for_hang() was confusing as it does not actually wait for the aforementioned hang, just until the request is running and we are *ready* to inject a hang. A quick s/wait_for_hang/wait_until_running/ removes that confusion without having to rethink the naming scheme, immediately at least. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406100950.19033-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Avoid repeatedly harming the same innocent contextChris Wilson2018-04-061-4/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't handle resetting the kernel context very well, or presumably any context executing its breadcrumb commands in the ring as opposed to the batchbuffer and flush. If we trigger a device reset twice in quick succession while the kernel context is executing, we may end up skipping the breadcrumb. This is really only a problem for the selftest as normally there is a large interlude between resets (hangcheck), or we focus on resetting just one engine and so avoid repeatedly resetting innocents. Something to try would be a preempt-to-idle to quiesce the engine before reset, so that innocent contexts would be spared the reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180330131801.18327-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Add basic sanitychecks for execlistsChris Wilson2018-04-042-0/+508
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before adding a new feature to execlists submission, we should endeavour to cover the baseline behaviour with selftests. So start the ball rolling. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180404093329.5383-1-chris@chris-wilson.co.uk
| * drm/i915/selftests: Stress resets-vs-request-priorityChris Wilson2018-03-221-63/+126
| | | | | | | | | | | | | | | | | | | | | | | | Watch what happens if we try to reset with a queue of requests with varying priorities -- that may need reordering or preemption across the reset. v2: Tweak priorities to avoid starving the hanging thread. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180322073533.5313-2-chris@chris-wilson.co.uk Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
| * drm/i915/selftests: Include the trace as a debug aideChris Wilson2018-03-221-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | If we fail to reset the GPU in a timely fashion, dump the GEM trace so that we can see what operations were in flight when the GPU got stuck. v2: There's more than one timeout that deserves tracing! v3: Silence checkpatch by not even using a product at all! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322074908.10838-1-chris@chris-wilson.co.uk
| * drm/i915: Add control flags to i915_handle_error()Chris Wilson2018-03-201-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to i915_reset/i915_reset_engine so that we include the reason for the reset in the dev_notice(), superseding the earlier option to not print that notice. v3: Stash the reason inside the i915->gpu_error to handover to the direct reset from the blocking waiter. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-2-chris@chris-wilson.co.uk
| * drm/i915: add a selftest for the mmio_bases tableDaniele Ceraolo Spurio2018-03-152-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | Check that the entries are in reverse gen order and that all entries with gen > 0 have an mmio base set. v2: loop forward, simplify logic, use i915_subtests (Chris) Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180314182653.26981-2-daniele.ceraolospurio@intel.com
* | Merge branch 'sched-wait-for-linus' of ↵Linus Torvalds2018-04-021-10/+4
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull wait_var_event updates from Ingo Molnar: "This introduces the new wait_var_event() API, which is a more flexible waiting primitive than wait_on_atomic_t(). All wait_on_atomic_t() users are migrated over to the new API and wait_on_atomic_t() is removed. The migration fixes one bug and should result in no functional changes for the other usecases" * 'sched-wait-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/wait: Improve __var_waitqueue() code generation sched/wait: Remove the wait_on_atomic_t() API sched/wait, arch/mips: Fix and convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait, fs/ocfs2: Convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait, fs/nfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait, fs/fscache: Convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait, fs/btrfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait, fs/afs: Convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait, drivers/media: Convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new wait_var_event() API sched/wait: Introduce wait_var_event()
| * sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new ↵Peter Zijlstra2018-03-201-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wait_var_event() API The old wait_on_atomic_t() is going to get removed, use the more flexible wait_var_event() API instead. Unlike wake_up_atomic_t(), wake_up_var() will issue the wakeup even if the variable is not 0. No change in functionality. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
* | drm/i915/icl: Gen11 forcewake supportDaniele Ceraolo Spurio2018-03-071-10/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main difference with previous GENs is that starting from Gen11 each VCS and VECS engine has its own power well, which only exist if the related engine exists in the HW. The fallback forcewake request workaround is only needed on gen9 according to the HSDES WA entry (1604254524), so we can go back to using the simpler fw_domains_get/put functions. BSpec: 18331 v2: fix fwtable, use array to test shadow tables, create new accessors to avoid check on every access (Tvrtko) v3 (from Paulo): Rebase. v4: - Range 09400-097FF should be FORCEWAKE_ALL (Daniele) - Use the BIT macro for forcewake domains (Daniele) - Add a comment about the range ordering (Oscar) - Updated commit message (Oscar) v5: Rebased v6: Use I915_MAX_VCS/VECS (Michal) v7: translate FORCEWAKE_ALL to available domains v8: rebase, add clarification on fallback ack in commit message. v9: fix rebase issue, change check in fw_domains_init from IS_GEN11 to GEN >= 11 v10: Generate is_genX_shadowed with a macro (Daniele) Include gen11_fw_ranges in the selftest (Michel) v11: Simplify FORCEWAKE_ALL, new line between NEEDS_FORCEWAKEs (Tvrtko) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-6-mika.kuoppala@linux.intel.com Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
* | drm/i915: Update missing parts after the rename to i915_requestMichel Thierry2018-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | Mostly doc/print messages that were not updated after commit e61e0f51ba79 ("drm/i915: Rename drm_i915_gem_request to i915_request"). Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180222172405.11386-1-michel.thierry@intel.com
* | drm/i915: Rename drm_i915_gem_request to i915_requestChris Wilson2018-02-2113-157/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to de-emphasize the link between the request (dependency, execution and fence tracking) from GEM and so rename the struct from drm_i915_gem_request to i915_request. That is we may implement the GEM user interface on top of requests, but they are an abstraction for tracking execution rather than an implementation detail of GEM. (Since they are not tied to HW, we keep the i915 prefix as opposed to intel.) In short, the spatch: @@ @@ - struct drm_i915_gem_request + struct i915_request A corollary to contracting the type name, we also harmonise on using 'rq' shorthand for local variables where space if of the essence and repetition makes 'request' unwieldy. For globals and struct members, 'request' is still much preferred for its clarity. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221095636.6649-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
* | drm: move read_domains and write_domain into i915Christian König2018-02-164-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all other drivers. Move the fields into drm_i915_gem_object instead and patch the i915 code with the following sed commands: sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c Change is only compile tested. v2: move fields around as suggested by Chris. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180216124338.9087-1-christian.koenig@amd.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERRGustavo A. R. Silva2018-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Fix inconsistent IS_ERR and PTR_ERR in shrink_boom. The proper pointer to use is _explode_ instead of _purge_. This issue was detected with the help of Coccinelle. Fixes: fe215c8bc426 ("drm/i915/selftests: add missing gtt shrinker test") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214211234.GA22341@embeddedgus Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915/selftests: Report setup errors for igt_partial_tilingChris Wilson2018-02-131-6/+12
| | | | | | | | | | | | | | | | | | | | | | igt_partial_tiling managed to fail with an -EBUSY. This usually means a pin leak, but that should be impossible given the test setup. Add a couple of error messages to help identify the path that failed. References: https://bugs.freedesktop.org/show_bug.cgi?id=105073 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180213120940.21579-1-chris@chris-wilson.co.uk
* | drm/i915: Only allocate preempt context when requiredChris Wilson2018-02-081-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we remove some hardcoded assumptions about the preempt context having a fixed id, reserved from use by normal user contexts, we may only allocate the i915_gem_context when required. Then the subsequent decisions on using preemption reduce to having the preempt context available. v2: Include an assert that we don't allocate the preempt context twice. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180207210544.26351-3-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com>
* | drm/i915/guc: Allow preempt-client to be NULLChris Wilson2018-02-081-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the next patch, we may only conditionally allocate the preempt-client if there is a global preempt context and so we need to be prepared in case the preempt-client itself is NULL. v2: Grep for more preempt_client. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180207210544.26351-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com>
* | drm/i915/selftests: Use a sacrificial context for hang testingChris Wilson2018-02-053-17/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky; export a function (for selftests) from i915_gem_context.c to get it right. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-2-chris@chris-wilson.co.uk
* | drm/i915/selftests: Flush old resets between enginesChris Wilson2018-02-051-3/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In practice, since we wait for each hanging batch to start before injecting the reset, this too-fast-reset condition can only be triggered when moving onto the next engine in the test, so we need only wait for the existing reset to complete before switching engines. v2: Wrap up the wait inside a safety net to bail out in case of angry hw. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-1-chris@chris-wilson.co.uk
* | drm/i915/selftests: add missing gtt shrinker testMatthew Auld2018-02-011-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | Try to catch a bug we've seen in the wild where the shrinker purges the pd/pdp from under us while allocating our paging structures. References: https://bugs.freedesktop.org/show_bug.cgi?id=104773 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180131191453.12676-1-matthew.auld@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-2-chris@chris-wilson.co.uk
* | drm/i915/selftests: Wait for the dma-fence timeoutChris Wilson2018-01-171-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When testing that the timeout fired, we need to be sure we have waited just long enough for the timeout to have occurred and for the softirq (on another cpu) to have completed. Sleeping for an arbitrary amount is prone to error, so wait for the timeout instead and complain if it was too late. v2: Use wait_event_timeout to provide an upper bound v3: Fix inverted check for wait_event_timeout timing out v4: Restore the check that the fences aren't signalled too early, by inspecting them before the expected timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=104670 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180117135713.2324-1-chris@chris-wilson.co.uk
* | drm/i915/selftests: Test i915_sw_fence/dma_fence interopChris Wilson2018-01-161-0/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | Check that we can successfully wait upon a dma_fence using the i915_sw_fence, including the optional timeout mechanism. v2: Account for the rounding up of the timeout to the next second. Unfortunately, the minimum delay is then 1 second. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180115204348.8480-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
* | drm/i915/selftests: Allow random array allocation to failChris Wilson2018-01-021-1/+2
| | | | | | | | | | | | | | | | | | | | In the selftests, we don't want to force an oom and would rather ENOMEM be reported. In this case, we would rather the allocation for the random array to fail. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171223110407.21402-2-chris@chris-wilson.co.uk
* | drm/i915/selftests: Tweak igt_ggtt_page to speed it upChris Wilson2018-01-021-16/+14
|/ | | | | | | | | | | Reduce the number of GGTT PTE operations to speed the test up, but we reduce the likelihood of spotting a coherency error in those operations. However, Broxton is sporadically timing on this test, presumably because its GGTT operations are all uncached. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171223110407.21402-1-chris@chris-wilson.co.uk
OpenPOWER on IntegriCloud