summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-08-19Revert "drm/amd/display: Refactor function dm_dp_mst_is_port_support_mode()"Greg Kroah-Hartman1-147/+85
This reverts commit 6b2fb172853261829229237766d078638267042f which is commit fa57924c76d995e87ca3533ec60d1d5e55769a27 upstream. It breaks the build on arm64 and arm systems, and trying to unwind the ifdef mess to fix it up was not simple at all. So revert it and wait for a fixed change to come back. Cc: Jerry Zuo <jerry.zuo@amd.com> Cc: Zaeem Mohamed <zaeem.mohamed@amd.com> Cc: Wayne Lin <wayne.lin@amd.com> Cc: Daniel Wheeler <daniel.wheeler@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Kevin Holm <kevin@holm.dev> Reported-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/b27c5434-f1b1-4697-985b-91bb3e9a22df@roeck-us.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-19drm/amdgpu/display: Fix null pointer dereference in ↵Srinivasan Shanmugam1-1/+4
dc_stream_program_cursor_position commit fa4c500ce93f4f933c38e6d6388970e121e27b21 upstream. The fix involves adding a null check for 'stream' at the beginning of the function. If 'stream' is NULL, the function immediately returns false. This ensures that 'stream' is not NULL when we dereference it to access 'ctx' in 'dc = stream->ctx->dc;' the function. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:398 dc_stream_program_cursor_position() error: we previously assumed 'stream' could be null (see line 397) drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c 389 bool dc_stream_program_cursor_position( 390 struct dc_stream_state *stream, 391 const struct dc_cursor_position *position) 392 { 393 struct dc *dc; 394 bool reset_idle_optimizations = false; 395 const struct dc_cursor_position *old_position; 396 397 old_position = stream ? &stream->cursor_position : NULL; ^^^^^^^^ The patch adds a NULL check --> 398 dc = stream->ctx->dc; ^^^^^^^^ The old code didn't check 399 400 if (dc_stream_set_cursor_position(stream, position)) { 401 dc_z10_restore(dc); 402 403 /* disable idle optimizations if enabling cursor */ 404 if (dc->idle_optimizations_allowed && 405 (!old_position->enable || dc->debug.exit_idle_opt_for_cursor_updates) && 406 position->enable) { 407 dc_allow_idle_optimizations(dc, false); Fixes: f63f86b5affc ("drm/amd/display: Separate setting and programming of cursor") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-19drm/amd/display: Solve mst monitors blank out problem after resumeWayne Lin1-1/+2
commit e33697141bac18906345ea46533a240f1ad3cd21 upstream. [Why] In dm resume, we firstly restore dc state and do the mst resume for topology probing thereafter. If we change dpcd DP_MSTM_CTRL value after LT in mst reume, it will cause light up problem on the hub. [How] Revert commit 202dc359adda ("drm/amd/display: Defer handling mst up request in resume"). And adjust the reason to trigger dc_link_detect by DETECT_REASON_RESUMEFROMS3S4. Cc: stable@vger.kernel.org Fixes: 202dc359adda ("drm/amd/display: Defer handling mst up request in resume") Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Fangzhi Zuo <jerry.zuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-19drm/amd/display: Prevent IPX From Link Detect and Set ModeFangzhi Zuo1-0/+10
commit 1ff6631baeb1f5d69be192732d0157a06b43f20a upstream. IPX involvment proven to affect LT, causing link loss. Need to prevent IPX enabled in LT process in which link detect and set mode are main procedures that have LT taken place. Reviewed-by: Roman Li <roman.li@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Kevin Holm <kevin@holm.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-19drm/amd/display: Separate setting and programming of cursorHarry Wentland5-33/+72
commit f63f86b5affcc2abd1162f11824b9386fc06ac94 upstream. We're seeing issues when user-space tries to do an atomic update of the primary surface, as well as the cursor. These two updates are separate calls into DC and don't currently act as an atomic update. This might lead to cursor updates being locked out and cursors stuttering. In order to solve this problem we want to separate the setting and programming of cursor attributes and position. That's what we're doing in this patch. The subsequent patch will then be able to use the cursor setters in independent cursor updates, as well as in atomic commits. Reviewed-by: Agustin Gutierrez <agustin.gutierrez@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Kevin Holm <kevin@holm.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-19drm/amd/display: Defer handling mst up request in resumeWayne Lin1-1/+0
commit 202dc359addab29451d3d18243c3d957da5392c8 upstream. [Why] Like commit ec5fa9fcdeca ("drm/amd/display: Adjust the MST resume flow"), we want to avoid handling mst topology changes before restoring the old state. If we enable DP_UP_REQ_EN before calling drm_atomic_helper_resume(), have changce to handle CSN event first and fire hotplug event before restoring the cached state. [How] Disable mst branch sending up request event before we restoring the cached state. DP_UP_REQ_EN will be set later when we call drm_dp_mst_topology_mgr_resume(). Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/amd/display: Change ASSR disable sequenceSwapnil Patel1-2/+1
commit 2d696cc837eaf5394d79bfd2b0b0483c4778aa83 upstream. [Why] Currently disabling ASSR before stream is disabled causes visible display corruption. [How] Move disable ASSR command to after stream has been disabled. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Swapnil Patel <swapnil.patel@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/amd/display: Add null check in resource_log_pipe_topology_updateNatanel Roizenman1-0/+4
commit 899d92fd26fe780aad711322aa671f68058207a6 upstream. [WHY] When switching from "Extend" to "Second Display Only" we sometimes call resource_get_otg_master_for_stream on a stream for the eDP, which is disconnected. This leads to a null pointer dereference. [HOW] Added a null check in dc_resource.c/resource_log_pipe_topology_update. CC: stable@vger.kernel.org Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Natanel Roizenman <natanel.roizenman@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14Revert "drm/amd/display: Add NULL check for 'afb' before dereferencing in ↵Ivan Lipski1-12/+4
amdgpu_dm_plane_handle_cursor_update" commit 778e3979c5dc9cbdb5d1b92afed427de6bc483b4 upstream. [WHY] This patch is a dupplicate implementation of 14bcf29b, which we are reverting due to a regression with kms_plane_cursor IGT tests. This reverts commit 38e6f715b02b572f74677eb2f29d3b4bc6f1ddff. Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Tested-by: George Zhang <George.zhang@amd.com> Signed-off-by: Ivan Lipski <ivlipski@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14Revert "drm/amd/display: Handle HPD_IRQ for internal link"Sung-huai Wang1-15/+9
commit a2919b25778b7479e477cf49af8c680017eafc24 upstream. [How&Why] This reverts commit 239b31bd5c3fef3698440bf6436b2068c6bb08a3. Due to the it effects Replay resync. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Sung-huai Wang <danny.wang@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/radeon: Remove __counted_by from StateArray.states[]Bill Wendling1-1/+1
commit 2bac084468847cfe5bbc7166082b2a208514bb1c upstream. Work for __counted_by on generic pointers in structures (not just flexible array members) has started landing in Clang 19 (current tip of tree). During the development of this feature, a restriction was added to __counted_by to prevent the flexible array member's element type from including a flexible array member itself such as: struct foo { int count; char buf[]; }; struct bar { int count; struct foo data[] __counted_by(count); }; because the size of data cannot be calculated with the standard array size formula: sizeof(struct foo) * count This restriction was downgraded to a warning but due to CONFIG_WERROR, it can still break the build. The application of __counted_by on the states member of 'struct _StateArray' triggers this restriction, resulting in: drivers/gpu/drm/radeon/pptable.h:442:5: error: 'counted_by' should not be applied to an array with element of unknown size because 'ATOM_PPLIB_STATE_V2' (aka 'struct _ATOM_PPLIB_STATE_V2') is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size] 442 | ATOM_PPLIB_STATE_V2 states[] __counted_by(ucNumEntries); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Remove this use of __counted_by to fix the warning/error. However, rather than remove it altogether, leave it commented, as it may be possible to support this in future compiler releases. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2028 Fixes: efade6fe50e7 ("drm/radeon: silence UBSAN warning (v3)") Signed-off-by: Bill Wendling <morbo@google.com> Co-developed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/mgag200: Bind I2C lifetime to DRM deviceThomas Zimmermann1-2/+4
commit eb1ae34e48a09b7a1179c579aed042b032e408f4 upstream. Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc. Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Fixes: b279df242972 ("drm/mgag200: Switch I2C code to managed cleanup") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.0+ Link: https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/mgag200: Set DDC timeout in millisecondsThomas Zimmermann1-1/+1
commit ecde5db1598aecab54cc392282c15114f526f05f upstream. Compute the i2c timeout in jiffies from a value in milliseconds. The original values of 2 jiffies equals 2 milliseconds if HZ has been configured to a value of 1000. This corresponds to 2.2 milliseconds used by most other DRM drivers. Update mgag200 accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)") Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.5+ Link: https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/lima: Mark simple_ondemand governor as softdepDragan Simic1-0/+1
commit 0c94f58cef319ad054fd909b3bf4b7d09c03e11c upstream. Lima DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Lima, to have its kernel module included in the initial ramdisk. This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or may have forced some users to introduce unnecessary workarounds. Having simple_ondemand marked as a softdep for Lima may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [3] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [4] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet. [1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinephone/-/blob/6.7-megi/config?ref_type=heads#L5749 [2] https://gitlab.com/postmarketOS/pmaports/-/blob/7f64e287e7732c9eaa029653e73ca3d4ba1c8598/main/linux-postmarketos-allwinner/config-postmarketos-allwinner.aarch64#L4654 [3] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d [4] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad Cc: Philip Muller <philm@manjaro.org> Cc: Oliver Smith <ollieparanoid@postmarketos.org> Cc: Daniel Smith <danct12@disroot.org> Cc: stable@vger.kernel.org Fixes: 1996970773a3 ("drm/lima: Add optional devfreq and cooling device support") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/fdaf2e41bb6a0c5118ff9cc21f4f62583208d885.1718655070.git.dsimic@manjaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/dp_mst: Skip CSN if topology probing is not done yetWayne Lin1-0/+11
commit ddf983488c3e8d30d5c2e2b315ae7d9cd87096ed upstream. [Why] During resume, observe that we receive CSN event before we start topology probing. Handling CSN at this moment based on uncertain topology is unnecessary. [How] Add checking condition in drm_dp_mst_handle_up_req() to skip handling CSN if the topology is yet to be probed. Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-3-Wayne.Lin@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/bridge: analogix_dp: properly handle zero sized AUX transactionsLucas Stach1-4/+1
commit e82290a2e0e8ec5e836ecad1ca025021b3855c2d upstream. Address only transactions without any data are valid and should not be flagged as short transactions. Simply return the message size when no transaction errors occured. CC: stable@vger.kernel.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240318203925.2837689-1-l.stach@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/test: fix the gem shmem test to map the sg table.Dave Airlie1-0/+11
commit 62b45bab010d1b0cea6166f818f1cd0666a6d8d8 upstream. The test here creates an sg table, but never maps it, when we get to drm_gem_shmem_free, the helper tries to unmap and this causes warnings on some platforms and debug kernels. This also sets a 64-bit dma mask, as I see an swiotlb warning if I stick with the default 32-bit one. Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Marco Pagani <marpagan@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240715083551.777807-1-airlied@gmail.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/i915/display: correct dual pps handling for MTL_PCH+Dnyaneshwar Bhadane2-0/+6
commit 1b85bdb0fadb42f5ef75ddcd259fc1ef13ec04de upstream. On the PCH side the second PPS was introduced in ICP+.Add condition On MTL_PCH and greater platform also having the second PPS. Note that DG1/2 south block only has the single PPS, so need to exclude the fake DG1/2 PCHs Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11488 Fixes: 93cbc1accbce ("drm/i915/mtl: Add fake PCH for Meteor Lake") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240801111141.574854-1-dnyaneshwar.bhadane@intel.com (cherry picked from commit da1878b61c8d480c361ba6a39ce8a31c80b65826) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/client: fix null pointer dereference in drm_client_modeset_probeMa Ke1-0/+5
commit 113fd6372a5bb3689aba8ef5b8a265ed1529a78f upstream. In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable@vger.kernel.org Fixes: cf13909aee05 ("drm/fb-helper: Move out modeset config code") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240802044736.1570345-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/i915/gem: Adjust vma offset for framebuffer mmap offsetAndi Shyti1-0/+2
commit 1ac5167b3a90c9820daa64cc65e319b2d958d686 upstream. When mapping a framebuffer object, the virtual memory area (VMA) offset ('vm_pgoff') should be adjusted by the start of the 'vma_node' associated with the object. This ensures that the VMA offset is correctly aligned with the corresponding offset within the GGTT aperture. Increment vm_pgoff by the start of the vma_node with the offset= provided by the user. Suggested-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.9+ [Joonas: Add Cc: stable] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802083850.103694-2-andi.shyti@linux.intel.com (cherry picked from commit 60a2066c50058086510c91f404eb582029650970) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/amdgpu: Forward soft recovery errors to userspaceJoshua Ashton1-2/+1
commit 829798c789f567ef6ba4b084c15b7b5f3bd98d51 upstream. As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ Signed-off-by: Joshua Ashton <joshua@froggi.es> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/amd/display: Skip Recompute DSC Params if no Stream on LinkFangzhi Zuo1-0/+3
commit 50e376f1fe3bf571d0645ddf48ad37eb58323919 upstream. [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 [how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cbd16fef) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/i915/gem: Fix Virtual Memory mapping boundaries calculationAndi Shyti1-6/+47
commit 8bdd9ef7e9b1b2a73e394712b72b22055e0e26c3 upstream. Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. Fixes: c58305af1835 ("drm/i915: Use remap_io_mapping() to prefault all PTE in a single pass") Reported-by: Jann Horn <jannh@google.com> Co-developed-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.9+ Reviewed-by: Jann Horn <jannh@google.com> Reviewed-by: Jonathan Cavitt <Jonathan.cavitt@intel.com> [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802083850.103694-3-andi.shyti@linux.intel.com (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-14drm/xe: Take ref to VM in delayed snapshotMatthew Brost1-1/+14
[ Upstream commit 642dfc9d5964b26f66fa6c28ce2861e11f9232aa ] Kernel BO's don't take a ref to the VM, we need the VM for the delayed snapshot, so take a ref to the VM in delayed snapshot. v2: - Check for lrc_bo before taking a VM ref (CI) - Check lrc_bo->vm before taking / dropping a VM ref (CI) - Drop VM in xe_lrc_snapshot_free v5: - Fix commit message wording (Johnathan) Fixes: 47058633d9c5 ("drm/xe: Move lrc snapshot capturing to xe_lrc.c") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240801154118.2547543-2-matthew.brost@intel.com (cherry picked from commit c3bc97d2f102ddd5a8341eeb2dbae2a3e98bb46a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/xe: Minor cleanup in LRC handlingNiranjana Vishwanathapura2-3/+3
[ Upstream commit 85cfc412579c041f1aaebba71427acec75ceca39 ] Properly define register fields and remove redundant lower_32_bits(). Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240507224255.5059-2-niranjana.vishwanathapura@intel.com Stable-dep-of: 642dfc9d5964 ("drm/xe: Take ref to VM in delayed snapshot") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/xe/hwmon: Fix PL1 disable flow in xe_hwmon_power_max_writeKarthik Poosa1-1/+2
[ Upstream commit ac3191c5cf47e2d5220a1ed7353a2e498a1f415e ] In xe_hwmon_power_max_write, for PL1 disable supported case, instead of returning after PL1 disable, PL1 enable path was also being run. Fixed it by returning after disable. v2: Correct typo and grammar in commit message. (Jonathan) Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Fixes: fef6dd12b45a ("drm/xe/hwmon: Protect hwmon rw attributes with hwmon_lock") Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240801112424.1841766-1-karthik.poosa@intel.com (cherry picked from commit 146458645e505f5eac498759bcd865cf7c0dfd9a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/xe: Use dma_fence_chain_free in chain fence unused as a syncMatthew Brost1-1/+1
[ Upstream commit 4f854a8b1b85d46abd5ce206936d23f87ac5e0c9 ] A chain fence is uninitialized if not installed in a drm sync obj. Thus if xe_sync_entry_cleanup is called and sync->chain_fence is non-NULL the proper cleanup is dma_fence_chain_free rather than a dma-fence put. Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2411 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2261 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727012216.2118276-1-matthew.brost@intel.com (cherry picked from commit 7f7a2da3bf8bc0e0f6c239af495b7050056e889c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/xe/rtp: Fix off-by-one when processing rulesLucas De Marchi1-1/+1
[ Upstream commit ae02c7b7fea3e034fbd724c21d88406f71ccc2f8 ] Gustavo noticed an odd "+ 2" in rtp_mark_active() while processing rtp rules and pointed that it should be "+ 1". In fact, while processing entries without actions (OOB workarounds), if the WA is activated and has OR rules, it will also inadvertently activate the very next workaround. Test in a LNL B0 platform by moving 18024947630 on top of 16020292621, makes the latter become active: $ cat /sys/kernel/debug/dri/0/gt0/workarounds ... OOB Workarounds 18024947630 16020292621 14018094691 16022287689 13011645652 22019338487_display In future a kunit test will be added to cover the rtp checks for entries without actions. Fixes: fe19328b900c ("drm/xe/rtp: Add support for entries with no action") Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240726064337.797576-6-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit fd6797ec50c561f085bc94e3ee26f484a52af79e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Replace dm_execute_dmub_cmd with dc_wake_and_execute_dmub_cmdRodrigo Siqueira1-2/+1
[ Upstream commit f2aaed194a54d78c307c44d1829c7e1ba67e9ba5 ] In the commit c2cec7a872b6 ("drm/amd/display: Wake DMCUB before sending a command for replay feature"), replaced dm_execute_dmub_cmd with dc_wake_and_execute_dmub_cmd in multiple areas, but due to merge issues the replacement of this function in the dmub_replay_copy_settings was missed. This commit replaces the old dm_execute_dmub_cmd with dc_wake_and_execute_dmub_cmd. Fixes: 3601a35a2e9d ("drm/amd/display: Wake DMCUB before sending a command for replay feature") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6cc213b9aa34bc3213e20f9256345c5cc1495b0b) Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/i915: Attempt to get pages without eviction firstDavid Gow1-5/+7
[ Upstream commit 787db3bb6ed5cee56fc97fecdd61517d89763f0a ] In commit a78a8da51b36 ("drm/ttm: replace busy placement with flags v6"), __i915_ttm_get_pages was updated to use flags instead of the separate 'busy' placement list. However, the behaviour was subtly changed. Originally, the function would attempt to use the preferred placement without eviction, and give an opportunity to restart the operation before falling back to allowing eviction. This was unintentionally changed, as the preferred placement was not given the TTM_PL_FLAG_DESIRED flag, and so eviction could be triggered in that first pass. This caused thrashing, and a significant performance regression on DG2 systems with small BAR. For example, Minecraft and Team Fortress 2 would drop to single-digit framerates. Restore the original behaviour by marking the initial placement as desired on that first attempt. Also, rework this to use a separate struct ttm_palcement, as the individual placements are marked 'const', so hot-patching the flags is even more dodgy than before. Thanks to Justin Brewer for bisecting this. Fixes: a78a8da51b36 ("drm/ttm: replace busy placement with flags v6") Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11255 Signed-off-by: David Gow <david@davidgow.net> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240804091851.122186-3-david@davidgow.net (cherry picked from commit 92653f2a572505adaf7f13f695c1907e71a1dc84) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/i915: Allow evicting to use the requested placementDavid Gow1-1/+0
[ Upstream commit 264b5b5980061d8c6a6a30c031cdec1179fe2bae ] In commit a78a8da51b36 ("drm/ttm: replace busy placement with flags v6"), the old system of having a separate placement list (for placements which should be used without eviction) and a 'busy' placement list (for placements which should be attempted if eviction is required) was replaced with a new one where placements could be marked 'FALLBACK' (to be attempted if eviction is required) or 'DESIRED' (to be attempted first, but not if eviction is required). i915 had always included the requested placement in the list of 'busy' placements: i.e., the placement could be used either if eviction is required or not. But when the new system was put in place, the requested (first) placement was marked 'DESIRED', so would never be used if eviction became necessary. While a bug in the original commit prevented this flag from working, when this was fixed in 4a0e7b3c ("drm/i915: fix applying placement flag"), it caused long hangs on DG2 systems with small BAR. Don't mark the requested placement DESIRED (or FALLBACK), allowing it to be used in both situations. This matches the old behaviour, and resolves the hangs. Thanks to Justin Brewer for bisecting the issue. Fixes: a78a8da51b36 ("drm/ttm: replace busy placement with flags v6") Fixes: 4a0e7b3c3753 ("drm/i915: fix applying placement flag") Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11255 Signed-off-by: David Gow <david@davidgow.net> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240804091851.122186-2-david@davidgow.net (cherry picked from commit 54bf0af90844fbf18f5be3272eda69198dfdb622) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/atomic: allow no-op FB_ID updates for async flipsSimon Ser1-11/+4
[ Upstream commit 929725bd7eb4eea1f75197d9847f3f1ea5afdad1 ] User-space is allowed to submit any property in an async flip as long as the value doesn't change. However we missed one case: as things stand, the kernel rejects no-op FB_ID changes on non-primary planes. Fix this by changing the conditional and skipping drm_atomic_check_prop_changes() only for FB_ID on the primary plane (instead of skipping for FB_ID on any plane). Fixes: 0e26cc72c71c ("drm: Refuse to async flip with atomic prop changes") Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: André Almeida <andrealmeid@igalia.com> Tested-by: Xaver Hugl <xaver.hugl@kde.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Michel Dänzer <michel.daenzer@mailbox.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240731191014.878320-1-contact@emersion.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Fix null pointer deref in dcn20_resource.cAurabindo Pillai1-4/+5
[ Upstream commit ecbf60782662f0a388493685b85a645a0ba1613c ] Fixes a hang thats triggered when MPV is run on a DCN401 dGPU: mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all and then enabling fullscreen playback (double click on the video) The following calltrace will be seen: [ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 181.843997] #PF: supervisor instruction fetch in kernel mode [ 181.844003] #PF: error_code(0x0010) - not-present page [ 181.844009] PGD 0 P4D 0 [ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI [ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018 [ 181.844044] RIP: 0010:0x0 [ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005 [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000 [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [ 181.844141] Call Trace: [ 181.844146] <TASK> [ 181.844153] ? show_regs+0x6d/0x80 [ 181.844167] ? __die+0x24/0x80 [ 181.844179] ? page_fault_oops+0x99/0x1b0 [ 181.844192] ? do_user_addr_fault+0x31d/0x6b0 [ 181.844204] ? exc_page_fault+0x83/0x1b0 [ 181.844216] ? asm_exc_page_fault+0x27/0x30 [ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu] [ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu] [ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu] [ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu] [ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu] [ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu] Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401Rodrigo Siqueira1-22/+27
[ Upstream commit 5af757124792817f8eb1bd0c80ad60fab519586b ] When users run the command: cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log The following NULL pointer dereference happens: [ +0.000003] BUG: kernel NULL pointer dereference, address: NULL [ +0.000005] #PF: supervisor instruction fetch in kernel mode [ +0.000002] #PF: error_code(0x0010) - not-present page [ +0.000002] PGD 0 P4D 0 [ +0.000004] Oops: 0010 [#1] PREEMPT SMP NOPTI [ +0.000003] RIP: 0010:0x0 [ +0.000008] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [...] [ +0.000002] PKRU: 55555554 [ +0.000002] Call Trace: [ +0.000002] <TASK> [ +0.000003] ? show_regs+0x65/0x70 [ +0.000006] ? __die+0x24/0x70 [ +0.000004] ? page_fault_oops+0x160/0x470 [ +0.000006] ? do_user_addr_fault+0x2b5/0x690 [ +0.000003] ? prb_read_valid+0x1c/0x30 [ +0.000005] ? exc_page_fault+0x8c/0x1a0 [ +0.000005] ? asm_exc_page_fault+0x27/0x30 [ +0.000012] dcn10_log_color_state+0xf9/0x510 [amdgpu] [ +0.000306] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000003] ? vsnprintf+0x2fb/0x600 [ +0.000009] dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu] [ +0.000218] ? __mod_memcg_lruvec_state+0xe8/0x170 [ +0.000008] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? debug_smp_processor_id+0x17/0x20 [ +0.000003] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? set_ptes.isra.0+0x2b/0x90 [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? _raw_spin_unlock+0x19/0x40 [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? do_anonymous_page+0x337/0x700 [ +0.000004] dtn_log_read+0x82/0x120 [amdgpu] [ +0.000207] full_proxy_read+0x66/0x90 [ +0.000007] vfs_read+0xb0/0x340 [ +0.000005] ? __count_memcg_events+0x79/0xe0 [ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000003] ? count_memcg_events.constprop.0+0x1e/0x40 [ +0.000003] ? handle_mm_fault+0xb2/0x370 [ +0.000003] ksys_read+0x6b/0xf0 [ +0.000004] __x64_sys_read+0x19/0x20 [ +0.000003] do_syscall_64+0x60/0x130 [ +0.000004] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ +0.000003] RIP: 0033:0x7fdf32f147e2 [...] This error happens when the color log tries to read the gamut remap information from DCN401 which is not initialized in the dcn401_dpp_funcs which leads to a null pointer dereference. This commit addresses this issue by adding a proper guard to access the gamut_remap callback in case the specific ASIC did not implement this function. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Add null checker before passing variablesAlex Hung1-3/+6
[ Upstream commit 8092aa3ab8f7b737a34b71f91492c676a843043a ] Checks null pointer before passing variables to functions. This fixes 3 NULL_RETURNS issues reported by Coverity. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: remove dpp pipes on failure to update pipe paramsWenjing Liu1-1/+8
[ Upstream commit 3ddd9c83ff7ac0ead38188425b14d03dc2f2c133 ] [why] There are cases where update pipe params could fail but dpp pipes are already added to the state. In this case, we should remove dpp pipes so dc state is restored back. If it is not restored, dc state is corrupted after calling this function, so if we call the same interface with the corrupted state again, we may end up programming pipe topology based on a corrupted dc state. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_computeWayne Lin1-8/+4
[ Upstream commit fcf6a49d79923a234844b8efe830a61f3f0584e4 ] [Why] When unplug one of monitors connected after mst hub, encounter null pointer dereference. It's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When commit new state which directly referring to info stored in dc_sink will cause null pointer dereference. [how] Remove redundant checking condition. Relevant condition should already be covered by checking if dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. Reviewed-by: Jerry Zuo <jerry.zuo@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: reduce ODM slice count to initial new dc state only when neededWenjing Liu2-41/+71
[ Upstream commit 9a29c4adb0997be6ba3dd92dfba14ea75a8c6ce4 ] [why] We need to decrease ODM slice when adding or removing planes because MPO support takes precedence over dynamic ODM combine. However there is a case where we remove ODM combine even for ODM combine required timing in the initial new dc state. This is normally okay because ODM will be added back after we pass DML bandwidth validation. However since we remove ODM combine in the initial new state, the previous ODM pipe allocation is lost. This may cause the new plane to take away the original secondary OPP head pipe that is still required in the new state. For a timing that requires ODM 2:1 but optimized with ODM 4:1, if we add an MPO plane, we will not have enough pipe to preserve ODM 4:1. In this case we should reduce ODM slice count then try to add the MPO plane again. By reducing, we are gradually remove 1 ODM slice from right most side one at a time until we have enough free pipes for the new plane. If we remove ODM combine entirely, we could use the pipe at ODM slice index 1 as a DPP pipe for the new plane. But ODM slice 1 is still needed as the timing requires ODM 2:1. This transition is not seamless and user will see corruption on the screen. [how] Remove single ODM slice one at time until we have enough pipes for a new plane. Remove previous logic to always remove ODM combine entirely. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Wake DMCUB before sending a command for replay featureNicholas Kazlauskas1-3/+3
[ Upstream commit 3601a35a2e9d640233f4bc3496f7603b93f9c143 ] [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] For functions that execute within a DC context or DC lock we can wrap the direct calls to dm_execute_dmub_cmd/list with code that exits idle power optimizations and reallows once we're done with the command submission on success. For DM direct submissions the DM will need to manage the enter/exit sequencing manually. We cannot invoke a DMCUB command directly within the DM execution helper or we can deadlock. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Add NULL check for 'afb' before dereferencing in ↵Srinivasan Shanmugam1-4/+12
amdgpu_dm_plane_handle_cursor_update [ Upstream commit 38e6f715b02b572f74677eb2f29d3b4bc6f1ddff ] This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252) Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencingSrinivasan Shanmugam1-0/+3
[ Upstream commit 15c2990e0f0108b9c3752d7072a97d45d4283aea ] This commit adds null checks for the 'stream' and 'plane' variables in the dcn30_apply_idle_power_optimizations function. These variables were previously assumed to be null at line 922, but they were used later in the code without checking if they were null. This could potentially lead to a null pointer dereference, which would cause a crash. The null checks ensure that 'stream' and 'plane' are not null before they are used, preventing potential crashes. Fixes the below static smatch checker: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922) Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/pm: Fix the null pointer dereference for vega10_hwmgrBob Zhou1-4/+25
[ Upstream commit 50151b7f1c79a09117837eb95b76c2de76841dab ] Check return value and conduct null pointer handling to avoid null pointer dereference. Signed-off-by: Bob Zhou <bob.zhou@amd.com> Reviewed-by: Tim Huang <Tim.Huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amdgpu: Add lock around VF RLCG interfaceVictor Skvortsov3-0/+9
[ Upstream commit e864180ee49b4d30e640fd1e1d852b86411420c9 ] flush_gpu_tlb may be called from another thread while device_gpu_recover is running. Both of these threads access registers through the VF RLCG interface during VF Full Access. Add a lock around this interface to prevent race conditions between these threads. Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com> Reviewed-by: Zhigang Luo <zhigang.luo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/admgpu: fix dereferencing null pointer contextJesse Zhang1-1/+1
[ Upstream commit 030ffd4d43b433bc6671d9ec34fc12c59220b95d ] When user space sets an invalid ta type, the pointer context will be empty. So it need to check the pointer context before using it Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Suggested-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Tim Huang <Tim.Huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rulesMa Jun3-10/+18
[ Upstream commit d19fb10085a49b77578314f69fff21562f7cd054 ] Check the pointer value to fix potential null pointer dereference Acked-by: Yang Wang<kevinyang.wang@amd.com> Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amdgpu: Fix the null pointer dereference to ras_managerMa Jun1-2/+5
[ Upstream commit 4c11d30c95576937c6c35e6f29884761f2dddb43 ] Check ras_manager before using it Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amdgpu/pm: Fix the null pointer dereference for smu7Ma Jun1-26/+24
[ Upstream commit c02c1960c93eede587576625a1221205a68a904f ] optimize the code to avoid pass a null pointer (hwmgr->backend) to function smu7_update_edc_leakage_table. Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/xe/xe_guc_submit: Fix exec queue stop race conditionJonathan Cavitt1-1/+1
[ Upstream commit 1564d411e17f51e2f64655b4e4da015be1ba7eaa ] Reorder the xe_sched_tdr_queue_imm and set_exec_queue_banned calls in guc_exec_queue_stop. This prevents a possible race condition between the two events in which it's possible for xe_sched_tdr_queue_imm to wake the ufence waiter before the exec queue is banned, causing the ufence waiter to miss the banned state. Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240510194540.3246991-1-jonathan.cavitt@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amd/amdkfd: Fix a resource leak in svm_range_validate_and_map()Ramesh Errabolu1-2/+7
[ Upstream commit d2d3a44008fea01ec7d5a9d9ca527286be2e0257 ] Analysis of code by Coverity, a static code analyser, has identified a resource leak in the symbol hmm_range. This leak occurs when one of the prior steps before it is released encounters an error. Signed-off-by: Ramesh Errabolu <Ramesh.Errabolu@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-14drm/amdgpu/pm: Fix the param type of set_power_profile_modeMa Jun3-16/+16
[ Upstream commit f683f24093dd94a831085fe0ea8e9dc4c6c1a2d1 ] Function .set_power_profile_mode need an array as input parameter. So define variable workload as an array to fix the below coverity warning. "Passing &workload to function hwmgr->hwmgr_func->set_power_profile_mode which uses it as an array. This might corrupt or misinterpret adjacent memory locations" Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>