- 28 Feb, 2020 6 commits
-
-
Chris Wilson authored
Check that we can recover if the LRC is totally corrupted. Based on a very simple theory that anything that can be adjusted via the context (i.e. on behalf of the user), should be under the purview of the per-engine-reset. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-13-chris@chris-wilson.co.uk
-
Chris Wilson authored
Record the LRC registers before/after a preemption event to ensure that the first context sees nothing from the second client; at least in the normal per-context register state. References: https://gitlab.freedesktop.org/drm/intel/issues/1233Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-12-chris@chris-wilson.co.uk
-
Chris Wilson authored
Pull the final atomic_dec of vm->open (marking the vm as closed) underneath the same vm->mutex as used to close it. This is required to correctly serialise with attempting to reuse the vma as the vm is closed by a second thread. References: 00de702c ("drm/i915: Check that the vma hasn't been closed before we insert it") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-10-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we drop the engine-pm on retiring, that may happen while there are still CS events in the buffer. As such we cannot assert the engine is still active on reset, until we know that the current request is still in flight. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1338Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227204727.2009346-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Still chasing the mystery of the stray idle flush, let's ensure that the heartbeat does not run at the same time as our test and confuse us. References: https://gitlab.freedesktop.org/drm/intel/issues/541Signed-off-by:
-
Chris Wilson authored
Attaching to the i915_active barrier is a two stage process, and a flush is only effective when the barrier is activation. Thus it is possible for us to see a barrier, and attempt to flush, only for our flush to have no effect. As such, before attempting to activate signaling on the fence we need to double check it is a fence! Fixes: d13a3177 ("drm/i915: Flush idle barriers when waiting") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1333Signed-off-by:
-
- 27 Feb, 2020 8 commits
-
-
Daniele Ceraolo Spurio authored
On TGL, bits 2-4 in the GGTT PTE are not ignored anymore and are instead used for some extra VT-d capabilities. We don't (yet?) have support for those capabilities, but, given that we shared the pte_encode function betweed GGTT and PPGTT, we still set those bits to the PPGTT PPAT values. The DMA engine gets very confused when those bits are set while the iommu is enabled, leading to errors. E.g. when loading the GuC we get: [ 9.796218] DMAR: DRHD: handling fault status reg 2 [ 9.796235] DMAR: [DMA Write] Request device [00:02.0] PASID ffffffff fault addr 0 [fault reason 02] Present bit in context entry is clear [ 9.899215] [drm:intel_guc_fw_upload [i915]] *ERROR* GuC firmware signature verification failed To fix this, just have dedicated gen8_pte_encode function per type of gtt. Also, explicitly set vm->pte_encode for gen8_ppgtt, even if we don't use it, to make sure we don't accidentally assign it to the GGTT one, like we do for gen6_ppgtt, in case we need it in the future. Reported-by:
"Sodhi, Vunny" <vunny.sodhi@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Wa_1608008084 is an additional WA that applies to writes on FF_MODE2 register. We can't read it back either from CPU or GPU. Since the other bits should be 0, recommendation to handle Wa_1604555607 is to actually just write the timer value. Do a write only and don't try to read it, neither before or after the WA is applied. Fixes: ff690b21 ("drm/i915/tgl: Implement Wa_1604555607") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200224191258.15668-1-lucas.demarchi@intel.com
-
Ville Syrjälä authored
Looks like the pipe rounding mode bit has moved from PIPE_CHICKEN to PIPE_MISC on tgl. Frob the new location. Bspec does still document the old bits as well, so I left the code for them as is until we get clarification from the hw folks on whether the old bits still do something useful. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226163054.9509-1-ville.syrjala@linux.intel.comReviewed-by:
-
Lucas De Marchi authored
This register was placed in the middle of the PP_STATUS definition instead of together with the PP_CONTROL where it should. Since it's not used and there are no current plans to use it, just remove the definition. v2: remove the define rather than moving it. Signed-off-by:
-
Jani Nikula authored
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace the sole remaining I915_WRITE() in i915_drv.c with intel_uncore_write(), although it might be better to keep the entire file void of direct register access. No functional changes. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225111509.21879-3-jani.nikula@intel.com
-
Jani Nikula authored
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding uncore register accessors intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read(), intel_uncore_read_fw(), and intel_uncore_write_fw(). Rename dev_priv to i915 while at it. No functional changes. Reviewed-by:
-
Jani Nikula authored
The DRAM related routines are pretty isolated from the rest of the i915_drv.c, split it out to a separate file. Put the eDRAM stuff in the same bag, and rename the visible functions to have intel_dram_ prefix. Do some benign whitespace fixes and dev_priv -> i915 conversions while at it. Reviewed-by:
-
Jani Nikula authored
The #include has been splattered all over the place, but there are precious few places, all .c files, that actually need it. v2: remove leftover double newlines Reviewed-by:
-
- 26 Feb, 2020 11 commits
-
-
Matt Atwood authored
On Tiger Lake we do not support source keying in the pixel formats P010, P012, P016. v2: Move WA to end of function. Create helper function for format check. Less verbose debugging messaging. v3: whitespace v4(MattR): - Actually return EINVAL to reject this combination. - Pass format parameter as u32. - Make test TGL-specific for now. - Switch to per-device logging. - Shorten/simplify comment. Bspec: 52890 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200224223651.3801646-1-matthew.d.roper@intel.comReviewed-by:
-
Matt Roper authored
On gen12, we no longer need to disable DC5/DC6 when when PG2 is in use (which translates to cases where we're using VDSC on pipe A). Bspec: 49193 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2020-02-26 - Enable VFIO edid for all platform (Zhenyu) - Code cleanup for attr group and unused vblank complete (Zhenyu, Julian) - Make gvt oblivious of kvmgt data structures (Julian) - Make WARN* drm specific (Pankaj) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226103840.GD10413@zhen-hp.sh.intel.com
-
Anshuman Gupta authored
skl_ddb_allocation_overlaps() num_entries hass been passed as INTEL_NUM_PIPES, it should be I915_MAX_PIPES. v2: - Rebased. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Anshuman Gupta authored
Add a WARN_ON for a disabled pipe in pipe_mask at intel_get_crtc_for_pipe() function. v2: - Use drm_WARN_ON instead of WARN_ON. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Anshuman Gupta authored
intel_plane_fb_max_stride should return the max stride of primary plane for first available pipe in intel device info pipe_mask. Similarly glk_force_audio_cdclk() should also use the first available CRTC instead of pipe 'A' crtc to force the cdclk changes. changes since RFC: - Introduced a helper to get first intel_crtc intel_get_first_crtc. [Ville] v1: - Used intel_get_first_crtc() instead of PIPE_A crtc in glk_force_audio_cdclk(). [Ville] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Anshuman Gupta authored
Skip the transcoder whose pipe is disabled while initializing transcoder error state in 3 non-contiguous display pipe system. v2: - Don't skip EDP_TRANSCODER error state. [Ville] - Use a helper has_transcoder(). [Ville] v3: - Removed DSI transcoder case from has_transcoder(), and few other cosmetic changes. [Ville] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Anshuman Gupta authored
we can't have (pipe == crtc->index) assumption in driver in order to support 3 non-contiguous display pipe system. FIXME: Remove the WARN_ON(drm_crtc_index(&crtc->base) != crtc->pipe) when we will fix all such assumption. changes since RFC: - Added again removed (pipe == crtc->index) WARN_ON. - Pass drm_crtc_index instead of intel pipe in order to call drm_handle_vblank(). v2: - Used drm_crtc_handle_vblank()/drm_crtc_wait_one_vblank() instead of drm_handle_vblank/drm_wait_one_vblank(). [Jani] - Introduced intel_handle_vblank() helper to avoid sprinkle of intel_crtc across irq_handlers. [Ville] v3: - Moved intel_handle_vblank() from header to i915_irq.c. [Ville] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Anshuman Gupta authored
It should not be assumed that a disabled display pipe will be always last the pipe. for_each_pipe() should iterate over I915_MAX_PIPES and check for the disabled pipe and skip that pipe so that it should not initialize the intel crtc for any disabled pipes. Due to changes in for_each_pipe() macro, it requires to handle the below compilation error. "suggest explicit braces to avoid ambiguous ‘else’ [-Werror=dangling-else]" v2: - Cosmetic changes, removed unwanted parentheses. [Ville] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Split inte_modeset_init() to parts before and after irq install, to facilitate further cleanup. The error paths are a mess, otherwise no functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
We no longer need or use it as we subclass struct drm_device in our struct drm_i915_private, and can always use to_i915() to get at i915. Stop assigning the pointer to catch anyone trying to add new users for ->dev_private. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Dale B Stimson <dale.b.stimson@intel.com> Signed-off-by:
-
- 25 Feb, 2020 10 commits
-
-
Chris Wilson authored
Check the user's flags on the struct file before deciding whether or not to stall before submitting a request. This allows us to reasonably cheaply honour O_NONBLOCK without checking at more critical phases during request submission. Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
No good reason why we must always use a static ringsize, so let userspace select one during construction. Link: https://github.com/intel/compute-runtime/pull/261Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225192206.1107336-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we do find ourselves with an idle barrier inside our active while waiting, attempt to flush it by emitting a pulse using the kernel context. Signed-off-by:
-
Rodrigo Vivi authored
Signed-off-by: -
Rodrigo Vivi authored
Some DSI and VBT pending patches from Hans will apply cleanly and with less ugly conflicts if they are rebuilt on top of other patches that recently landed on drm-next. Reference: https://patchwork.freedesktop.org/series/70952/ Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com
-
Chris Wilson authored
We cannot assert the fence is not yet changed as the next thread may change it prior to acquiring our lock. Signed-off-by:
-
Chris Wilson authored
Tidy up after a call to eb_parse() if a later bind fails. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1312Signed-off-by:
-
Tina Zhang authored
When vgpu ptr is unavailable, the drm_WARN* can hang the whole system due to the drm pointer is NULL. This patch fixes this issue by using WARN directly which won't care about the drm pointer. Fixes: 12d58619 ("drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available") Signed-off-by:
Tina Zhang <tina.zhang@intel.com> Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Signed-off-by: -
Rodrigo Vivi authored
Signed-off-by:
-
- 24 Feb, 2020 5 commits
-
-
Chris Wilson authored
Full-ppgtt on gen7 is proving to be highly unstable and not robust. Closes: https://gitlab.freedesktop.org/drm/intel/issues/694 Fixes: 3cd6e886 ("drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw") Signed-off-by:
-
José Roberto de Souza authored
Commit 60c6a14b ("drm/i915/display: Force the state compute phase once to enable PSR") was forcing the state compute too earlier causing errors because not everything was initialized, so here moving to the end of i915_driver_modeset_probe() when the display is all initialized. Also fixing the place where it disarm the force probe as during the atomic check phase errors could happen like the ones due locking and it would cause PSR to never be enabled if that happens. Leaving the disarm to the atomic commit phase, intel_psr_enable() or intel_psr_update() will be called even if the current state do not allow PSR to be enabled. v2: Check if intel_dp is null in intel_psr_force_mode_changed_set() v3: Check intel_dp before get dev_priv v4: - renamed intel_psr_force_mode_changed_set() to intel_psr_set_force_mode_changed() - removed the set parameter from intel_psr_set_force_mode_changed() - not calling intel_psr_set_force_mode_changed() from intel_psr_enable/update(), directly setting it after the same checks that intel_psr_set_force_mode_changed() does - moved intel_psr_set_force_mode_changed() arm call to i915_driver_modeset_probe() as it is a better for a PSR call, all the functions calls happening between the old and the new function call will cause issue Fixes: 60c6a14b ("drm/i915/display: Force the state compute phase once to enable PSR") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151Tested-by:
Ross Zwisler <zwisler@google.com> Reported-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Ville Syrjälä authored
One should use drm_connector_list_iter_end() rather than drm_connector_list_iter_begin() to terminate the connector iteration. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1278 Fixes: e24bcd34 ("drm/i915/dp: Add all tiled and port sync conns to modeset") Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Jani Nikula authored
$(CC) with $(CFLAGS_GCOV) assumes the output filename with .gcno suffix appended is writable. This is not the case when the output filename is /dev/null: HDRTEST drivers/gpu/drm/i915/display/intel_frontbuffer.h /dev/null:1:0: error: cannot open /dev/null.gcno HDRTEST drivers/gpu/drm/i915/display/intel_ddi.h /dev/null:1:0: error: cannot open /dev/null.gcno make[5]: *** [../drivers/gpu/drm/i915/Makefile:307: drivers/gpu/drm/i915/display/intel_ddi.hdrtest] Error 1 make[5]: *** Waiting for unfinished jobs.... make[5]: *** [../drivers/gpu/drm/i915/Makefile:307: drivers/gpu/drm/i915/display/intel_frontbuffer.hdrtest] Error 1 Filter out $(CFLAGS_GVOC) from the header test $(c_flags) as they don't make sense here anyway. References: http://lore.kernel.org/r/d8112767-4089-4c58-d7d3-2ce03139858a@infradead.orgReported-by:
Randy Dunlap <rdunlap@infradead.org> Fixes: c6d4a099 ("drm/i915: reimplement header test feature") Cc: Masahiro Yamada <masahiroy@kernel.org> Acked-by:
-
Chris Wilson authored
Restore the previous WARN_ON(cond) so that we don't complain about poor old Cherryview. Fixes: eb020ca3 ("drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available") Signed-off-by:
-
