- 25 Sep, 2017 5 commits
-
-
Mika Kuoppala authored
When first execlist entry is processed, we move the port (contents). Introduce function for this as execlist and guc use this common operation. v2: rebase. s/GEM_DEBUG_BUG/GEM_BUG (Chris) v3: rebase Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170922124307.10914-4-mika.kuoppala@intel.com
-
Mika Kuoppala authored
On reset and wedged path, we want to release the requests that are tied to ports and then mark the ports to be unset. Introduce a function for this. v2: rebase v3: drop local, keep GEM_BUG_ON (Michał, Chris) v4: rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Mika Kuoppala authored
Move execlist init into a common engine setup. As it is common to both guc and hw execlists. v2: rebase with csb changes v3: rebase Signed-off-by:
-
Mika Kuoppala authored
Engine's execlist related items have been increasing to a point where a separate struct is warranted. Carve execlist specific items to a dedicated struct to add clarity. v2: add kerneldoc and fix whitespace (Joonas, Chris) v3: csb_mmio changes, rebase v4: s/\b(el|execlist)\b/execlists/ (Joonas) Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> (v3) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by:
-
Jani Nikula authored
The hardware state readout oopses after several warnings when trying to use HDMI on port A, if such a combination is configured in VBT. Filter the combo out already at the VBT parsing phase. v2: also ignore DVI (Ville) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889 Cc: stable@vger.kernel.org Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
Daniel Drake <dan@reactivated.net> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170921141920.18172-1-jani.nikula@intel.com
-
- 22 Sep, 2017 6 commits
-
-
Chris Wilson authored
No users now outside of i915_wait_request(), so we can make it private to i915_gem_request.c, and assume the caller knows the seqno. In the process, also remove i915_gem_request_started() as that was only ever used by i915_spin_request(). Signed-off-by:
-
Oscar Mateo authored
The total size of the context has decreased with the removal of the URB_ATOMIC section. BSpec indicates 16750 DWORDs (17 pages), plus one page for PPHWSP, and I'm throwing an extra page for precaution. Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Our global struct with params is named exactly the same way as new preferred name for the drm_i915_private function parameter. To avoid such name reuse lets use different name for the global. v5: pure rename v6: fix Credits-to: Coccinelle @@ identifier n; @@ ( - i915.n + i915_modparams.n ) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by:
-
Chris Wilson authored
After we see our target seqno has been completed by the hw, we need to confirm that it still matches the request (as it may have been preempted before the spin completes). If the request no longer matches the target seqno, we need to restart the wait to reacquire that seqno. Signed-off-by:
-
Chris Wilson authored
If preemption occurs at precisely the right moment, we may decide that the wait is complete even though the wait's request is no longer executing (having been preempted). We handle this situation by double checking that request following deciding whether the wait is complete. Reported-by:
-
Chris Wilson authored
As we now check if the seqno is complete in order to signal the fence, we can also decide not to wake up the first_waiter until it is ready (since it is waiting on the same seqno). The only caveat is that if we need the engine->irq_seqno_barrier to enforce some coherency between an interrupt and the seqno read, we have to always wake the waiter in order to perform that heavyweight barrier. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
- 21 Sep, 2017 2 commits
-
-
Chris Wilson authored
Since we reuse the same field for the user passing in their control flags, and for the kernel to track a couple of bits of state, document and check that those do not overlap. Suggested-by:
-
Anuj Phogat authored
See Mesa commit 9c588ff Cc: Matt Turner <mattst88@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by:
-
- 20 Sep, 2017 5 commits
-
-
Colin Ian King authored
hw_check is being assigned and updated but is no longer being read, hence it is redundant and can be removed. Detected by clang scan-build: "warning: Value stored to 'hw_check' during its initialization is never read" Fixes: f6d1973d ("drm/i915: Move modeset state verifier calls") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170914162154.11304-1-colin.king@canonical.com
-
Ville Syrjälä authored
Most of our DP encoder hooks are split into per-platform variants. .disable() an exception, and thus it's a bit messy. Let's split it up as well. We'll leave the common parts in a helper called by each platform specific hook. Now each platform has mostly its own hooks. Some hooks are still shared between vlv and chv, and between g4x and ilk. None of the remaining shared hooks have any platform checks in them however so duplicating them doesn't seem particularly useful. There is a subtle change on VLV/CHV where we now disable PSR before audio, whereas before we disabled PSR after audio. That should be totally fine, and PSR is disabled by default anyway. Jani also pointed out to me that PSR + audio doesn't seem like a particularly realistic combination. v2: Drop the PSR HAS_DDI check here (Rodrigo) Pimp up the commit message a bit based on a chat with Jani Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: -
Ville Syrjälä authored
It is safe to call intel_psr_disable() on a platform without PSR. We don't have such a check when calling intel_psr_enable() either. v2: Don't drop the HAS_DDI check quite yet (Rodrigo) Reviewed-by:
-
Mika Kuoppala authored
On kbl evidence indicates that even if the hardware happily tells us to proceed with reset, it really isn't ready. Resetting a freely running batchbuffer after we have ack for readiness, still can cause a system hang. We also have similar experiences on older gens. So now attempt to stop engines before proceeding for reset, on all gens where we have a gpu reset. This has shown to improve reset reliability and reduce the risk of losing the machine. v2: Add fixme for wa (Joonas) Testcase: igt/prime_busy/hang-* # kbl Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
drm_edid_to_eld() initializes the connector ELD to zero, overwriting the ELD connector type initialized in intel_audio_codec_enable(). If userspace does getconnector and thus get_modes after modeset, a subsequent audio component i915_audio_component_get_eld() call will receive an ELD without the connector type properly set. It's fine for HDMI, but screws up audio for DP. Always set the ELD connector type at intel_connector_update_modes() based on the connector type. We can drop the connector type update from intel_audio_codec_enable(). Credits to Joseph Nuzman <jnuzman@gmail.com> for figuring this out. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joseph Nuzman <jnuzman@gmail.com> Reported-by:
Joseph Nuzman <jnuzman@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101583Reviewed-by:
-
- 19 Sep, 2017 7 commits
-
-
Rodrigo Vivi authored
We now have Coffee Lake on our CI systems. Coffee Lake is at this point in same stage as Kaby Lake. And it seems that we don't have any risk of bad blank screens or anything like that. So let's remove the protection. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170907230632.25650-1-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
"CNL PCH chance of hang when software accesses south display registers after hotplug is enabled. Workaround: Program 0xC2000 bits 11:8 = 0xF before enabling south display hotplug detection." "Workaround only needs to be applied to pre-production steppings used in graphics capable SKUs, but it is easier to apply to everything, and does not hurt." v2: Moving from clock gating to right before enabling SHOTPLUG_CTL as it should be. v3: Align with SOUTH_CHICKEN1 (DK) and consequently use proper spaces on bits definition since other bits around already use new style. And now that checkpatch is not noise anymore I also fixed the reg read mask to avoid going over 80 chars. Suggested-by:Ben Widawsky <ben@bwidawsk.net> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Ville Syrjälä authored
All the values we put into the CNL buf_trans tables fit into 8 bits. So switch over to u8 from the u32 we use currently. Signed-off-by:
-
Ville Syrjälä authored
All the values we put into the BXT buf_trans tables fit into 8 bits. So switch over to u8 from the u32 we use currently. Signed-off-by:
-
Ville Syrjälä authored
Some comments in intel_ddi.c are indented with spaces instead of tabs. Fix that up. Signed-off-by:
-
Chris Wilson authored
A fence may be signaled from any context, including from inside a timer. One example is timer_i915_sw_fence_wake() which is used to provide a safety-net when waiting on an external fence. If the external fence is not signaled within a timely fashion, we signal our fence on its behalf, and so we then may process subsequent fences in the chain from within that timer context. Given that dma_i915_sw_fence_wake() may be from inside a timer, we cannot then use del_timer_sync() as that requires the timer lock for itself. To circumvent this, while trying to keep the signal propagation as low latency as possible, move the completion into a worker and use a bit of atomic switheroo to serialise the timer-callback and the dma-callback. Testcase: igt/gem_eio/in-flight-external Signed-off-by:
-
Chris Wilson authored
archdata.iommu only exists when CONFIG_IOMMU_API is enabled (and only applies to intel-iommu in our case) so conditionally compile it out when it doesn't exist. Fixes: b5891fb5 ("drm/i915/selftests: Disable iommu for the mock device") Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
- 18 Sep, 2017 15 commits
-
-
Rodrigo Vivi authored
Don't touch other bits. My bad. I haven't seen any case where those other bits appeard to be set before we touch it, but it is safe to avoid touching other bits we weren't told to touch. Fixes: 0a46ddd5 ("drm/i915/cnp: Wa 1181: Fix Backlight issue") Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Radhakrishna Sripada authored
Some platforms do not support PSR and DRRS simultaneously. Visual artifacts and flickering were reported on BDW HP Spectre x360 Convertible. Deferring to PSR when both PSR and DRRS are supported by the panel. V2: Minor code-style changes suggested by Rodrigo V3: Add a WARN_ON during PSR init suggested by Dhinakaran Correct debug message,title suggested by Jani Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101111 Cc: Nicholas Stommel <nicholas.stommel@gmail.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Lionel Landwerlin authored
Add the test configuration & timestamp frequency for Coffeelake GT2. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
We're doing this on all Gen9 based platforms, let's just check the gen rather than listing every single platforms. Signed-off-by:
-
Chris Wilson authored
On some machines, the iommu cannot allocate a domain for the mock device causing the dma_map_sg() to fail, and the selftest to fail with -ENOMEM. For the mock selftests, we are using a fake device and do not care about iommu; so convince intel_iommu to treat us as a dummy device with an identity mapping (and no iommu domain). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101080Signed-off-by:
Elizabeth De La Torre Mena <elizabethx.de.la.torre.mena@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com
-
Zhi Wang authored
The cache attribute of the required entry has to be the same with the existing value. After this requirement is met, the futher comparison should be performed. After this fix, the refined test case can pass. v2: - Refine the tittle and comments. (Rodrigo) Fixes: 4395890a ("drm/i915: Introduce private PAT management") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
Document the expected length of buffers config pointers (tuple of u32 values). Signed-off-by:
-
Michał Winiarski authored
We can just operate on the wq_tail directly (in the process descriptor). This allows us to remove the duplicated tail from the client. While I'm here let's also remove the constants kept in the client and document our locking requirements. This causes a small change in one of GuC debugfs files. We're no longer reporting constant values (which I don't think is a problem), but we're also no longer reporting the tail (does anyone care?). v2: Update tail after wqi contents. (Chris) v3: Really update tail after wqi contents. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
-
Michał Winiarski authored
All we're really doing is incrementing a simple counter in a doorbell_info struct. We can do without extra variables and a separate counter kept in guc_client. Since it's gone, we're also removing its debugfs. The only functional change here, is that we're no longer treating 0 as a special value. GuC doesn't seem to care, why should we? v2: Restore desc->tail update. v3: Drop the retry loop, assert that doorbell cookie doesn't change behind our back. v4: WARN rather than BUG, use xchg. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Suggested-by:
-
Michał Winiarski authored
To create an upper bound on number of GuC workitems, we need to change the way that requests are being submitted. Rather than submitting each request as an individual workitem, we can do coalescing in a similar way we're handlig execlist submission ports. We also need to stop pretending that we're doing "lite-restore" in GuC submission (we would create a workitem each time we hit this condition). This allows us to completely remove the reservation, replacing it with a compile time check. v2: Also coalesce when replaying on reset (Daniele) v3: Consistent wq_resv - per-request (Daniele) v4: Squash removing wq_resv v5: Reflect i915_guc_submit argument changes in doc v6: Rebase on top of execlists reset/restart fix (Chris,Michał) References: https://bugs.freedesktop.org/show_bug.cgi?id=101873 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
-
Michał Winiarski authored
Originally removed in: c1adab97 ("drm/i915/guc: Remove failed doorbell stat from debugfs") f1448a62 ("drm/i915/guc: Remove last submission result from debugfs") Were accidentally restored in: 925344cc ("BackMerge tag 'v4.12-rc5' into drm-next") We can also remove unused variable and replace it with a WARN. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Chris Wilson authored
Given the mechanism to unwind and replay requests (designed to support preemption), we have an alternative to the current method of resubmitting the ELSP upon reset. Resubmitting ELSP turns out to be more complicated than expected, due to having to handle lost context-switch interrupts and so guessing what ELSP we need to resubmit later. Instead, by unwinding the requests and clearing the ELSP tracking entirely, we can then just dequeue the first pair of ready requests after resetting, using the normal submission procedure. Currently, the unwound requests have maximum priority and so are guaranteed to be resubmitted upon resume. If we are lucky, we may be able to coalesce a new request on top! Suggested-by:
-
Chris Wilson authored
In the next patch we will want to reinsert a request not at the end of the priority queue, but at the front. Here we split insert_request() into two, the first function retrieves the priority list (for reuse for unsubmit later) and a wrapper function to insert at the end of that list and to schedule the tasklet if we were first. Signed-off-by:
-
Chris Wilson authored
Move insert_request() earlier to avoid a forward declaration in a later patch. Signed-off-by:
-
Chris Wilson authored
During a reset, we may skip over completed requests and lost context-switch interrupts. Following the reset, we may then may end up with no active requests in the ELSP (and so do not resubmit to restart the engine), but have a queue of requests ready for execution. This is unlikely, it requires the last request to complete after the hang is detected, but not impossible. The outcome of this is that the engine stalls, possibly leading to full ring and indefinite wait under struct_mutex, eventually leading to a full driver hang. Alternatively, we can solve this by unsubmitting the incomplete requests and just kickstarting the tasklet. Michał has patches for that, which I initially disliked due to the extra complexity, but the complexity of this "simple" restart is growing... Signed-off-by:
-
