- 08 Apr, 2020 11 commits
-
-
Jani Nikula authored
Prefer struct drm_device based logging over struct device based logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200402114819.17232-10-jani.nikula@intel.com
-
Jani Nikula authored
Convert all the pr_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Chris Wilson authored
Since the semaphore interrupt may cause us to yield the timeslice immediately, we may cancel the timer before we notice the submission is complete. The assertion is no longer valid due to the race with the interrupt. 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/20200407222625.15542-1-chris@chris-wilson.co.uk
-
- 07 Apr, 2020 2 commits
-
-
Chris Wilson authored
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the user batch or in our own preamble, the engine raises a GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so respond to a semaphore wait by yielding the timeslice, if we have another context to yield to! The only real complication is that the interrupt is only generated for the start of the semaphore wait, and is asynchronous to our process_csb() -- that is, we may not have registered the timeslice before we see the interrupt. To ensure we don't miss a potential semaphore blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark the interrupt and apply it to the next timeslice regardless of whether it was active at the time. v2: We use semaphores in preempt-to-busy, within the timeslicing implementation itself! Ergo, when we do insert a preemption due to an expired timeslice, the new context may start with the missed semaphore flagged by the retired context and be yielded, ad infinitum. To avoid this, read the context id at the time of the semaphore interrupt and only yield if that context is still active. Fixes: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by:
-
Chris Wilson authored
Tidy the code by casting remain to unsigned long once for the duration of eb_relocate_vma() Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200407085930.19421-1-chris@chris-wilson.co.uk
-
- 06 Apr, 2020 7 commits
-
-
Chris Wilson authored
If we want to percolate information back from the HW, up through the GEM context, we need to wait until the intel_context is scheduled out for the last time. This is handled by the retirement of the intel_context's barrier, i.e. by listening to the pulse after the notional unpin. So wait until the intel_context is finally retired before releasing the engine, so that we can inspect the final context state and pass it on. Signed-off-by:
-
Chris Wilson authored
Allow the caller to also wait upon the barriers stored in i915_active. v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well for completeness, and avoid the lazy GEM_BUG_ON()! v3: Pull flush_lazy_signals() under the active-ref protection as it too walks the rbtree and so we must be careful that we do not free it as we iterate. Signed-off-by:
-
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 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:
-
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:
-
