- 17 Feb, 2020 1 commit
-
-
Jani Nikula authored
We've moved from bugzilla to gitlab. Cc: stable@vger.kernel.org Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212160434.6437-1-jani.nikula@intel.com
-
- 16 Feb, 2020 2 commits
-
-
Chris Wilson authored
Since we use a HW readback or estimation of the CS timestamp frequency, sometimes it may result in 0. Avoid the division-by-zero in computing its reciprocal, the timestamp period. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200216161746.500258-1-chris@chris-wilson.co.uk
-
Tvrtko Ursulin authored
GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP which will be useful for us in cases when we are not able to track context busyness ourselves (like with GuC). Keep a copy of this in struct intel_context from where it can be easily read even if the context is not pinned. v2: (Chris) * Do not store pphwsp address in intel_context. * Log CS wrap-around. * Simplify calculation by relying on integer wraparound. v3: * Include total/avg in traces and error state for debugging Signed-off-by:
-
- 15 Feb, 2020 4 commits
-
-
Ville Syrjälä authored
Currently when we load the driver we set distrust_bios_wm=true, which will cause active_pipe_changes to get flagged even when we're not toggling any pipes on/off. The reason being that we want to fully redistribute the dbuf among the active pipes and ignore whatever state the firmware left behind. Unfortunately when the code flags active_pipe_changes it doesn't set state->modeset to true, which means the hardware dbuf state won't actually get updated. Hence the hardware and software states go out of sync, which can result in planes trying to use a disabled dbuf slice. Suprisingly that only seems to corrupt the display rather than making the whole display engine keel over. Let's fix this for now by flagging state->modeset whenever distrust_bios_wm is set. Eventually we'll likely want to rip out all of this mess and introduce proper statye tracking for dbuf. But that requires more work. Toss in a FIXME to that effect. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: ff2cd863 ("drm/i915: Correctly map DBUF slices to pipes") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jani Nikula authored
We lack full state readout of DSC config, which may lead to DSC enable using a config that's all zeros, failing spectacularly. Force full modeset and thus compute config at probe to get a sane state, until we implement DSC state readout. Any fastset that did appear to work with DSC at probe, worked by coincidence. [1] is an example of a change that triggered the issue on TGL DSI DSC. [1] http://patchwork.freedesktop.org/patch/msgid/20200212150102.7600-1-ville.syrjala@linux.intel.com Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Fixes: fbacb15e ("drm/i915/dsc: add basic hardware state readout support") Acked-by:
-
Stanislav Lisovskiy authored
TGL BIOS seems to enable both DBuf slices ocasionally, depending how many displays are connected, while i915 according to BSpec was powering on S1 DBuf slice, until a modeset was done. This was causing a brief flash during the boot as we were disabling slice, previously used by BIOS with that. To prevent this, now we are ensuring tht we are enabling _at least_ one slice, but if there are more, let's not power them off. Fixes: ff2cd863 ("drm/i915: Correctly map DBUF slices to pipes") Reviewed-by:
-
José Roberto de Souza authored
Commit 1c9d2eb2 ("drm/i915: move intel_dp_set_m_n() to encoder for DDI platforms") moved the intel_dp_set_m_n() from hsw_crtc_enable() to intel_ddi_pre_enable_dp() but it missed add it to intel_mst_pre_enable_dp() causing MST slaves to not work. v2: Not setting intel_ddi_set_dp_msa() twice for MST master Fixes: 1c9d2eb2 ("drm/i915: move intel_dp_set_m_n() to encoder for DDI platforms") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
- 14 Feb, 2020 3 commits
-
-
Chris Wilson authored
Sometimes the error interrupt can fire even before we have seen the request go active -- in which case, we end up waiting until the timeout as the request is already completed. Double check for this case! Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214120659.3888735-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
The i915_debugfs.c has grown more than a little unwieldy. Split out the display related debugfs code to a file of its own under display/, initialized with a separate call. No functional changes. v2: - Also moved i915_frontbuffer_tracking, i915_gem_framebuffer, i915_power_domain_info, i915_dmc_info, i915_ipc_status (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
The DMC firmware is about display. Move the handling under display. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
- 13 Feb, 2020 6 commits
-
-
Jani Nikula authored
Prefer i915 over dev_priv where possible. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Move vga switcheroo and dsm handler register later in i915_driver_register(), and unregister in i915_driver_unregister(). The dsm handler unregister is a nop, and is only added for completeness. My unsubstantiated suspicion is that the vga switcheroo state change would not work as early as we register the hooks currently. In any case exposing the interfaces to the world only after we've got everything set up seems prudent. Also replace the error handling in vga switcheroo register with a simple error message. This is done at the same time due to lack of error propagation from i915_driver_register(). Cc: Lukas Wunner <lukas@wunner.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Jani Nikula authored
drm->dev_private is to be avoided. Use to_i915() on the struct drm_device pointer instead. Rename the affected local dev_priv variables to i915 while at it. Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Chris Wilson authored
Originally, I did not expect having to rewind a context upon timeslicing: the point was to replace the executing context with a non-executing one! However, given a second context that depends on requests from the first, we may have to split the requests along the first context to execute the second, causing us to partially replay the first context and so have to rewind its RING_TAIL. References: 5ba32c7b ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200213140150.3639027-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
With debugging turned off, we have to tell the compiler not to warn about the unused debug locals. Signed-off-by:
-
Mika Kuoppala authored
This is in mcr range of register, thus we can only verify it through mmio. Use engine wa list with mcr range verification skip. Fixes: 0db1a5f8 ("drm/i915: Implement Wa_1607090982") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 12 Feb, 2020 4 commits
-
-
Chris Wilson authored
Show the ring/request/context state if we see what we believe is an early CS completion. Signed-off-by:
-
Chris Wilson authored
Make sure we avoid ending up with a phys_sz of 0, or for phys_sz to be larger than the actual size. Closes: https://patchwork.freedesktop.org/series/73320/Signed-off-by:
-
Chris Wilson authored
Apply vast quantities of poison and not tell anyone to see if we fall for the trap of using a stale RING_HEAD. References: 42827350 ("drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex") Signed-off-by:
-
Chris Wilson authored
On retiring the request, we should not re-use these elements in the ring (at least not until we fill the ringbuffer and knowingly reuse the space). Leave behind some poison to (hopefully) trap ourselves if we make a mistake. Suggested-by:
-
- 11 Feb, 2020 16 commits
-
-
Chris Wilson authored
If we have a set of active engines marked as being non-persistent, we lose track of those if the user replaces those engines with I915_CONTEXT_PARAM_ENGINES. As part of our uABI contract is that non-persistent requests are terminated if they are no longer being tracked by the user's context (in order to prevent a lost request causing an untracked and so unstoppable GPU hang), we need to apply the same context cancellation upon changing engines. v2: Track stale engines[] so we only reap at context closure. v3: Tvrtko spotted races with closing contexts and set-engines, so add a veneer of kill-everything paranoia to clean up after losing a race. Fixes: a0e04715 ("drm/i915/gem: Make context persistence optional") Testcase: igt/gem_ctx_peristence/replace Signed-off-by:
-
Ville Syrjälä authored
s/before/after/ again after accidentally changing it the other way in commit 5604e9ce ("drm/i915: Simplify intel_set_cdclk_{pre,post}_plane_update() calling convention") Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Accidentally removed the 'ret=0' initialization, and thus we're potentially looking at some stack garbage here. The whole 'ret = do_stuff; if (!ret) do_other_stuff;' pattern confuses my brain so let's replace it with the standard immediate return thing. Reported-by:
-
Chris Wilson authored
Currently on execlists, we use a local hwsp for the kernel_context, rather than the engine's HWSP, as this is the default for execlists. However, seqno wrap requires allocating a new HWSP cacheline, and may require pinning a new HWSP page in the GGTT. This operation requiring pinning in the GGTT is not allowed within the kernel_context timeline, as doing so may require re-entering the kernel_context in order to evict from the GGTT. As we want to avoid requiring a new HWSP for the kernel_context, we can use the permanently pinned engine's HWSP instead. However to do so we must prevent the use of semaphores reading the kernel_context's HWSP, as the use of semaphores do not support rollover onto the same cacheline. Fortunately, the kernel_context is mostly isolated, so unlikely to give benefit to semaphores. Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
We can not require that the system process a tasklet in reasonable time (thanks be to ksoftirqd), but we can insist that having waited sufficiently for the error interrupt to have been raised and having kicked the tasklet, the reset has begun and the request will be marked as in error (if not already completed). Signed-off-by:
-
Wambui Karuga authored
Conversion of the printk based logging macros to the struct drm_device based logging macros in i915/display/intel_dpio_phy.c. This was achieved using the following coccinelle semantic patch that matches based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&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_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Note that this converts both DRM_DEBUG/DRM_DEBUG_DRIVER to drm_dbg(). Checkpatch warnings were fixed manually. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by: -
Wambui Karuga authored
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dsi_vbt.c. This also involves extracting the drm_i915_private device from the intel_dsi type for use in the logging macros. This converts DRM_DEBUG/DRM_DEBUG_DRIVER to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Conversion of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_combo_phy.c. This transformation was achieved using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&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_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } This converts DRM_DEBUG/DRM_DEBUG_DRIVER to drm_dbg(). New checkpatch warnings were addressed manually. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by: -
Wambui Karuga authored
Conversion of instances of printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dpll_mgr.c. This also involves extracting the struct drm_i915_private device pointer from various intel types to use in the drm_device based macros. Note that this converts DRM_DEBUG_DRIVER to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Replaces various instances of the printk based logging macros with the struct drm_device based logging macros in i915/display/intel_crt.c using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&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_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were addressed manually. Signed-off-by: -
Wambui Karuga authored
Initial conversion of the straightforward printk based logging macros to the struct drm_device based logging macros in i915/display/intel_color.c. Signed-off-by:
-
Wambui Karuga authored
Conversion of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_atomic.c This change was achieved using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&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_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were fixed manually. Signed-off-by: -
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dp_link_training.c. This also involves extracting the drm_i915_private device pointer from the intel_dp type to use in the various macros. Signed-off-by:
-
Chris Wilson authored
We manipulate ring->head while active in i915_request_retire underneath the timeline manipulation. We cannot rely on a stable ring->head outside of the timeline->mutex, in particular while setting up the context for resume and reset. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1126 Fixes: 08819549 ("drm/i915: Introduce intel_context.pin_mutex for pin management") Fixes: e5dadff4 ("drm/i915: Protect request retirement with timeline->mutex") References: f3c0efc9 ("drm/i915/execlists: Leave resetting ring to intel_ring") Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Reviewed-by:
-
Anshuman Gupta authored
As Gen12 onwards there are HDCP instances for each transcoder instead of port, remove the (port < PORT_E) hdcp support limitation for platform >= Gen12. v2: - Nuke the comment and cosmetic changes. [Jani] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Chris Wilson authored
dma-bufs are device coherent, with explicit CPU synchronisation provided via the begin/end cpu access ioctls. As the coherency of the dma-buf is explicitly defined to be under user control, flushing any caches on attach/detach of the dma-buf is additional work that doesn't aide the user in the slightest. Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Dongwon Kim <dongwon.kim@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171130180702.29357-1-chris@chris-wilson.co.uk
-
- 10 Feb, 2020 4 commits
-
-
Chris Wilson authored
Reduce the amount of work we do to verify client blt correctness as currently our 0.5s subtests takes about 15s on slower devices! v2: Grow the maximum block size until we run out of time Signed-off-by:
-
Matt Roper authored
A recent bspec update added an extra voltage level that we didn't have on ICL and new criteria for selecting the level. Bspec: 49208 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
Voltage level depends not only on the cdclk, but also on the DDI clock. Last time the bspec voltage level table for EHL was updated, we only updated the cdclk requirements, but forgot to account for the new port clock criteria. Bspec: 21809 Fixes: d1474838 ("drm/i915/ehl: Update voltage level checks") Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Add a basic description about how DC3CO works to help people not familiar with it. While at it, I also improved the delayed work handle and function names and removed a debug message that is ambiguous and not much useful, no changes in behavior here. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205214945.131012-1-jose.souza@intel.com
-
