- 21 Apr, 2021 1 commit
-
-
Zhenyu Wang authored
Looks this duplication was missed in code rebase. Remove extra check. Cc: Yan Zhao <yan.y.zhao@intel.com> Fixes: 02dd2b12 ("drm/i915/gvt: unify lri cmd handler and mmio handlers") Reviewed-by:
Colin Xu <colin.xu@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210414084813.3763353-2-zhenyuw@linux.intel.com
-
- 15 Apr, 2021 2 commits
-
-
Dan Carpenter authored
The intel_gvt_init_vgpu_type_groups() function is only called from intel_gvt_init_device(). If it fails then the intel_gvt_init_device() prints the error code and propagates it back again. That's a bug because false is zero/success. The fix is to modify it to return zero or negative error codes and make everything consistent. Fixes: c5d71cb3 ("drm/i915/gvt: Move vGPU type related code into gvt file") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jiapeng Chong authored
Fix the following clang warning: drivers/gpu/drm/i915/gvt/gtt.c:590:20: warning: unused function 'ppgtt_set_guest_root_entry' [-Wunused-function]. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
- 25 Feb, 2021 6 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2021-02-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next A fix for color format check from Ville, plus the re-enable of -Wuninitialized from Nathan, and the GVT fixes including fixes for ww locking, cmd parser and a general cleanup of dev_priv->gt. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YDe3pBPV5Kx3hpk6@intel.com
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-5.12-2021-02-24' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-fixes-5.12-2021-02-24: amdgpu: - Clang warning fix - S0ix platform shutdown/poweroff fix - Misc display fixes Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2021-02-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next tasty fixes for v5.12: - Cherry pick of drm-misc-fixes pull: "here's this week's PR for drm-misc-fixes. One of the patches is a memory leak; the rest is for hardware issues." - Fix dt bindings for dp connector. - Fix build error in atyfb. - Improve error handling for dma-buf heaps. - Make vblank timestamp more correct, by recording timestamp to be set when signaling. Signed-off-by:
-
Heiko Stuebner authored
The panel is able to work when dsi clock is non-continuous, thus the system power consumption can be reduced using such feature. Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags. Also the flag actually becomes necessary after commit c6d94e37 ("drm/bridge/synopsys: dsi: add support for non-continuous HS clock") and without it the panel only emits stripes instead of output. Fixes: c6d94e37 ("drm/bridge/synopsys: dsi: add support for non-continuous HS clock") Cc: stable@vger.kernel.org # 5.10+ Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Tested-by:
Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by:
Christopher Morgan <macromorgan@hotmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210206135020.1991820-1-heiko@sntech.deSigned-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Alyssa Rosenzweig authored
The AFBC decoder used in the Rockchip VOP assumes the use of the YUV-like colourspace transform (YTR). YTR is lossless for RGB(A) buffers, which covers the RGBA8 and RGB565 formats supported in vop_convert_afbc_format. Use of YTR is signaled with the AFBC_FORMAT_MOD_YTR modifier, which prior to this commit was missing. As such, a producer would have to generate buffers that do not use YTR, which the VOP would erroneously decode as YTR, leading to severe visual corruption. The upstream AFBC support was developed against a captured frame, which failed to exercise modifier support. Prior to bring-up of AFBC in Mesa (in the Panfrost driver), no open userspace respected modifier reporting. As such, this change is not expected to affect broken userspaces. Tested on RK3399 with Panfrost and Weston. Fixes: 7707f722 ("drm/rockchip: Add support for afbc") Cc: stable@vger.kernel.org Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Acked-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
-
xinhui pan authored
Free the memory on failure. Also no need to re-alloc memory on retry. Signed-off-by:
xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210219042547.44855-1-xinhui.pan@amd.comReviewed-by:
Christian König <christian.koenig@amd.com> CC: stable@vger.kernel.org # 5.11 Signed-off-by:
-
- 24 Feb, 2021 7 commits
-
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
* a6xx speedbin support * a508, a509, a512 support * various a5xx fixes * various dpu fixes * qseed3lite support for sm8250 * dsi fix for msm8994 * mdp5 fix for framerate bug with cmd mode panels * a6xx GMU OOB race fixes that were showing up in CI * various addition and removal of semicolons * gem submit fix for legacy userspace relocs path Signed-off-by:
-
Veera Sundaram Sankaran authored
The explicit out-fences in crtc are signaled as part of vblank event, indicating all framebuffers present on the Atomic Commit request are scanned out on the screen. Though the fence signal and the vblank event notification happens at the same time, triggered by the same hardware vsync event, the timestamp set in both are different. With drivers supporting precise vblank timestamp the difference between the two timestamps would be even higher. This might have an impact on use-mode frameworks using these fence timestamps for purposes other than simple buffer usage. For instance, the Android framework [1] uses the retire-fences as an alternative to vblank when frame-updates are in progress. Set the fence timestamp during send vblank event using a new drm_send_event_timestamp_locked variant to avoid discrepancies. [1] https://android.googlesource.com/platform/frameworks/native/+/master/ services/surfaceflinger/Scheduler/Scheduler.cpp#397 Changes in v2: - Use drm_send_event_timestamp_locked to update fence timestamp - add more information to commit text Changes in v3: - use same backend helper function for variants of drm_send_event to avoid code duplications Changes in v4: - remove WARN_ON from drm_send_event_timestamp_locked Signed-off-by:
Veera Sundaram Sankaran <veeras@codeaurora.org> Reviewed-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> [sumits: minor parenthesis alignment correction] Link: https://patchwork.freedesktop.org/patch/msgid/1610757107-11892-2-git-send-email-veeras@codeaurora.org (cherry picked from commit a78e7a51) Signed-off-by:
-
Veera Sundaram Sankaran authored
Some drivers have hardware capability to get the precise HW timestamp of certain events based on which the fences are triggered. The delta between the event HW timestamp & current HW reference timestamp can be used to calculate the timestamp in kernel's CLOCK_MONOTONIC time domain. This allows it to set accurate timestamp factoring out any software and IRQ latencies. Add a timestamp variant of fence signal function, dma_fence_signal_timestamp to allow drivers to update the precise timestamp for fences. Changes in v2: - Add a new fence signal variant instead of modifying fence struct Changes in v3: - Add timestamp domain information to commit-text and dma_fence_signal_timestamp documentation Signed-off-by:
-
John Stultz authored
Every heap needs to create a dmabuf and then export it to a fd via dma_buf_fd(), so to consolidate things a bit, have the heaps just return a struct dmabuf * and let the top level dma_heap_buffer_alloc() call handle creating the fd via dma_buf_fd(). Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Liam Mark <lmark@codeaurora.org> Cc: Laura Abbott <labbott@kernel.org> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Hridya Valsaraju <hridya@google.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Sandeep Patil <sspatil@google.com> Cc: Daniel Mentz <danielmentz@google.com> Cc: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: Ørjan Eide <orjan.eide@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Ezequiel Garcia <ezequiel@collabora.com> Cc: Simon Ser <contact@emersion.fr> Cc: James Jones <jajones@nvidia.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
John Stultz authored
If we abort from the allocation due to a fatal_signal_pending(), be sure we report an error so any return code paths don't trip over the fact that the allocation didn't succeed. Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Liam Mark <lmark@codeaurora.org> Cc: Laura Abbott <labbott@kernel.org> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Hridya Valsaraju <hridya@google.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Sandeep Patil <sspatil@google.com> Cc: Daniel Mentz <danielmentz@google.com> Cc: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: Ørjan Eide <orjan.eide@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Ezequiel Garcia <ezequiel@collabora.com> Cc: Simon Ser <contact@emersion.fr> Cc: James Jones <jajones@nvidia.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Suggested-by:
Suren Baghdasaryan <surenb@google.com> Signed-off-by:
-
Qingqing Zhuo authored
[Why] mutex_lock() was introduced in dm_disable_vblank(), which could be called in an IRQ context. Waiting in IRQ would cause issues like kernel lockup, etc. [How] Handle code that requires mutex lock on a different thread. v2: squash in compilation fix without CONFIG_DRM_AMD_DC_DCN (Alex) v3: squash in warning fix (Wei) Signed-off-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by:
Bindu Ramamurthy <bindu.r@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Prike Liang authored
In the shutdown and poweroff opt on the s0i3 system we still need un-gate the gfx clock gating and power gating before destory amdgpu device. Fixes: 628c36d7 ("drm/amdgpu: update amdgpu device suspend/resume sequence for s0i3 support") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1499Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Reviewed-by:
-
- 23 Feb, 2021 3 commits
-
-
Ville Syrjälä authored
We tend to use output_format!=RGB as a shorthand for YCbCr, but this fails if we have a disabled crtc where output_format==INVALID. We're now getting some fail from intel_color_check() when we have: hw.enable==false hw.ctm!=NULL output_format==INVALID Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the dumpster, and thus everything defaults to RGB when the crtc is disabled. This does beg the deeper question of how much of the state should we in fact be validating when hw/uapi.enable==false. And should we even be doing the uapi->hw copy when uapi.enable==false? So far I've not been able to come up with satisfactory answers for myself, so I'm putting it off for the moment. Cc: Lee Shawn C <shawn.c.lee@intel.com> Fixes: 0aa5c383 ("drm/i915: support two CSC module on gen11 and later") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 7e07c68f) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Nathan Chancellor authored
-Wunintialized was disabled in commit c5627461 ("drm/i915: Disable -Wuninitialized") because there were two warnings that were false positives. The first was due to DECLARE_WAIT_QUEUE_HEAD_ONSTACK, which was fixed in LLVM 9.0.0. The second was in busywait_stop, which was fixed in LLVM 10.0.0 (issue 415). The kernel's minimum version for LLVM is 10.0.1 so this warning can be safely enabled, where it has already caught a couple bugs. Link: https://github.com/ClangBuiltLinux/linux/issues/220 Link: https://github.com/ClangBuiltLinux/linux/issues/415 Link: https://github.com/ClangBuiltLinux/linux/issues/499 Link: https://github.com/llvm/llvm-project/commit/2e040398f8d691cc378c1abb098824ff49f3f28f Link: https://github.com/llvm/llvm-project/commit/c667cdc850c2aa821ffeedbc08c24bc985c59edd Fixes: c5627461 ("drm/i915: Disable -Wuninitialized") References: 2ea4a7ba ("drm/i915/gt: Avoid uninitialized use of rpcurupei in frequency_show") References: 2034c212 ("drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state") Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
Merge tag 'gvt-next-fixes-2021-02-22' of https://github.com/intel/gvt-linux into drm-intel-next-fixes gvt-next-fixes-2021-02-22 - Fix to use i915 default state for cmd parser on all engines (Chris) - Purge dev_priv->gt (Chris) - Fix gvt object ww locking (Zhi) Signed-off-by:
-
- 22 Feb, 2021 8 commits
-
-
Eric Bernstein authored
[Why] In some cases, this function is called when DIG BE is not connected to DIG FE, in which case a value of zero isn't invalid and assert should not be hit. [How] Remove assert and handle ENGINE_ID_UNKNOWN result in calling function. Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Acked-by:
-
Rodrigo Siqueira authored
When run igt@kms_vrr in a device that uses DCN2.1 architecture, we noticed multiple failures. Furthermore, when we tested a VRR demo, we noticed a system hang where the mouse pointer still works, but the entire system freezes; in this case, we don't see any dmesg warning or failure messages kernel. This happens due to a lack of vupdate_no_lock interrupt, making the userspace wait eternally to get the event back. For fixing this issue, we need to add the vupdate_no_lock interrupt in the interrupt list. Signed-off-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by:
-
Anson Jacob authored
This reverts commit 8866a67a. Reason for revert: This breaks hotplug of HDMI on some systems, resulting in a blank screen. Caused general hangs on boot/hotplugs. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1487 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1492 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211649Signed-off-by:
Anson Jacob <Anson.Jacob@amd.com> Reviewed-by:
Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Acked-by:
-
Nathan Chancellor authored
Clang warns: drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning: variable 'structure_size' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~~~~~ drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:770:23: note: uninitialized use occurs here memset(header, 0xFF, structure_size); ^~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:753:25: note: initialize the variable 'structure_size' to silence this warning uint16_t structure_size; ^ = 0 1 warning generated. Return in the default case, as the size of the header will not be known. Fixes: de4b7cd8 ("drm/amd/pm/swsmu: unify the init soft gpu metrics function") Link: https://github.com/ClangBuiltLinux/linux/issues/1304Reviewed-by:Kevin Wang <kevin1.wang@amd.com> Signed-off-by:
-
Randy Dunlap authored
Fix build errors when these functions are not defined. ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt': ../drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration of function 'aty_ld_lcd'; did you mean 'aty_ld_8'? [-Werror=implicit-function-declaration] 2002 | pm = aty_ld_lcd(POWER_MANAGEMENT, par); ../drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit declaration of function 'aty_st_lcd'; did you mean 'aty_st_8'? [-Werror=implicit-function-declaration] 2004 | aty_st_lcd(POWER_MANAGEMENT, pm, par); Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210222032853.21483-1-rdunlap@infradead.org
-
Zhi Wang authored
To support ww locking and per-object implemented in i915, GVT scheduler needs to be refined. Most of the changes are located in shadow batch buffer, shadow wa context in GVT-g, where use quite a lot of i915 gem object APIs. v2: - Adjust the usage of ww lock on context pin/unpin. (maarten) - Rebase the patch on the newest staging branch. Fixes: 6b050304 ("drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
Chris Wilson authored
Use the right intel_gt stored as a backpointer in intel_vgpu. Signed-off-by:
-
Chris Wilson authored
Rather than break existing context objects by incorrectly forcing them to rogue cache coherency and trying to assert a new mapping, read the reg whitelist from the default context image. And use gvt->gt, never &dev_priv->gt. Fixes: 493f30cd ("drm/i915/gvt: parse init context to update cmd accessible reg whitelist") Acked-by:
-
- 19 Feb, 2021 2 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2021-02-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Restrict DRM_I915_DEBUG to developer builds (Chris) - Fix return and error codes (Dan) - Suspend/Resume fix (Chris) - Disable atomics in L3 for gen9 (Chris) - Flush before changing register state (Chris) - Fix for GLK's HDMI (Ville) - Fix ILK+'s plane strides with Xtiling (Ville) - Correct surface base address for renderclear (Chris) Signed-off-by:
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.12-2021-02-18' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.12-2021-02-18: amdgpu: - Prefer Bhawan's unused variable fix - Fixes for high priority queues on gfx8,9 - swSMU fixes for sienna cichlid - swSMU fixes for renoir - mmhub client id fixes for arcturus - SMUIO fixes for navi family - swSMU fixes for vangogh - GPU reset cleanup - Display fixes - GFX harvesting fix for sienna cichlid - Fix reference clock on Renoir - Misc fixes and cleanups amdkfd: - Fix for unique id query - Fix recursive lock warnings radeon: - Remove confusing VCE messages on Oland Signed-off-by:
-
- 18 Feb, 2021 8 commits
-
-
Alex Deucher authored
Fixes the rlc reference clock used for GPU timestamps. Value is 100Mhz. Confirmed with hardware team. v2: reword commit message. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1480Acked-by:
-
Alex Deucher authored
Disable it on those boards. No functional change, this just removes the message about VCE failing to initialize. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197327Reviewed-by:
-
Felix Kuehling authored
memalloc_nofs_save/restore are no longer sufficient to prevent recursive lock warnings when holding locks that can be taken in MMU notifiers. Use memalloc_noreclaim_save/restore instead. Fixes: f920e413 ("mm: track mmu notifiers in fs_reclaim_acquire/release") CC: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Philip Yang <Philip.Yang@amd.com> Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Jan Kokemüller authored
dcn21_validate_bandwidth() calls functions that use floating point math. On my machine this sometimes results in simd exceptions when there are other FPU users such as KVM virtual machines running. The screen freezes completely in this case. Wrapping the function with DC_FP_START()/DC_FP_END() seems to solve the problem. This mirrors the approach used for dcn20_validate_bandwidth. Tested on a AMD Ryzen 7 PRO 4750U (Renoir). Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206987Signed-off-by:
Jan Kokemüller <jan.kokemueller@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Fix potential integer overflow by casting actual_calculated_clock_100hz to u64, in order to give the compiler complete information about the proper arithmetic to use. Notice that such variable is used in a context that expects an expression of type u64 (64 bits, unsigned) and the following expression is currently being evaluated using 32-bit arithmetic: actual_calculated_clock_100hz * post_divider Fixes: 7a03fdf6 ("drm/amd/display: fix 64bit division issue on 32bit OS") Addresses-Coverity-ID: 1501691 ("Unintentional integer overflow") Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Nirmoy Das authored
Fixes: 9037246b ("drm/amd/display: Add sysfs interface for set/get srm") Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by:
-
Marek Olšák authored
This fixes incorrect TCC harvesting info reported to userspace. The impact was a very very tiny performance degradation (unnecessary GL2 cache flushes). Signed-off-by:
Marek Olšák <marek.olsak@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Bjorn Andersson authored
The meta-schema recently gained a definition for the common -supply$ property, which denotes that maxItems is not a valid property. Drop this to clear up the binding validation error. Fixes: a46c1125 ("dt-bindings: dp-connector: add binding for DisplayPort connector") Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> (cherry picked from commit ca230ab1) Link: https://patchwork.freedesktop.org/patch/msgid/20210120175922.1579835-1-bjorn.andersson@linaro.org
-
- 17 Feb, 2021 2 commits
-
-
Chris Wilson authored
The surface_state_base is an offset into the batch, so we need to pass the correct batch address for STATE_BASE_ADDRESS. Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20210210122728.20097-1-chris@chris-wilson.co.uk (cherry picked from commit 1914911f4aa08ddc05bae71d3516419463e0c567) Signed-off-by:
-
Ville Syrjälä authored
ilk+ planes get notably unhappy when the plane x+w exceeds the stride. This wasn't a problem previously because we always aligned SURF to the closest tile boundary so the x offset never got particularly large. But now with async flips we have to align to 256KiB instead and thus this becomes a real issue. On ilk/snb/ivb it looks like the accesses just wrap early to the next tile row when scanout goes past the SURF+n*stride boundary, hsw/bdw suffer more heavily and start to underrun constantly. i965/g4x appear to be immune. vlv/chv I've not yet checked. Let's borrow another trick from the skl+ code and search backwards for a better SURF offset in the hopes of getting the x offset below the limit. IIRC when I ran into a similar issue on skl years ago it was causing the hardware to fall over pretty hard as well. And let's be consistent and include i965/g4x in the check as well, just in case I just got super lucky somehow when I wasn't able to reproduce the issue. Not that it really matters since we still use 4k SURF alignment for i965/g4x anyway. Fixes: 6ede6b06 ("drm/i915: Implement async flips for vlv/chv") Fixes: 4bb18054 ("drm/i915: Implement async flip for ilk/snb") Fixes: 2a636e24 ("drm/i915: Implement async flip for ivb/hsw") Fixes: cda195f1 ("drm/i915: Implement async flips for bdw") Signed-off-by:
-
- 12 Feb, 2021 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2021-02-11' of git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next-fixes cherry picked from drm-misc-next for v5.12: - Assorted small fixes. - Disable and remove gma3600 support. - Fix CEC for vc4/hdmi. Signed-off-by:
-
