- 06 Apr, 2020 5 commits
-
-
Chris Wilson authored
Later use will require asynchronous waits on the active timelines, but will not utilize an async wait on the exclusive channel. Make the await on the exclusive fence explicit in the selection flags. 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/20200406155840.1728-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we set the debug flag to force ourselves not to relocate via the gpu, do not relocate via the gpu. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406123616.7334-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
__i915_gem_object_flush_map() takes a byte range, so feed it the written bytes and do not mistake the u32 index as bytes! Fixes: a679f58d ("drm/i915: Flush pages on acquisition") Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406114821.10949-1-chris@chris-wilson.co.uk
-
Imre Deak authored
On TypeC ports if a sink deasserts/reasserts its HPD signal, generating a hotplug interrupt without the sink getting unplugged/replugged from the connector, there can be an up to 3 seconds delay until the AUX channel gets functional. To avoid detection failures this delay causes retry the detection for 5 seconds. I noticed this on ICL/TGL RVPs and a DELL XPS 13 7390 ICL laptop. References: https://gitlab.freedesktop.org/drm/intel/issues/1067Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330095425.29113-2-imre.deak@intel.com
-
Imre Deak authored
On TypeC connectors we need to retry the detection after hotplug events for a longer time, so add a retry counter to support this. The next patch will add detection retries on TypeC ports needing this. Signed-off-by:
-
- 03 Apr, 2020 14 commits
-
-
Chris Wilson authored
While extremely unlikely to be populated, we could capture a request on the virtual engine which we should free along with the virtual engine. Fixes: 43acd651 ("drm/i915: Keep a per-engine request pool") Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200403203303.10903-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we submit, we do not start timeslicing until we process the CS event that marks the start of the context running on HW. So in the selftest, be sure to wait until we have processed the pending events before asserting that timeslicing has begun. Signed-off-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200403190209.21818-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is currently pinned, without waiting to see if the inflight operations may unpin it. We see this problem with the shrinker trying to unbind the active vma from inside its bind worker: <6> [472.618968] Workqueue: events_unbound fence_work [i915] <4> [472.618970] Call Trace: <4> [472.618974] ? __schedule+0x2e5/0x810 <4> [472.618978] schedule+0x37/0xe0 <4> [472.618982] schedule_preempt_disabled+0xf/0x20 <4> [472.618984] __mutex_lock+0x281/0x9c0 <4> [472.618987] ? mark_held_locks+0x49/0x70 <4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60 <4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619122] i915_vma_unbind+0xae/0x110 [i915] <4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915] <4> [472.619208] i915_gem_shrink+0x328/0x660 [i915] <4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915] <4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80 <4> [472.619363] ? __alloc_pd+0xb/0x30 [i915] <4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30 <4> [472.619368] ? __module_address+0x23/0xe0 <4> [472.619371] ? is_module_address+0x26/0x40 <4> [472.619374] ? static_obj+0x34/0x50 <4> [472.619376] ? lockdep_init_map+0x4d/0x1e0 <4> [472.619407] setup_page_dma+0xd/0x90 [i915] <4> [472.619437] alloc_pd+0x29/0x50 [i915] <4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915] <4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915] <4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915] <4> [472.619577] __vma_bind+0x26/0x40 [i915] <4> [472.619611] fence_work+0x1c/0x90 [i915] <4> [472.619617] process_one_work+0x26a/0x620 Fixes: 2850748e ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by:
-
Ashutosh Dixit authored
It is wrong to block the user thread in the next poll when OA data is already available which could not fit in the user buffer provided in the previous read. In several cases the exact user buffer size is not known. Blocking user space in poll can lead to data loss when the buffer size used is smaller than the available data. This change fixes this issue and allows user space to read all OA data even when using a buffer size smaller than the available data using multiple non-blocking reads rather than staying blocked in poll till the next timer interrupt. v2: Fix ret value for blocking reads (Umesh) v3: Mistake during patch send (Ashutosh) v4: Remove -EAGAIN from comment (Umesh) v5: Improve condition for clearing pollin and return (Lionel) v6: Improve blocking read loop and other cleanups (Lionel) v7: Added Cc stable Testcase: igt/perf/polling-small-buf Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Chris Wilson authored
Make sure we revoke the user's mmaps of this vma to force them to take a pagefault *before* we remove the associated aperture detiling register. Fixes: 0d86ee35 ("drm/i915/gt: Make fence revocation unequivocal") Signed-off-by:
-
Ville Syrjälä authored
Move the final DP_TP_CTL frobbing of port sync to the master encoder's enable hook. Now neatly out of sight from the high level modeset code. And thus we've eliminated all the special casing of port sync in the high level modeset code. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313164831.5980-14-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
We're going to want access to the atomic state for iterating the slave crtcs when enabling the port sync master crtc. Pass the atomic state all the way down. The alternative would be yet another encoder hook which we'll have to call after all the normal modeset stuff is done. Not really a fan of yet another hook just for this. Note that during readout state sanitation we are now going to pass NULL as the atomic state since we don't have one. We need to change that and then we can also s/crtc_state/crtc/ and s/conn_state/conn/ for the encoder hooks as well. Signed-off-by:
-
Ville Syrjälä authored
Currently only port sync pipes do the sequence such that we first do the modeset part for every pipe and then do the plane/etc. updates. Let's follow that apporach for all pipes in skl+ so that we can properly integrate the port sync into the normal modeset flow. v2: Remove now stale TODO of port sync slave entries[] s/oldnew/new/ Signed-off-by: -
Ville Syrjälä authored
Don't assume there is just one port sync slave. We might have several. v2: Fix unitialized new_crtc_state usage (José) Fix clearing of modeset_pipes for slaves s/oldnew/new/ Signed-off-by: -
Ville Syrjälä authored
Remove the copy pasted port sync crtc enable functions and instead just split the normal function into the two parts we need. Signed-off-by:
-
Ville Syrjälä authored
Transcoder port sync was introduced to the hardware in BDW. We can trivially enable it for SKL+ since the same codepaths are already used for ICL+ port sync. The only difference is the actual location of the bits we need to poke. We leave BDW out (at least for now) since it uses different modeset paths that haven't been adapted for port sync, and IIRC using the feature would involve some extra workarounds we've not implemented. Pre-BDW hardware does not support port sync so we'd have to tweak the modeset sequence to start the pipes as close together as possible and hope for the best. So far no one has seriously tried to implement that. Closes: https://gitlab.freedesktop.org/drm/intel/issues/27Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
We have a bunch of code that would like to know which CPU transcoders are actually present in the hardware. Rather than use various ad-hoc methods let's just include a full bitmask in the device info, alongside pipe_mask. v2: Rebase Signed-off-by:
-
Chris Wilson authored
We use timer->expires == 0 to detect if a timer had been cancelled, but it's a valid expiration we could set. Just skip using 0 and set the expiry for the next jiffie. Signed-off-by:
-
Chris Wilson authored
Add a tiny per-engine request mempool so that we should always have a request available for powermanagement allocations from tricky contexts. This reserve is expected to be only used for kernel contexts when barriers must be emitted [almost] without fail. The main consumer for this reserved request is expected to be engine-pm, for which we know that there will always be at least the previous pm request that we can reuse under mempressure (so there should always be a spare request for engine_park()). This is an alternative to using a comparatively bulky mempool, which requires custom handling for both our reserved allocation requirement and to protect our TYPESAFE_BY_RCU slab cache. The advantage of mempool would be that it would allow us to keep a larger per-engine request pool. However, converting over to mempool is straightforward should the need arise. Signed-off-by:
-
- 02 Apr, 2020 6 commits
-
-
Swathi Dhanavanthri authored
This workaround now applies to all steppings, not just A0. Wa_1409085225 is a temporary A0-only W/A however it is identical to Wa_14010229206 and hence the combined workaround is made permanent. Bspec: 52890 Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Tested-by:
Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> [mattrope: added missing blank line] Signed-off-by:
-
Chris Wilson authored
In order to kill off a hostile context, we need to be able to reset the GPU. So check that is supported prior to beginning the test. Reported-by:
-
Chris Wilson authored
Now that we can peek at GEM->engines[] and obtain a reference to them using RCU, do so for instances where we can safely iterate the potentially old copy of the engines. For setting, we can do this when we know the engine properties are copied over before swapping, so we know the new engines already have the global property and we update the old before they are discarded. For reading, we only need to be safe; as we do so on behalf of the user, their races are their own problem. Signed-off-by:
-
Chris Wilson authored
If we receive the error interrupt before the CS interrupt, we may find ourselves without an active request to reset, skipping the GPU reset. All because the attempt to reset was too early. Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function parameter 'supported' description in 'intel_uc_fw_init_early' drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function parameter 'platform' description in 'intel_uc_fw_init_early' drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function parameter 'rev' description in 'intel_uc_fw_init_early' drivers/gpu/drm/i915/gt/uc/intel_guc_log.c:696: warning: Function parameter or member 'log' not described in 'intel_guc_log_info' drivers/gpu/drm/i915/gt/uc/intel_guc_log.c:696: warning: Excess function parameter 'guc' description in 'intel_guc_log_info' Signed-off-by:
-
Chris Wilson authored
We cached the number of vma bound to the object in order to speed up shrinker decisions. This has been superseded by being more proactive in removing objects we cannot shrink from the shrinker lists, and so we can drop the clumsy attempt at atomically counting the bind count and comparing it to the number of pinned mappings of the object. This will only get more clumsier with asynchronous binding and unbinding. Signed-off-by:
-
- 01 Apr, 2020 6 commits
-
-
Chris Wilson authored
If we must revoke the fence because the VMA is no longer present, or because the fence no longer applies, ensure that we do and convert it into an error if we try but cannot. Signed-off-by:
-
Chris Wilson authored
Make a copy of the object tiling parameters at the point of grabbing the fence. Signed-off-by:
-
Chris Wilson authored
Only GPU activity via the GGTT fence is asynchronous, we know that we control the CPU access directly, so we only need to wait for the GPU to stop using the fence before we relinquish it. Signed-off-by:
-
Chris Wilson authored
If the current node/entry location is occupied, and the object is not pinned, try assigning it some free space. We cannot wait here, so if in doubt, we unreserve and try to grab all at once. v2: Use the final pin_flags so that we won't have to move the object if we find the wrong free space. Signed-off-by:
-
Chen Zhou authored
There is a spelling mistake in comment, fix it. Signed-off-by:
Chen Zhou <chenzhou10@huawei.com> Reviewed-by:
-
Chris Wilson authored
Insert a space so that the same fields between active/pending execlists state are aligned. Signed-off-by:
-
- 31 Mar, 2020 9 commits
-
-
Chris Wilson authored
If the user passes in a readonly reloc[], by the time we notice we have already committed to modifying the execobjects, or have indeed done so already. Reporting the failure just compounds the issue as we have no second pass to fall back to anymore. "Be damned if you do, and damned if you don't." Testcase: igt/gem_exec_reloc/readonly Fixes: 7dc8f114 ("drm/i915/gem: Drop relocation slowpath") References: fddcd00a ("drm/i915: Force the slow path after a user-write error") Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200331162150.3635-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
When we allocate space in the GGTT we may have to allocate a larger region than will be populated by the object to accommodate fencing. Make sure that this space beyond the end of the buffer points safely into scratch space, in case the HW tries to access it anyway (e.g. fenced access to the last tile row). v2: Preemptively / conservatively guard gen6 ggtt as well. Reported-by:
-
Mika Kuoppala authored
For CI it is enough to point out a single failure in isolation. However it is beneficial to gather info in logs for transients further down the line. Do not stop into first comparison failure but continue probing forward. v2: for all engines and poisons (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
Since we print out EXECLISTS_STATUS in the dump, also print out the CCID of each context so we can cross check between the two. Signed-off-by:
-
Chris Wilson authored
Since we may be attempting to reset an active engine, we try to freeze it in place before resetting -- to be on the safe side. We can go one step further if we are using the CS flow semaphore to prevent the context switching into the next. Signed-off-by:
-
Chris Wilson authored
Since we don't wait for the error interrupt to reset, restart and then complete the guilty request, clean up the error messages. Signed-off-by:
-
Chris Wilson authored
Add a few telltales to see when timeslicing is being enabled. Signed-off-by:
-
Chris Wilson authored
Since we may kick more than engine, and may kick each one a couple of times, coalesce the tasklet execution to the end. This also ensures that we have the chance to run the tasklet immediately after priority bumping. Signed-off-by:
-
José Roberto de Souza authored
Specification was updated with vswing tables for different configurations. Also reordering icl_mg_phy_ddi_buf_trans struct to match table order. BSpec: 21735 Signed-off-by:
Clinton Taylor <clinton.a.taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330210044.130510-3-jose.souza@intel.com
-
