- 28 Jul, 2016 1 commit
-
-
Ville Syrjälä authored
SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck in an infinite batch buffer loop. The GPU apparently hogs something critical and CPUs start to lose interrupts and whatnot. We can keep the system limping along by unmasking some interrupts in GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for that task, so let's never mask it. v2: s/gen6_rps_pm_mask/gen6_sanitize_rps_pm_mask/ (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93122Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 27 Jul, 2016 6 commits
-
-
Chris Wilson authored
We still have lots of comments that refer to the old ring when we mean struct intel_engine_cs and its hardware correspondence. This patch fixes an instance inside hangcheck to talk about engines. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469606850-28659-5-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
A few places we use ring when referring to the struct intel_engine_cs. An anachronism we are pruning out. Signed-off-by:
-
Chris Wilson authored
Inside the error capture itself, we refer to not only the hardware engine, its ringbuffer but also the capture state. Finding clear names for each whilst avoiding mixing ring/intel_engine_cs is tricky. As a compromise we keep using ering for the error capture. v2: Use 'ee' locals for struct drm_i915_error_engine Signed-off-by:
-
Chris Wilson authored
This patch transitions the execbuf engine selection away from using the ring nomenclature - though we still refer to the user's incoming selector as their user_ring_id. Signed-off-by:
-
Chris Wilson authored
When we refer to intel_engine_cs, we want to use engine so as not to confuse ourselves about ringbuffers. v2: Rename all the functions as well, as well as a few more stray comments. v3: Split the really long error message strings Signed-off-by:
-
Ville Syrjälä authored
Bspec tells us to keep bashing the PCU for up to 3ms when trying to inform it about an upcoming change in the cdclk frequency. Currently we only keep at it for 15*10usec (+ whatever delays gets added by the sandybridge_pcode_read() itself). Let's change the limit to 3ms. I decided to keep 10 usec delay per iteration for now, even though the spec doesn't really tell us to do that. Cc: stable@vger.kernel.org Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume") Cc: David Weinehall <david.weinehall@intel.com> Signed-off-by:
David Weinehall <david.weinehall@intel.com> Reviewed-by:
-
- 26 Jul, 2016 4 commits
-
-
Chris Wilson authored
The obj->batch_pool_link is only inspected when traversing the batch pool list and when on the batch pool list the object is referenced. Thus when freeing the batch pool list, we only need to unreference the object and do not have to worry about the obj->batch_pool_link. Signed-off-by:
-
Chris Wilson authored
Upon release of the file (i.e. the user calls close(fd)), we decouple all objects from the client list so that we don't chase the dangling file_priv. As we always inspect file_priv first, we only need to nullify that pointer and can safely ignore the list_head. Signed-off-by:
-
Chris Wilson authored
list_first_entry_or_null() can generate better code than using if (!list_empty()) {ptr = list_first_entry()) ..., so put it to use. Signed-off-by: -
Chris Wilson authored
Since intel_engine_enable_signaling() is now only called via fence_enable_sw_signaling(), we can rely on it to provide serialisation and run-once for us and so make ourselves slightly simpler. Signed-off-by:
-
- 25 Jul, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 Jul, 2016 2 commits
-
-
Chris Wilson authored
In order to close a race with a long running hangcheck comparing a stale interrupt counter with a just started waiter, we need to first bump the counter as we start the fresh wait. References: https://bugs.freedesktop.org/show_bug.cgi?id=96974Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469351421-13493-2-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
During the idle-worker we disable the hangcheck and so kick any waiters that should have been completed (since the GPU is now idle). Unlike the hangcheck, we do not take any care to avoid the race between the irq handler and ourselves, and so it is possible for us to declare a missed interrupt even as the bottom-half is being scheduled to run. Let's ignore this race to stop a potential false-positive error. References: https://bugs.freedesktop.org/show_bug.cgi?id=96974Signed-off-by:
-
- 21 Jul, 2016 8 commits
-
-
Chris Wilson authored
This reverts commit b12e0ee2 ("drm/i915: Enable RC6 immediately"), as it was never meant to be sent anywhere other than the bug report for experimentation. Signed-off-by:
-
Daniel Vetter authored
I forgot to remove these when reworking the firmware loading sequence last year. The new sequence is that we load firmware, and if it's not there we entirely (and permanently) fail dmc setup. Reported-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468505704-17391-1-git-send-email-daniel.vetter@ffwll.ch
-
Dave Gordon authored
The exit path in intel_overlay_put_image_ioctl() first unlocks the struct_mutex, then drops its reference to 'new_bo' by calling i915_gem_object_put(). As it isn't holding the mutex at this point, this should be i915_gem_object_put_unlocked(). This was previously correct but got splatted in the recent s/drm_gem_object_unreference/i915_gem_object_put/ where the _unlocked suffix was lost in this one case. v2: don't bother fixing whitespace glitch [Chris Wilson] Chris can do it next time he touches gem_evict.c ;) Fixes: f8c417cd drm/i915: Rename drm_gem_object_unreference in preparation ... Signed-off-by: -
Chris Wilson authored
Now that PCU communication is reasonably fast, we do not need to defer RC6 initialisation to a workqueue. References: https://bugs.freedesktop.org/show_bug.cgi?id=97017Signed-off-by:
-
Tim Gore authored
WaC6DisallowByGfxPause is currently applied unconditionally but is not required in all revisions. v2: extend application of workaround to agree with w/a database, which differs from the HSD. References: HSD#2133391 Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469008825-19442-1-git-send-email-tim.gore@intel.com
-
Dave Gordon authored
'ring' is an old deprecated term for a GPU engine, so we're trying to phase out all such terminology. eb_select_ring() not only has 'ring' (meaning engine) in its name, but it has an ugly calling convention whereby it returns an errno and stores a pointer-to-engine indirectly through an output parameter. As there is only one error it ever returns (-EINVAL), we can make it return the pointer directly, and have the caller pass back the error code -EINVAL if the pointer result is NULL. Thus we can replace - ret = eb_select_ring(dev_priv, file, args, &engine); - if (ret) - return ret; with + engine = eb_select_engine(dev_priv, file, args); + if (!engine) + return -EINVAL; for increased clarity and maybe save a few cycles too. Signed-off-by:
-
Dave Gordon authored
'ring' is an old deprecated term for a GPU engine. Chris Wilson wants to use the name for what is currently known as an intel_ringbuffer, but it will be dreadfully confusing if some rings are ringbuffers but other rings are still engines. So this patch changes the names of a bunch of parameters called 'ring' to either 'engine' or 'engine_id' according to what they actually are. Signed-off-by:
-
Dave Gordon authored
'ring' is an old deprecated term for a GPU engine. Here we make the terminology more consistent by renaming the 'ring' parameter of lots of macros that calculate addresses within the MMIO space of an engine. Signed-off-by:
-
- 20 Jul, 2016 18 commits
-
-
Mika Kuoppala authored
Add WaDisableGatherAtSetShaderCommonSlice for all gen9 as stated by bspec. The bspec told to put this workaround to the per ctx bb. Initial implementation and subsequent review were done based on bspec. Arun raised a suspicion that this would belong to indirect bb instead and he conducted more throughout investigation on the matter and indeed the documentation was wrong. v2: Move to indirect_ctx wa bb, as it is correct place (Arun) References: HSD#2135817 Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> (v1) Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
Add this workaround to prevent hang when in place compression is used. References: HSD#2135774 Cc: stable@vger.kernel.org Signed-off-by:
-
Chris Wilson authored
Rather than recomputing whether semaphores are enabled, we can do that computation once during early initialisation as the i915.semaphores module parameter is now read-only. s/i915_semaphores_is_enabled/i915.semaphores/ v2: Add the state to the debug dmesg as well Signed-off-by:
-
Chris Wilson authored
Just a different colour to better match virtual addresses elsewhere. s/ring->virtual_start/ring->vaddr/ Signed-off-by:
-
Chris Wilson authored
Ringbuffers are now being written to either through LLC or WC paths, so treating them as simply iomem is no longer adequate. However, for the older !llc hardware, the hardware is documentated as treating the TAIL register update as serialising, so we can relax the barriers when filling the rings (but even if it were not, it is still an uncached register write and so serialising anyway.). For simplicity, let's ignore the iomem annotation. v2: Remove iomem from ringbuffer->virtual_address v3: And for good measure add iomem elsewhere to keep sparse happy Signed-off-by:
-
Chris Wilson authored
Whilst this ultimately wraps kref_put_mutex(), our goal here is the lockless variant, so keep the _unlocked() suffix until we need it no more. s/drm_gem_object_unreference_unlocked/i915_gem_object_put_unlocked/ Signed-off-by:
-
Chris Wilson authored
Ultimately wraps kref_put(), so adopt its nomenclature for consistency with other subsystems. s/drm_gem_object_unreference/i915_gem_object_put/ Signed-off-by:
-
Chris Wilson authored
Ultimately wraps kref_get(), so adopt its nomenclature for consistency with other subsystems. s/drm_gem_object_reference/i915_gem_object_get/ Signed-off-by:
-
Chris Wilson authored
For symmetry with a forthcoming i915_gem_object_get() and i915_gem_object_put(). Signed-off-by:
-
Chris Wilson authored
As these are wrappers around kref_get/kref_put() it is preferable to follow the naming convention and use the same verb get/put in our wrapper names for manipulating a reference to the context. s/i915_gem_context_reference/i915_gem_context_get/ s/i915_gem_context_unreference/i915_gem_context_put/ Signed-off-by:
-
Chris Wilson authored
Now that we derive requests from struct fence, swap over to its nomenclature for references. It's shorter and more idiomatic across the kernel. s/i915_gem_request_reference/i915_gem_request_get/ s/i915_gem_request_unreference/i915_gem_request_put/ Signed-off-by:
-
Chris Wilson authored
When transitioning to the GTT or CPU domain we wait on all rendering from i915 to complete (with the optimisation of allowing concurrent read access by both the GPU and client). We don't yet ensure all rendering from third parties (tracked by implicit fences on the dma-buf) is complete. Since implicitly tracked rendering by third parties will ignore our cache-domain tracking, we have to always wait upon rendering from third-parties when transitioning to direct access to the backing store. We still rely on clients notifying us of cache domain changes (i.e. they need to move to the GTT read or write domain after doing a CPU access before letting the third party render again). v2: This introduces a potential WARN_ON into i915_gem_object_free() as the current i915_vma_unbind() calls i915_gem_object_wait_rendering(). To hit this path we first need to render with the GPU, have a dma-buf attached with an unsignaled fence and then interrupt the wait. It does get fixed later in the series (when i915_vma_unbind() only waits on the active VMA and not all, including third-party, rendering. To offset that risk, use the __i915_vma_unbind_no_wait hack. Testcase: igt/prime_vgem/basic-fence-read Testcase: igt/prime_vgem/basic-fence-mmap Signed-off-by:
-
Chris Wilson authored
A foreign dma-buf does not share our cache domain tracking, and we rely on the producer ensuring cache coherency. Marking them as being in the CPU domain is incorrect. v2: Add commentary about the GTT domain. This is not the best place for it, but pending an actual overhaul of our domain tracking and explaining each one, this comment should help the next reader... Signed-off-by:
-
Chris Wilson authored
Since commit a6f766f3 ("drm/i915: Limit ring synchronisation (sw sempahores) RPS boosts") and commit bcafc4e3 ("drm/i915: Limit mmio flip RPS boosts") we have limited the waitboosting for semaphores and flips. Ideally we do not want to boost in either of these instances as no userspace consumer is waiting upon the results (though a userspace producer may be stalled trying to submit an execbuf - but in this case the producer is being throttled due to the engine being saturated with work). With the introduction of NO_WAITBOOST in the previous patch, we can finally disable these needless boosts. Signed-off-by:
-
Chris Wilson authored
We want to restrict waitboosting to known process contexts, where we can track which clients are receiving waitboosts and prevent excessive power wasting. For fence_wait() we do not have any client tracking and so that leaves it open to abuse. v2: Hide the IS_ERR_OR_NULL testing for special clients Signed-off-by:
-
Chris Wilson authored
dma-buf provides a generic fence class for interoperation between drivers. Internally we use the request structure as a fence, and so with only a little bit of interfacing we can rebase those requests on top of dma-buf fences. This will allow us, in the future, to pass those fences back to userspace or between drivers. v2: The fence_context needs to be globally unique, not just unique to this device. Signed-off-by:
-
Chris Wilson authored
Following a GPU reset upon hang, we retire all the requests and then mark them all as complete. If we mark them as complete first, we both keep the normal retirement order (completed first then retired) and provide a small optimisation for concurrent lookups. Signed-off-by:
-
Chris Wilson authored
In order to keep the memory allocated for requests reasonably tight, try to reuse the oldest request (so long as it is completed and has no external references) for the next allocation. v2: Throw in a comment to hopefully make sure no one mistakes the optimistic retirement of the oldest request for simply stealing it. Signed-off-by:
-
