- 06 Apr, 2020 5 commits
-
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406114821.10949-1-chris@chris-wilson.co.uk (cherry picked from commit 30c88a47) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
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 (cherry picked from commit 97a37c91) Signed-off-by:
-
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:
Matthew Auld <matthew.auld@intel.com> Reviewed-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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330210044.130510-1-jose.souza@intel.com (cherry picked from commit 70988115) Signed-off-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:
-
- 31 Mar, 2020 1 commit
-
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
Merge tag 'gvt-next-fixes-2020-03-31' of https://github.com/intel/gvt-linux into drm-intel-next-fixes gvt-next-fixes-2020-03-31 - Fix non-privilege access warning (Tina) - Fix display port type (Tina) - BDW cmd parser missed SWTESS_BASE_ADDRESS (Yan) - Bypass length check of LRI (Yan) - Fix one klocwork warning (Tina) Signed-off-by:
-
- 27 Mar, 2020 1 commit
-
-
Tina Zhang authored
Add llu suffix and cast operator to fix the klocwork warning about "Operands in a bitwise operation have different size" Signed-off-by:
Tina Zhang <tina.zhang@intel.com> Acked-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
- 26 Mar, 2020 7 commits
-
-
Uma Shankar authored
This patch fixes the private_flags of mode to be checked and compared against uapi.mode and not from hw.mode. This helps properly trigger modeset at boot if desired by driver. It helps resolve audio_codec initialization issues if display is connected at boot. Initial discussion on this issue has happened on below thread: https://patchwork.freedesktop.org/series/74828/ v2: No functional change. Fixed the Closes tag and added Maarten's RB. v3: Added Fixes tag. Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Souza, Jose <jose.souza@intel.com> Fixes: 58d124ea ("drm/i915: Complete crtc hw/uapi split, v6.") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1363Suggested-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
SweeAun Khor <swee.aun.khor@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200326125111.11081-1-uma.shankar@intel.com (cherry picked from commit d5e56705) Signed-off-by:
-
Chris Wilson authored
We move the virtual breadcrumb from one physical engine to the next, if the next virtual request is scheduled on a new physical engine. Since the virtual context can only be in one signal queue, we need it to track the current physical engine for the new breadcrumbs. However, to move the list we need both breadcrumb locks -- and since we cannot take both at the same time (unless we are careful and always ensure consistent ordering) stage the movement of the signaler via the current virtual request. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1510 Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200325130059.30600-1-chris@chris-wilson.co.uk (cherry picked from commit 6c81e21a) Signed-off-by:
-
Chris Wilson authored
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for Ivybridge to hit the same minimum power consumption as rc6 on other platforms, so make it so. v2: Update selftest to include all rc6 residency counters Note that Andi did mention that we should be converting the magic numbers into opaque magic macros, so if they ever get reused (unlikely given only Ivybridge used the extra modes) we'll need to pay back the technical debt. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518 Fixes: 730eaeb5 ("drm/i915/gt: Manual rc6 entry upon parking") Testcase: igt/i915_pm_rc6_residency/rc6-idle Signed-off-by:
-
Chris Wilson authored
Abuse^W Take advantage that we know we are inside the GT wakeref and that prevents any client execbuf from reopening the i915_vma in order to claim all the vma to close without having to drop the spinlock to free each one individually. By keeping the spinlock, we do not have to restart if we run concurrently with i915_gem_free_objects -- which causes them both to restart continually and make very very slow progress. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1361 Fixes: 77853186 ("drm/i915: Claim vma while under closed_lock in i915_vma_parked()") Signed-off-by:
-
Chris Wilson authored
If we park/unpark faster than we can respond to RPS events, we never will process a downclock event after expiring a waitboost, and thus we will forever restart the GPU at max clocks even if the workload switches and doesn't justify full power. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500 Fixes: 3e7abf81 ("drm/i915: Extract GT render power state management") Signed-off-by:
-
Chris Wilson authored
Use the restored ability to check if a context is closed to decide whether or not to immediately ban the context from further execution after a hang. Fixes: be90e344 ("drm/i915/gt: Cancel banned contexts after GT reset") Signed-off-by:
-
Chris Wilson authored
I need to keep the GEM context around a bit longer so adding an explicit flag for syncing execbuf with closed/abandonded contexts. v2: * Use already available context flags. (Chris) Signed-off-by:
-
- 20 Mar, 2020 5 commits
-
-
Umesh Nerlige Ramappa authored
On running several back to back perf capture sessions involving closing and opening the perf stream, invalid OA reports are seen in the beginning of the OA buffer in some sessions. Fix this by invalidating OA TLB when the perf stream is closed or disabled on gen12. Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 00a7f0d7 ("drm/i915/tgl: Add perf support on TGL") Signed-off-by:
-
Chris Wilson authored
Beware that the context may already be closed as we try to lookup an engine. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1389 Fixes: 130a95e9 ("drm/i915/gem: Consolidate ctx->engines[] release") Signed-off-by:
-
Chris Wilson authored
The residual w/a batch is causing system instablity on Ivybridge and Baytrail under some workloads, so disable until resolved. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1405 Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
https://github.com/ckhu-mediatek/linux.git-tagsDave Airlie authored
Mediatek DRM Next for Linux 5.7 This include MT8183 DPI support. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/1584580683.29614.5.camel@mtksdaap41
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.7-2020-03-19: amdgpu: - SR-IOV fixes - RAS fixes - Fallthrough cleanups - Kconfig fix for ACP - Fix load balancing with VCN - DC fixes - GPU reset fixes - Various cleanups scheduler: - Revert job distribution optimization - Add a helper to pick the least loaded scheduler Signed-off-by:
-
- 19 Mar, 2020 21 commits
-
-
Colin Ian King authored
There are spelling mistakes in pr_err messages and a comment. Fix these. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Nathan Chancellor authored
clang warns: drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:6: warning: variable 'shadow' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (offset == grbm_cntl || offset == grbm_idx) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:757:6: note: uninitialized use occurs here if (shadow) { ^~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:2: note: remove the 'if' if its condition is always true if (offset == grbm_cntl || offset == grbm_idx) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:738:13: note: initialize the variable 'shadow' to silence this warning bool shadow; ^ = 0 1 warning generated. shadow is only assigned in one condition and used as the condition for another if statement; combine the two if statements and remove shadow to make the code cleaner and resolve this warning. Fixes: 2e0cc4d4 ("drm/amdgpu: revise RLCG access path") Link: https://github.com/ClangBuiltLinux/linux/issues/936Suggested-by:Joe Perches <joe@perches.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
James Zhu authored
fix typo for vcn2.5/jpeg2.5 idle check Signed-off-by:
James Zhu <James.Zhu@amd.com> Reviewed-by:
Leo Liu <leo.liu@amd.com> Signed-off-by:
-
James Zhu authored
fix typo for vcn2/jpeg2 idle check Signed-off-by:
-
James Zhu authored
fix typo for vcn1 idle check Signed-off-by:
-
Zhigang Luo authored
The CAP fw is for enabling driver compatibility. Currently, it only enabled for vega10 VF. Signed-off-by:
Zhigang Luo <zhigang.luo@amd.com> Reviewed-by:
Shaoyun Liu <Shaoyun.Liu@amd.com> Signed-off-by:
-
John Clements authored
issue smu cmd to disable all features upon baco entry for arcturus to mitigate potential dirty I2C controller on boot Reviewed-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
Yintian Tao authored
Originally, only the PTE valid is taken in consider. The PRT case is missied when bo update which raise problem. We need add condition for PRT case. v2: add PRT condition for amdgpu_vm_bo_update_mapping, too v3: fix one typo error Signed-off-by:
Yintian Tao <yttao@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Dmytro Laktyushkin authored
Adds logic that will determine if pipes need merging during validation. Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
-
Wyatt Wood authored
[Why] The scratch space can be used to pass data between x86 and DMCUB. DMCUB will manage the actually mapping of CW7 internally, driver does not program the window. [How] Allocate extra space within the DMUB service's framebuffer for this scratch space and expose them from the service for use in DC. Signed-off-by:
Wyatt Wood <wyatt.wood@amd.com> Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
-
Yongqiang Sun authored
[Why] before update dpp DTO, we check dppclks in context to determine it is changed or not, but dppclks in context will be updated anyways after flip is done, so compare dppclks in context will always get an equal result. [How] Add pipe dpp clks in dccg and compare values between dccg and context. Signed-off-by:
Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by:
-
Nikola Cornij authored
[why] Causes regression with MST DSC displays not lighting up after DPMS [how] Revert commit 8cc426d7 ("drm/amd/display: Program DSC during timing programming") Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Yongqiang Sun authored
[Why] underflow happened when playing video on 1366x768 + 4K clone mode due to incorrect handle watermark change flag and lower down clocks to early. [How] Check watermark change flag when decide doing optimized, and check optimized required flag to do clock update. Signed-off-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Charlene Liu authored
[why] this register not exist in some asic, based on request remove this from dc. [how] add guard for sanization. Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Reviewed-by:
-
Martin Tsai authored
[Why] We should check MST BU support capability on output port before building vsc info packet. [How] Add a new definition for port and sink capability check. Signed-off-by:
Martin Tsai <martin.tsai@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
-
Sung Lee authored
[WHY] In headless boot cases, self refresh control registers are not programmed on boot. In certain hybrid graphics cases this may cause cstate entering to get blocked causing a hang. [HOW] Program self refresh control register on boot. Signed-off-by:
Sung Lee <sung.lee@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Wenjing Liu authored
[why] DP doesn't have message id as the first byte of an hdcp message, current hdcp psp unifies HDMI and DP message so that it is required when reading DP HDCP messages in hdcp_ddc, a message id needs to be added as the first byte of the HDCP message. The id is currently assigned as a magic number which is not a good coding practice. [how] Replace magic numbers with macro defined in hdcp headers. Signed-off-by:
Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by:
-
Wyatt Wood authored
[Why] We want to be able to enable/disable psr on dmcub and fallback to dmcu when necessary. [How] Use dc config option to do so. Signed-off-by:
-
Wyatt Wood authored
[Why] The default value for disable_dmcu is true, even for asics that require dmcu. [How] Set flag properly per asic. Signed-off-by:
-
Roman Li authored
[Why] The PSR enablement was dependent on swizzle as a workaround for non-pageflipping fb console. It's no longer required. [How] Remove PSR-enable dependency on swizzle mode. Signed-off-by:
Roman Li <roman.li@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] This is enabled by default on Renoir but there's userspace/API support to actually make use of this. Since we're not passing this down through surface updates, let's explicitly disable this for now. This fixes "dcn20_program_front_end_for_ctx" warnings associated with incorrect/unexpected programming sequences performed while this is enabled. [How] Disable it at the topmost level in DM in case anyone tries to flip this to enabled for any of the other ASICs like Navi10/14. Signed-off-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
-
