summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/amdgpu
AgeCommit message (Collapse)AuthorFilesLines
42 hoursdrm/amdgpu/userq: assign an error code for invalid userq vaPrike Liang1-0/+2
commit 883bd89d00085c2c5f1efcd25861745cb039f9e3 upstream. It should return an error code if userq VA validation fails. Fixes: 9e46b8bb0539 ("drm/amdgpu: validate userq buffer virtual address and size") Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
42 hoursdrm/amdgpu: Fix function header names in amdgpu_connectors.cSrinivasan Shanmugam1-3/+12
commit 38ab33dbea594700c8d6cc81eec0a54e95d3eb2f upstream. Align the function headers for `amdgpu_max_hdmi_pixel_clock` and `amdgpu_connector_dvi_mode_valid` with the function implementations so they match the expected kdoc style. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1199: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Returns the maximum supported HDMI (TMDS) pixel clock in KHz. drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1212: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Validates the given display mode on DVI and HDMI connectors. Fixes: 585b2f685c56 ("drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)") Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
42 hoursdrm/amdgpu: Fix unintended error log in VCN5_0_0Sathishkumar S1-2/+3
commit 46b0e6b9d749cfa891e6969d6565be1131c53aa2 upstream. The error log is supposed to be gaurded under if failure condition. Fixes: faab5ea08367 ("drm/amdgpu: Check vcn sram load return value") Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
42 hoursdrm/amdkfd: Don't clear PT after process killedPhilip Yang1-0/+4
commit 597eb70f7ff7551ff795cd51754b81aabedab67b upstream. If process is killed. the vm entity is stopped, submit pt update job will trigger the error message "*ERROR* Trying to push to a killed entity", job will not execute. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 10c382ec6c6d1e11975a11962bec21cba6360391) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
42 hoursdrm/amdgpu: Report individual reset errorLijo Lazar1-10/+15
[ Upstream commit 2e97663760e5fb7ee14f399c68e57b894f01e505 ] If reinitialization of one of the GPUs fails after reset, it logs failure on all subsequent GPUs eventhough they have resumed successfully. A sample log where only device at 0000:95:00.0 had a failure - amdgpu 0000:15:00.0: amdgpu: GPU reset(19) succeeded! amdgpu 0000:65:00.0: amdgpu: GPU reset(19) succeeded! amdgpu 0000:75:00.0: amdgpu: GPU reset(19) succeeded! amdgpu 0000:85:00.0: amdgpu: GPU reset(19) succeeded! amdgpu 0000:95:00.0: amdgpu: GPU reset(19) failed amdgpu 0000:e5:00.0: amdgpu: GPU reset(19) failed amdgpu 0000:f5:00.0: amdgpu: GPU reset(19) failed amdgpu 0000:05:00.0: amdgpu: GPU reset(19) failed amdgpu 0000:15:00.0: amdgpu: GPU reset end with ret = -5 To avoid confusion, report the error for each device separately and return the first error as the overall result. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Fix fence signaling race condition in userqueueJesse.Zhang1-1/+1
[ Upstream commit b8ae2640f9acd4f411c9227d2493755d03fe440a ] This commit fixes a potential race condition in the userqueue fence signaling mechanism by replacing dma_fence_is_signaled_locked() with dma_fence_is_signaled(). The issue occurred because: 1. dma_fence_is_signaled_locked() should only be used when holding the fence's individual lock, not just the fence list lock 2. Using the locked variant without the proper fence lock could lead to double-signaling scenarios: - Hardware completion signals the fence - Software path also tries to signal the same fence By using dma_fence_is_signaled() instead, we properly handle the locking hierarchy and avoid the race condition while still maintaining the necessary synchronization through the fence_list_lock. v2: drop the comment (Christian) Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Add fallback to pipe reset if KCQ ring reset failsJesse.Zhang1-0/+12
[ Upstream commit 7469567d882374dcac3fdb8b300e0f28cf875a75 ] Add a fallback mechanism to attempt pipe reset when KCQ reset fails to recover the ring. After performing the KCQ reset and queue remapping, test the ring functionality. If the ring test fails, initiate a pipe reset as an additional recovery step. v2: fix the typo (Lijo) v3: try pipeline reset when kiq mapping fails (Lijo) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu/atom: Check kcalloc() for WS buffer in ↵Guangshuo Li1-0/+4
amdgpu_atom_execute_table_locked() [ Upstream commit cc9a8e238e42c1f43b98c097995137d644b69245 ] kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference. Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: reject gang submissions under SRIOVChristian König1-1/+1
[ Upstream commit d7ddcf921e7d0d8ebe82e89635bc9dc26ba9540d ] Gang submission means that the kernel driver guarantees that multiple submissions are executed on the HW at the same time on different engines. Background is that those submissions then depend on each other and each can't finish stand alone. SRIOV now uses world switch to preempt submissions on the engines to allow sharing the HW resources between multiple VFs. The problem is now that the SRIOV world switch can't know about such inter dependencies and will cause a timeout if it waits for a partially running gang submission. To conclude SRIOV and gang submissions are fundamentally incompatible at the moment. For now just disable them. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amd: Avoid evicting resources at S5Mario Limonciello (AMD)1-0/+4
[ Upstream commit 531df041f2a5296174abd8292d298eb62fe1ea97 ] Normally resources are evicted on dGPUs at suspend or hibernate and on APUs at hibernate. These steps are unnecessary when using the S4 callbacks to put the system into S5. Cc: AceLan Kao <acelan.kao@canonical.com> Cc: Kai-Heng Feng <kaihengf@nvidia.com> Cc: Mark Pearson <mpearson-lenovo@squebb.ca> Cc: Denis Benato <benato.denis96@gmail.com> Cc: Merthan Karakaş <m3rthn.k@gmail.com> Tested-by: Eric Naim <dnaim@cachyos.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Release hive reference properlyLijo Lazar2-4/+7
[ Upstream commit c1456fadce0c99175f97e66c2b982dd051e01aa2 ] xgmi hive reference is taken on function entry, but not released correctly for all paths. Use __free() to release reference properly. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ce Sun <cesun102@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: validate userq buffer virtual address and sizePrike Liang3-0/+58
[ Upstream commit 9e46b8bb0539d7bc9a9e7b3072fa4f6082490392 ] It needs to validate the userq object virtual address to determine whether it is residented in a valid vm mapping. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctlTvrtko Ursulin1-14/+5
[ Upstream commit dea75df7afe14d6217576dbc28cc3ec1d1f712fb ] Replace kmalloc_array() + copy_from_user() with memdup_array_user(). This shrinks the source code and improves separation between the kernel and userspace slabs. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: validate userq input argsPrike Liang2-32/+56
[ Upstream commit 219be4711a1ba788bc2a9fafc117139d133e5fea ] This will help on validating the userq input args, and rejecting for the invalid userq request at the IOCTLs first place. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: add support for cyan skillfish gpu_infoAlex Deucher1-0/+4
[ Upstream commit fa819e3a7c1ee994ce014cc5a991c7fd91bc00f1 ] Some SOCs which are part of the cyan skillfish family rely on an explicit firmware for IP discovery. Add support for the gpu_info firmware. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: don't enable SMU on cyan skillfishAlex Deucher1-1/+4
[ Upstream commit 94bd7bf2c920998b4c756bc8a54fd3dbdf7e4360 ] Cyan skillfish uses different SMU firmware. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amd: add more cyan skillfish PCI idsAlex Deucher1-0/+5
[ Upstream commit 1e18746381793bef7c715fc5ec5611a422a75c4c ] Add additional PCI IDs to the cyan skillfish family. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Correct info field of bad page threshold exceed CPERXiang Liu1-1/+3
[ Upstream commit f320ed01cf5f2259e2035a56900952cb3cc77e7a ] Correct valid_bits and ms_chk_bits of section info field for bad page threshold exceed CPER to match OOB's behavior. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)Timur Kristóf1-13/+44
[ Upstream commit 585b2f685c56c5095cc22c7202bf74d8e9a73cdd ] Update the legacy (non-DC) display code to respect the maximum pixel clock for HDMI and DVI-D. Reject modes that would require a higher pixel clock than can be supported. Also update the maximum supported HDMI clock value depending on the ASIC type. For reference, see the DC code: check max_hdmi_pixel_clock in dce*_resource.c v2: Fix maximum clocks for DVI-D and DVI/HDMI adapters. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Avoid vcn v5.0.1 poison irq call trace on sriov guestMangesh Gadre1-1/+1
[ Upstream commit 37551277dfed796b6749e4fa52bdb62403cfdb42 ] Sriov guest side doesn't init ras feature hence the poison irq shouldn't be put during hw fini Signed-off-by: Mangesh Gadre <Mangesh.Gadre@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Avoid jpeg v5.0.1 poison irq call trace on sriov guestMangesh Gadre1-1/+1
[ Upstream commit 01152c30eef972c5ca3b3eeb14f2984fa48d18c2 ] Sriov guest side doesn't init ras feature hence the poison irq shouldn't be put during hw fini Signed-off-by: Mangesh Gadre <Mangesh.Gadre@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Notify pmfw bad page threshold exceededXiang Liu1-2/+3
[ Upstream commit c8d6e90abe50377110f92702fbebc6efdd22391d ] Notify pmfw when bad page threshold is exceeded, no matter the module parameter 'bad_page_threshold' is set or not. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu/vpe: cancel delayed work in hw_finiAlex Deucher1-4/+2
[ Upstream commit ec813f384b1a9df332e86ff46c422e5d2d00217f ] We need to cancel any outstanding work at both suspend and driver teardown. Move the cancel to hw_fini which gets called in both cases. Reviewed-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Correct the counts of nr_banks and nr_errorsCe Sun1-0/+2
[ Upstream commit 907813e5d7cadfeafab12467d748705a5309efb0 ] Correct the counts of nr_banks and nr_errors Signed-off-by: Ce Sun <cesun102@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Correct the loss of aca bank reg infoCe Sun4-32/+29
[ Upstream commit d8442bcad0764c5613e9f8b2356f3e0a48327e20 ] By polling, poll ACA bank count to ensure that valid ACA bank reg info can be obtained v2: add corresponding delay before send msg to SMU to query mca bank info (Stanley) v3: the loop cannot exit. (Thomas) v4: remove amdgpu_aca_clear_bank_count. (Kevin) v5: continuously inject ce. If a creation interruption occurs at this time, bank reg info will be lost. (Thomas) v5: each cycle is delayed by 100ms. (Tao) Signed-off-by: Ce Sun <cesun102@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: refactor bad_page_work for corner case handlingChenglei Xie4-13/+58
[ Upstream commit d2fa0ec6e0aea6ffbd41939d0c7671db16991ca4 ] When a poison is consumed on the guest before the guest receives the host's poison creation msg, a corner case may occur to have poison_handler complete processing earlier than it should to cause the guest to hang waiting for the req_bad_pages reply during a VF FLR, resulting in the VM becoming inaccessible in stress tests. To fix this issue, this patch refactored the mailbox sequence by seperating the bad_page_work into two parts req_bad_pages_work and handle_bad_pages_work. Old sequence: 1.Stop data exchange work 2.Guest sends MB_REQ_RAS_BAD_PAGES to host and keep polling for IDH_RAS_BAD_PAGES_READY 3.If the IDH_RAS_BAD_PAGES_READY arrives within timeout limit, re-init the data exchange region for updated bad page info else timeout with error message New sequence: req_bad_pages_work: 1.Stop data exhange work 2.Guest sends MB_REQ_RAS_BAD_PAGES to host Once Guest receives IDH_RAS_BAD_PAGES_READY event handle_bad_pages_work: 3.re-init the data exchange region for updated bad page info Signed-off-by: Chenglei Xie <Chenglei.Xie@amd.com> Reviewed-by: Shravan Kumar Gande <Shravankumar.Gande@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: fix nullptr err of vm_handle_movedHeng Zhou1-1/+14
[ Upstream commit 859958a7faefe5b7742b7b8cdbc170713d4bf158 ] If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved. Signed-off-by: Heng Zhou <Heng.Zhou@amd.com> Reviewed-by: Kasiviswanathan, Harish <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: add to custom amdgpu_drm_release drm_dev_enter/exitVitaly Prosyak1-1/+4
[ Upstream commit c31f486bc8dd6f481adcb9cca4a6e1837b8cf127 ] User queues are disabled before GEM objects are released (protecting against user app crashes). No races with PCI hot-unplug (because drm_dev_enter prevents cleanup if iewdevice is being removed). Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu/jpeg: Hold pg_lock before jpeg poweroffSathishkumar S1-2/+4
[ Upstream commit 0e7581eda8c76d1ca4cf519631a4d4eb9f82b94c ] Acquire jpeg_pg_lock before changes to jpeg power state and release it after power off from idle work handler. Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: skip mgpu fan boost for multi-vfYunxiang Li1-1/+1
[ Upstream commit ba5e322b2617157edb757055252a33587b6729e0 ] On multi-vf setup if the VM have two vf assigned, perhaps from two different gpus, mgpu fan boost will fail. Signed-off-by: Yunxiang Li <Yunxiang.Li@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>
42 hoursdrm/amdgpu: Initialize jpeg v5_0_1 ras functionMangesh Gadre1-0/+8
[ Upstream commit 01fa9758c8498d8930df56eca36c88ba3e9493d4 ] Initialize jpeg v5_0_1 ras function Signed-off-by: Mangesh Gadre <Mangesh.Gadre@amd.com> Reviewed-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Skip poison aca bank from UE channelXiang Liu1-21/+30
[ Upstream commit 8e8e08c831f088ed581444c58a635c49ea1222ab ] Avoid GFX poison consumption errors logged when fatal error occurs. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Fix vcn v5.0.1 poison irq call traceStanley.Yang2-5/+12
[ Upstream commit b1b29aa88f5367d0367c8eeef643635bc6009a9a ] Why: [13014.890792] Call Trace: [13014.890793] <TASK> [13014.890795] ? show_trace_log_lvl+0x1d6/0x2ea [13014.890799] ? show_trace_log_lvl+0x1d6/0x2ea [13014.890800] ? vcn_v5_0_1_hw_fini+0xe9/0x110 [amdgpu] [13014.890872] ? show_regs.part.0+0x23/0x29 [13014.890873] ? show_regs.cold+0x8/0xd [13014.890874] ? amdgpu_irq_put+0xc6/0xe0 [amdgpu] [13014.890934] ? __warn+0x8c/0x100 [13014.890936] ? amdgpu_irq_put+0xc6/0xe0 [amdgpu] [13014.890995] ? report_bug+0xa4/0xd0 [13014.890999] ? handle_bug+0x39/0x90 [13014.891001] ? exc_invalid_op+0x19/0x70 [13014.891003] ? asm_exc_invalid_op+0x1b/0x20 [13014.891005] ? amdgpu_irq_put+0xc6/0xe0 [amdgpu] [13014.891065] ? amdgpu_irq_put+0x63/0xe0 [amdgpu] [13014.891124] vcn_v5_0_1_hw_fini+0xe9/0x110 [amdgpu] [13014.891189] amdgpu_ip_block_hw_fini+0x3b/0x78 [amdgpu] [13014.891309] amdgpu_device_fini_hw+0x3c1/0x479 [amdgpu] How: Add omitted vcn poison irq get call. Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amd/amdgpu: Release xcp drm memory after unplugMeng Li1-0/+1
[ Upstream commit e6c2b0f23221ed43c4cc6f636e9ab7862954d562 ] Add a new API amdgpu_xcp_drm_dev_free(). After unplug xcp device, need to release xcp drm memory etc. Co-developed-by: Jiang Liu <gerry@linux.alibaba.com> Signed-off-by: Jiang Liu <gerry@linux.alibaba.com> Signed-off-by: Meng Li <li.meng@amd.com> Acked-by: Alex Deucher <alexander.deucher@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>
42 hoursdrm/amdgpu: Effective health check before resetCe Sun1-18/+8
[ Upstream commit da467352296f8e50c7ab7057ead44a1df1c81496 ] Move amdgpu_device_health_check into amdgpu_device_gpu_recover to ensure that if the device is present can be checked before reset The reason is: 1.During the dpc event, the device where the dpc event occurs is not present on the bus 2.When both dpc event and ATHUB event occur simultaneously,the dpc thread holds the reset domain lock when detecting error,and the gpu recover thread acquires the hive lock.The device is simultaneously in the states of amdgpu_ras_in_recovery and occurs_dpc,so gpu recover thread will not go to amdgpu_device_health_check.It waits for the reset domain lock held by the dpc thread, but dpc thread has not released the reset domain lock.In the dpc callback slot_reset,to obtain the hive lock, the hive lock is held by the gpu recover thread at this time.So a deadlock occurred Signed-off-by: Ce Sun <cesun102@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Avoid rma causes GPU duplicate resetCe Sun2-7/+11
[ Upstream commit 21c0ffa612c98bcc6dab5bd9d977a18d565ee28e ] Try to ensure poison creation handle is completed in time to set device rma value. Signed-off-by: Ce Sun <cesun102@amd.com> Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Update IPID value for bad page threshold CPERXiang Liu1-2/+6
[ Upstream commit 8f0245ee95c5ba65a2fe03f60386868353c6a3a0 ] Update the IPID register value for bad page threshold CPER according to the latest definition. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Fix build error when CONFIG_SUSPEND is disabledPerry Yuan1-0/+4
[ Upstream commit 8e3967a71e6fca9c871f98b9289b59c82b88b729 ] The variable `pm_suspend_target_state` is conditionally defined only when `CONFIG_SUSPEND` is enabled (see `include/linux/suspend.h`). Directly referencing it without guarding by `#ifdef CONFIG_SUSPEND` causes build failures when suspend functionality is disabled (e.g., `CONFIG_SUSPEND=n`). Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: Check vcn sram load return valueSathishkumar S8-18/+63
[ Upstream commit faab5ea0836733ef1c8e83cf6b05690a5c9066be ] Log an error when vcn sram load fails in indirect mode and return the same error value. Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
42 hoursdrm/amdgpu: add range check for RAS bad page addressTao Zhou1-30/+28
[ Upstream commit 2b17c240e8cd9ac61d3c82277fbed27edad7f002 ] Exclude invalid bad pages. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
43 hoursdrm/amd: Check that VPE has reached DPM0 in idle handlerMario Limonciello1-4/+30
commit ba10f8d92a2c026b1052b4c0fa2cd7538838c965 upstream. [Why] Newer VPE microcode has functionality that will decrease DPM level only when a workload has run for 2 or more seconds. If VPE is turned off before this DPM decrease and the PMFW doesn't reset it when power gating VPE, the SOC can get stuck with a higher DPM level. This can happen from amdgpu's ring buffer test because it's a short quick workload for VPE and VPE is turned off after 1s. [How] In idle handler besides checking fences are drained check PMFW version to determine if it will reset DPM when power gating VPE. If PMFW will not do this, then check VPE DPM level. If it is not DPM0 reschedule delayed work again until it is. v2: squash in return fix (Alex) Cc: Peyton.Lee@amd.com Reported-by: Sultan Alsawaf <sultan@kerneltoast.com> Reviewed-by: Sultan Alsawaf <sultan@kerneltoast.com> Tested-by: Sultan Alsawaf <sultan@kerneltoast.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4615 Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3ac635367eb589bee8edcc722f812a89970e14b7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
43 hoursdrm/amdgpu: fix SPDX headers on amdgpu_cper.c/hAlex Deucher2-2/+2
[ Upstream commit f3b37ebf2c94e3a3d7bbf5e3788ad86cf30fc7be ] These should be MIT. The driver in general is MIT and the license text at the top of the files is MIT so fix it. Fixes: 92d5d2a09de1 ("drm/amdgpu: Introduce funcs for populating CPER") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4654 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit abd3f876404cafb107cb34bacb74706bfee11cbe) Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-23drm/amdgpu: set an error on all fences from a bad contextAlex Deucher3-6/+37
[ Upstream commit ff780f4f80323148d43198f2052c14160c8428d3 ] When we backup ring contents to reemit after a queue reset, we don't backup ring contents from the bad context. When we signal the fences, we should set an error on those fences as well. v2: misc cleanups v3: add locking for fence error, fix comment (Christian) v4: fix wrap around, locking (Christian) Fixes: 77cc0da39c7c ("drm/amdgpu: track ring state associated with a fence") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-23drm/amdgpu: handle wrap around in reemit handlingAlex Deucher1-5/+10
[ Upstream commit 1f22fcb88bfef26a966e9eb242c692c6bf253d47 ] Compare the sequence numbers directly. Fixes: 77cc0da39c7c ("drm/amdgpu: track ring state associated with a fence") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-23drm/amdgpu: fix handling of harvesting for ip_discovery firmwareAlex Deucher1-1/+17
[ Upstream commit 357d90be2c7aaa526a840cddffd2b8d676fe75a6 ] Chips which use the IP discovery firmware loaded by the driver reported incorrect harvesting information in the ip discovery table in sysfs because the driver only uses the ip discovery firmware for populating sysfs and not for direct parsing for the driver itself as such, the fields that are used to print the harvesting info in sysfs report incorrect data for some IPs. Populate the relevant fields for this case as well. Fixes: 514678da56da ("drm/amdgpu/discovery: fix fw based ip discovery") Acked-by: Tom St Denis <tom.stdenis@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>
2025-10-23drm/amdgpu: add support for cyan skillfish without IP discoveryAlex Deucher1-0/+30
[ Upstream commit 9e6a5cf1a23bf575e93544ae05585659063b1c18 ] For platforms without an IP discovery table. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: 357d90be2c7a ("drm/amdgpu: fix handling of harvesting for ip_discovery firmware") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-23drm/amdgpu: add ip offset support for cyan skillfishAlex Deucher3-1/+59
[ Upstream commit e8529dbc75cab56fc3c57830d0fd48cbd8911e6c ] For chips that don't have IP discovery tables. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: 357d90be2c7a ("drm/amdgpu: fix handling of harvesting for ip_discovery firmware") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-23drm/amd: Fix hybrid sleepMario Limonciello (AMD)1-1/+1
[ Upstream commit 0a6e9e098fcc318fec0f45a05a5c4743a81a60d9 ] [Why] commit 530694f54dd5e ("drm/amdgpu: do not resume device in thaw for normal hibernation") optimized the flow for systems that are going into S4 where the power would be turned off. Basically the thaw() callback wouldn't resume the device if the hibernation image was successfully created since the system would be powered off. This however isn't the correct flow for a system entering into s0i3 after the hibernation image is created. Some of the amdgpu callbacks have different behavior depending upon the intended state of the suspend. [How] Use pm_hibernation_mode_is_suspend() as an input to decide whether to run resume during thaw() callback. Reported-by: Ionut Nechita <ionut_n2001@yahoo.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4573 Tested-by: Ionut Nechita <ionut_n2001@yahoo.com> Fixes: 530694f54dd5e ("drm/amdgpu: do not resume device in thaw for normal hibernation") Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Kenneth Crudup <kenny@panix.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Cc: 6.17+ <stable@vger.kernel.org> # 6.17+: 495c8d35035e: PM: hibernate: Add pm_hibernation_mode_is_suspend() Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-23drm/amd: Check whether secure display TA loaded successfullyMario Limonciello1-1/+1
commit c760bcda83571e07b72c10d9da175db5051ed971 upstream. [Why] Not all renoir hardware supports secure display. If the TA is present but the feature isn't supported it will fail to load or send commands. This shows ERR messages to the user that make it seems like there is a problem. [How] Check the resp_status of the context to see if there was an error before trying to send any secure display commands. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1415 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Adrian Yip <adrian.ytw@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-23drm/amdgpu: fix gfx12 mes packet status return checkJonathan Kim1-1/+6
commit d0de79f66a80eeb849033fae34bd07a69ce72235 upstream. GFX12 MES uses low 32 bits of status return for success (1 or 0) and high bits for debug information if low bits are 0. GFX11 MES doesn't do this so checking full 64-bit status return for 1 or 0 is still valid. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-11-15 15:06:54 +0000