- 11 Apr, 2024 3 commits
-
-
Dave Airlie authored
Merge tag 'drm-misc-fixes-2024-04-11' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: ast: - Fix soft lockup client: - Protect connector modes with mode_config mutex host1x: - Do not setup DMA for virtual addresses ivpu: - Fix deadlock in context_xa - PCI fixes - Fixes to error handling nouveau: - gsp: Fix OOB access - Fix casting panfrost: - Fix error path in MMU code qxl: - Revert "drm/qxl: simplify qxl_fence_wait" vmwgfx: - Enable DMA for SEV mappings Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240411073403.GA9895@localhost.localdomain
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-6.9-2024-04-10' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.9-2024-04-10: amdgpu: - GPU reset fixes - Fix some confusing logging - UMSCH fix - Aborted suspend fix - DCN 3.5 fixes - S4 fix - MES logging fixes - SMU 14 fixes - SDMA 4.4.2 fix - KASAN fix - SMU 13.0.10 fix - VCN partition fix - GFX11 fixes - DWB fixes - Plane handling fix - FAMS fix - DCN 3.1.6 fix - VSC SDP fixes - OLED panel fix - GFX 11.5 fix amdkfd: - GPU reset fixes Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2024-04-10' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes Display fixes: - Couple CDCLK programming fixes (Ville) - HDCP related fix (Suraj) - 4 Bigjoiner related fixes (Ville) Core fix: - Fix for a circular locking around GuC on reset+wedged case (John) Signed-off-by:
-
- 10 Apr, 2024 26 commits
-
-
Yifan Zhang authored
This patch to differentiate external rev id for gfx 11.5.0. Signed-off-by:
Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by:
Tim Huang <Tim.Huang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Zhongwei authored
[Why] OLED panels show no display for large vtotal timings. [How] Check if ss is enabled and read from lut for spread spectrum percentage. Adjust dprefclk as required. DP_DTO adjustment is for edp only. Cc: stable@vger.kernel.org Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
Zhongwei <zhongwei.zhang@amd.com> Signed-off-by:
-
Harry Wentland authored
The previous check for the is_vsc_sdp_colorimetry_supported flag for MST sink signals did nothing. Simplify the code and use the same check for MST and SST. Cc: stable@vger.kernel.org Reviewed-by:
Agustin Gutierrez <agustin.gutierrez@amd.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Harry Wentland authored
In order for display colorimetry to work correctly on DP displays we need to send the VSC SDP packet. We should only do so for panels with DPCD revision greater or equal to 1.4 as older receivers might have problems with it. Cc: stable@vger.kernel.org Cc: Joshua Ashton <joshua@froggi.es> Cc: Xaver Hugl <xaver.hugl@gmail.com> Cc: Melissa Wen <mwen@igalia.com> Cc: Agustin Gutierrez <Agustin.Gutierrez@amd.com> Reviewed-by:
-
Fudongwang authored
[Why] Wrong logic cause screen corruption. [How] Port logic from DCN35/314. Cc: stable@vger.kernel.org Reviewed-by:
Fudongwang <fudong.wang@amd.com> Signed-off-by:
-
Dillon Varone authored
[WHY&HOW] We should not be recursively calling the manual trigger programming function when FAMS is not in use. Cc: stable@vger.kernel.org Reviewed-by:
Alvin Lee <alvin.lee2@amd.com> Acked-by:
Dillon Varone <dillon.varone@amd.com> Signed-off-by:
-
Wenjing Liu authored
[why] In current implemenation ODM mode is only reset when the last plane is removed from dc state. For any dc validate we will always remove all current planes and add new planes. However when switching from no planes to 1 plane, ODM mode is not reset because no planes get removed. This has caused an issue where we kept ODM combine when it should have been remove when a plane is added. The change is to reset ODM mode when adding the first plane. Cc: stable@vger.kernel.org Reviewed-by:
Wenjing Liu <wenjing.liu@amd.com> Signed-off-by:
-
Tim Huang authored
The RB bitmap should be global active RB bitmap & active RB bitmap based on active SA. Signed-off-by:
-
Alex Hung authored
mode_config's max width x height is 4096x2160 and is higher than DWB's max resolution 3840x2160 which is returned instead. Cc: stable@vger.kernel.org Reviewed-by:
Alex Hung <alex.hung@amd.com> Signed-off-by:
-
Zhigang Luo authored
If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault. Signed-off-by:
Zhigang Luo <Zhigang.Luo@amd.com> Reviewed-by:
Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
-
ZhenGuo Yin authored
[Why] set_q_mode_offs don't get cleared after GPU reset, nexting SET_Q_MODE packet to init shadow memory will be skiped, hence there has a page fault. [How] VM flush is needed after GPU reset, clear set_q_mode_offs when emitting VM flush. Fixes: 8bc75586 ("drm/amdgpu: workaround to avoid SET_Q_MODE packets v2") Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
ZhenGuo Yin <zhenguo.yin@amd.com> Signed-off-by:
-
Lijo Lazar authored
VCN need not be shared in CPX mode always for all GFX 9.4.3 SOC SKUs. In certain configs, VCN instance can be exclusively allocated to a partition even under CPX mode. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
James Zhu <James.Zhu@amd.com> Reviewed-by:
Asad Kamal <asad.kamal@amd.com> Acked-by:
-
Kenneth Feng authored
fix the high voltage issue after unload on smu 13.0.10 Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Alex Hung authored
[WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized. [HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3199Reviewed-by:
Rodrigo Siqueira <rodrigo.siqueira@amd.com> Acked-by:
Roman Li <roman.li@amd.com> Signed-off-by:
-
Tao Zhou authored
SDMA_CNTL is not set in some cases, driver configures it by itself. v2: simplify code Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
-
Yifan Zhang authored
This patch to add smu 14.0.1 support Reviewed-by:
-
lima1002 authored
update ppsmc.h pmfw.h and driver_if.h for smu v14_0_1 Reviewed-by:
lima1002 <li.ma@amd.com> Signed-off-by:
-
shaoyunl authored
From MES version 0x54, the log entry increased and require the log buffer size to be increased. The 16k is maximum size agreed Signed-off-by:
shaoyunl <shaoyun.liu@amd.com> Acked-by:
-
shaoyunl authored
The MES log might slow down the performance for extra step of log the data, disable it by default and introduce a parameter can enable it when necessary Signed-off-by:
-
Tim Huang authored
While doing multiple S4 stress tests, GC/RLC/PMFW get into an invalid state resulting into hard hangs. Adding a GFX reset as workaround just before sending the MP1_UNLOAD message avoids this failure. Signed-off-by:
-
Li Ma authored
There is a new DCN veriosn 3.5.1 need to load Signed-off-by:
-
Lijo Lazar authored
For SOC21 ASICs, there is an issue in re-enabling PM features if a suspend got aborted. In such cases, reset the device during resume phase. This is a workaround till a proper solution is finalized. Signed-off-by:
Yang Wang <kevinyang.wang@amd.com> Reviewed-by:
-
Lang Yu authored
Otherwise the old one will be used during GPU reset. That's not expected. Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by:
Feifei Xu <Feifei.Xu@amd.com> Signed-off-by:
-
Lijo Lazar authored
Downgrade to debug information when IBs are skipped. Also, use dev_* to identify the device. Signed-off-by:
-
Alex Deucher authored
There are cases where soft reset seems to succeed, but does not, so always use mode1/2 for now. Reviewed-by:
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by:
-
Harish Kasiviswanathan authored
Currently, with F32 HWS GPU reset is only when unmap queue fails. However, if compute queue doesn't repond to preemption request in time unmap will return without any error. In this case, only preemption error is logged and Reset is not triggered. Call GPU reset in this case also. Reviewed-by:
Mukul Joshi <mukul.joshi@amd.com> Signed-off-by:
-
- 09 Apr, 2024 2 commits
-
-
Zack Rusin authored
Enable DMA mappings in vmwgfx after TTM has been fixed in commit 3bf3710e ("drm/ttm: Add a generic TTM memcpy move for page-based iomem") This enables full guest-backed memory support and in particular allows usage of screen targets as the presentation mechanism. Signed-off-by:
Zack Rusin <zack.rusin@broadcom.com> Reported-by:
Ye Li <ye.li@broadcom.com> Tested-by:
Martin Krastev <martin.krastev@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.rusin@broadcom.com
-
Dave Airlie authored
This reverts: nouveau/gsp: don't check devinit disable on GSP. and applies a further fix. It turns out the open gpu driver, checks this register, but only for display. Match that behaviour and in the turing path only disable the display block. (ampere already only does displays). Fixes: 5d4e8ae6 ("nouveau/gsp: don't check devinit disable on GSP.") Reviewed-by:
Danilo Krummrich <dakr@redhat.com> Signed-off-by:
-
- 08 Apr, 2024 9 commits
-
-
Ville Syrjälä authored
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change switch between non-VRR and VRR timings generators on the fly, or even when sending the push to the transcoder. For now just disable VRR when bigjoiner is needed. Cc: stable@vger.kernel.org Tested-by:
Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-6-ville.syrjala@linux.intel.comSigned-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit f9d5e51d) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change the timings at the same time. For now just disable live M/N updates when bigjoiner is needed. Cc: stable@vger.kernel.org Tested-by:
Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-5-ville.syrjala@linux.intel.comSigned-off-by:
-
Ville Syrjälä authored
The current modeset sequence can't handle port sync and bigjoiner at the same time. Refuse port sync when bigjoiner is needed, at least until we fix the modeset sequence. v2: Add a FIXME (Vandite) Cc: stable@vger.kernel.org Tested-by:
-
Ville Syrjälä authored
Bigjoiner seem to be causing all kinds of grief to the PSR code currently. I don't believe there is any hardware issue but the code simply not handling this correctly. For now just disable PSR when bigjoiner is needed. Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-3-ville.syrjala@linux.intel.comReviewed-by:
Arun R Murthy <arun.r.mruthy@intel.com> Acked-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
John Harrison authored
The previous fix for the circlular lock splat about the busyness worker wasn't quite complete. Even though the reset-in-progress flag is cleared at the start of intel_uc_reset_finish, the entire function is still inside the reset mutex lock. Not sure why the patch appeared to fix the issue both locally and in CI. However, it is now back again. There is a further complication that the wedge code path within intel_gt_reset() jumps around so much that it results in nested reset_prepare/_finish calls. That is, the call sequence is: intel_gt_reset | reset_prepare | __intel_gt_set_wedged | | reset_prepare | | reset_finish | reset_finish The nested finish means that even if the clear of the in-progress flag was moved to the end of _finish, it would still be clear for the entire second call. Surprisingly, this does not seem to be causing any other problems at present. As an aside, a wedge on fini does not call the finish functions at all. The reset_in_progress flag is left set (twice). So instead of trying to cancel the worker anywhere at all in the reset path, just add a cancel to intel_guc_submission_fini instead. Note that it is not a problem if the worker is still active during a reset. Either it will run before the reset path starts locking things and will simply block the reset code for a tiny amount of time. Or it will run after the locks have been acquired and will early exit due to the try-lock. Also, do not use the reset-in-progress flag to decide whether a synchronous cancel is safe (from a lockdep perspective) or not. Instead, use the actual reset mutex state (both the genuine one and the custom rolled BACKOFF one). Fixes: 0e00a881 ("drm/i915/guc: Avoid circular locking issue on busyness flush") Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240329235306.1559639-1-John.C.Harrison@Intel.com (cherry picked from commit 3563d855) Signed-off-by:
-
Suraj Kandpal authored
HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x capable. --v2 -Assign hdcp_capable and hdcp2_capable to false [Chaitanya] --v3 -Fix variable assignment [Chaitanya] Fixes: 813cca96 ("drm/i915/hdcp: Add new remote capability check shim function") Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240401055652.276785-2-suraj.kandpal@intel.com (cherry picked from commit 6809f924) Signed-off-by:
-
Ville Syrjälä authored
Currently we only consider the relationship of the old and new CDCLK frequencies when determining whether to do the repgramming from intel_set_cdclk_pre_plane_update() or intel_set_cdclk_post_plane_update(). It is technically possible to have a situation where the CDCLK frequency is decreasing, but the voltage_level is increasing due a DDI port. In this case we should bump the voltage level already in intel_set_cdclk_pre_plane_update() (so that the voltage_level will have been increased by the time the port gets enabled), while leaving the CDCLK frequency unchanged (as active planes/etc. may still depend on it). We can then reduce the CDCLK frequency to its final value from intel_set_cdclk_post_plane_update(). In order to handle that correctly we shall construct a suitable amalgam of the old and new cdclk states in intel_set_cdclk_pre_plane_update(). And we can simply call intel_set_cdclk() unconditionally in both places as it will not do anything if nothing actually changes vs. the current hw state. v2: Handle cdclk_state->disable_pipes v3: Only synchronize the cd2x update against the pipe's vblank when the cdclk frequency is changing during the current commit phase (Gustavo) Cc: stable@vger.kernel.org Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently we always reprogram CDCLK from the intel_set_cdclk_pre_plane_update() when using squash/crawl. The code only works correctly for the cd2x update or full modeset cases, and it was simply never updated to deal with squash/crawl. If the CDCLK frequency is increasing we must reprogram it before we do anything else that might depend on the new higher frequency, and conversely we must not decrease the frequency until everything that might still depend on the old higher frequency has been dealt with. Since cdclk_state->pipe is only relevant when doing a cd2x update we can't use it to determine the correct sequence during squash/crawl. To that end introduce cdclk_state->disable_pipes which simply indicates that we must perform the update while the pipes are disable (ie. during intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new CDCLK frequency comparsiong as for cd2x updates. The only remaining problem case is when the voltage_level needs to increase due to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are being disabled). The current approach will not bump the voltage level up until after the port has already been enabled, which is too late. But we'll take care of that case separately. v2: Don't break the "must disable pipes case" v3: Keep the on stack 'pipe' for future use Cc: stable@vger.kernel.org Fixes: d62686ba ("drm/i915/adl_p: CDCLK crawl support for ADL") Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de>
-
