- 03 Apr, 2020 3 commits
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318170235.15176-1-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
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 <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200403073657.13427-1-chris@chris-wilson.co.uk
-
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:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200402184037.21630-1-chris@chris-wilson.co.uk
-
- 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:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200402124218.6375-1-chris@chris-wilson.co.uk
-
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:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200401223924.16667-1-chris@chris-wilson.co.uk
-
- 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 14 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:
Imre Deak <imre.deak@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554Signed-off-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
-
José Roberto de Souza authored
EHL has now only one table for all DP rates. BSpec: 21257 Signed-off-by:
-
José Roberto de Souza authored
DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type and later eDP ports that have the type changed to INTEL_OUTPUT_EDP. But for all other DDI ports it can drive HDMI or DP depending on what user connects to the ports. ehl_get_combo_buf_trans() and tgl_get_combo_buf_trans() was checking for INTEL_OUTPUT_DP that was never true, causing wrong vswing tables being used. So here replacing the INTEL_OUTPUT_DP checks by the valid output types that this functions receives as parameters. HDMI cases will be correctly handled as it do not use encoder->type, instead it calls the functions with INTEL_OUTPUT_HDMI as type parameter and HDMI don't have retraining. v2: changed INTEL_OUTPUT_DDI to INTEL_OUTPUT_EDP and INTEL_OUTPUT_HDMI Fixes: bd3cf6f7 ("drm/i915/dp/tgl+: Update combo phy vswing tables") Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
The DDI IO power well must not be enabled for a TypeC port in TBT mode, ensure this during driver loading/system resume. This gets rid of error messages like [drm] *ERROR* power well DDI E TC2 IO state mismatch (refcount 1/enabled 0) and avoids leaking the power ref when disabling the output. Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by:
-
Chris Wilson authored
process_csb: 0000:00:02.0 bcs0: cs-irq head=4, tail=5 process_csb: 0000:00:02.0 bcs0: csb[5]: status=0x00008002:0x60000020 trace_ports: 0000:00:02.0 bcs0: preempted { ff84:45154! prio 2 } trace_ports: 0000:00:02.0 bcs0: promote { ff84:45155* prio 2 } trace_ports: 0000:00:02.0 bcs0: submit { ff84:45156 prio 2 } process_csb: 0000:00:02.0 bcs0: cs-irq head=5, tail=6 process_csb: 0000:00:02.0 bcs0: csb[6]: status=0x00000018:0x60000020 trace_ports: 0000:00:02.0 bcs0: completed { ff84:45155* prio 2 } process_csb: 0000:00:02.0 bcs0: ring:{start:0x00178000, head:0928, tail:0928, ctl:00000000, mode:00000200} process_csb: 0000:00:02.0 bcs0: rq:{start:00178000, head:08b0, tail:08f0, seqno:ff84:45155, hwsp:45156}, process_csb: 0000:00:02.0 bcs0: ctx:{start:00178000, head:e000928, tail:0928}, process_csb: GEM_BUG_ON("context completed before request") In this sequence, we can see that although we have submitted the next request [ff84:45156] to HW (via ELSP[]) it has not yet reported the lite-restore. Instead, we see the completion event of the currently active request [ff84:45155] but at the time of processing that event, the breadcrumb has not yet been written. Though by the time we do print out the debug info, the seqno write of ff84:45156 has landed! Therefore there is a serialisation problem between the seqno writes and CS events, not just between the CS buffer and its head/tail pointers as previously observed on Icelake. This is not a huge problem, as we don't strictly rely on the breadcrumb to determine HW activity, but it may indicate that interrupt delivery is before the seqno write, aka bringing back the plague of missed interrupts from yesteryear. However, there is no indication of this wider problem, so let's just flush the seqno read before reporting an error. If it persists after the fresh read we can worry again. Signed-off-by: -
Lionel Landwerlin authored
Reading or writing those fields should only happen under stream->oa_buffer.ptr_lock. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: d1df41eb ("drm/i915/perf: rework aging tail workaround") Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330091411.37357-1-lionel.g.landwerlin@intel.com
-
- 30 Mar, 2020 9 commits
-
-
Chris Wilson authored
Upon a GPU reset, we copy the default context image over top of the guilty image. This will rollback the CTX_TIMESTAMP register to before our value of ce->runtime.last. Reset both back to 0 so that we do not encounter an underflow on the next schedule out after resume. This should not be a huge issue in practice, as hangs should be rare in correct code. Signed-off-by:
-
Chris Wilson authored
Use a separate array allocation for the execbuf vma, so that we can track their lifetime independently from the copy of the user arguments. With luck, this has a secondary benefit of splitting the malloc size to within reason and avoid vmalloc. The downside is that we might require two separate vmallocs -- but much less likely. In the process, this prevents a memory leak on the ww_mutex error unwind. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1390Signed-off-by:
-
Chris Wilson authored
We wish that the scheduler emit the context modification commands prior to enabling the oa_config, for which we must explicitly inform it of the ordering constraints. This is especially important as we now wait for the final oa_config setup to be completed and as this wait may be on a distinct context to the state modifications, we need that command packet to be always last in the queue. We borrow the i915_active for its ability to track multiple timelines and the last dma_fence on each; a flexible dma_resv. Keeping track of each dma_fence is important for us so that we can efficiently schedule the requests and reprioritise as required. Reported-by:
-
Chris Wilson authored
For conveniences of callers that just want to use an i915_active to track a wide array of concurrent timelines, wrap the base i915_active struct inside a kref. This i915_active will self-destruct after use. Signed-off-by:
-
Chris Wilson authored
Allow some users the discretion to not immediately return on a normal signal. Hopefully, they will opt to use TASK_KILLABLE instead. Signed-off-by:
-
Chris Wilson authored
Allow a bit of leniency for the CPU scheduler to be distracted while we flush the tasklet and so ensure that we always check the status of the request once more before timing out. v2: Wait until the HW acked the submit, and we do any secondary actions for the submit (e.g. timeslices) Signed-off-by:
-
Chris Wilson authored
Add some extra information into trace_ports to help with reviewing correctness. Signed-off-by:
-
Michal Wajdeczko authored
We report HuC status in debugfs using register read, but we missed that on Gen11+ HuC uses different register. Use correct one. While here, correct placement of the colon. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michal Wajdeczko authored
There might be many reasons why we failed to successfully load and authenticate HuC firmware, but today we only use single error in case of no HuC hardware. Add some more error codes for most common cases (disabled, not installed, corrupted or mismatched firmware). Signed-off-by:
-
- 27 Mar, 2020 2 commits
-
-
Aditya Swarup authored
Add definitions for registers grouped under Transcoder VRR function with necessary bitfields. Bspec: 49268 v2: Use REG_GENMASK, correct tabs/space indentation and move the definitions near the transcoder section.(Jani) v3: Remove unnecessary prefix from bit/mask definitions.(Manasi) v4: Use 'trans' in macro for better readability.(Manasi) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Chris Wilson authored
In what seems remarkably similar to the w/a required to not reload an idle context with HEAD==TAIL, it appears we must prevent the HW from switching to an idle context in ELSP[1], while simultaneously trying to preempt the HW to run another context and a continuation of the idle context (which is no longer idle). We can achieve this by preventing the context from completing while we reload a new ELSP (by applying ring_set_paused(1) across the whole of dequeue), except this eventually fails due to a lite-restore into a waiting semaphore does not generate an ACK. Instead, we try to avoid making the GPU do anything too challenging and not submit a new ELSP while the interrupts + CSB events appear to have fallen behind the completed contexts. We expect it to catch up shortly so we queue another tasklet execution and hope for the best. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1501Signed-off-by:
-
