Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80 2025-07-06T09:01:47+00:00 2025-07-06T09:01:47+00:00 Alex Deucher alexander.deucher@amd.com 2025-06-02T15:31:52+00:00 urn:sha1:5f2e040f19c4d73496ac8c32f2c441a6146430c9 commit ebe43542702c3d15d1a1d95e8e13b1b54076f05a upstream. Use the amdgpu fence container so we can store additional data in the fence. This also fixes the start_time handling for MCBP since we were casting the fence to an amdgpu_fence and it wasn't. Fixes: 3f4c175d62d8 ("drm/amdgpu: MCBP based on DRM scheduler (v9)") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bf1cd14f9e2e1fdf981eed273ddd595863f5288c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2024-06-14T20:17:13+00:00 Christian König christian.koenig@amd.com 2024-06-05T11:27:20+00:00 urn:sha1:030631e97b209481edbac38000d2a60fd340f6b1 This reverts commit b8c415e3bf98 ("drm/amdgpu: take runtime pm reference when we attach a buffer") and commit 425285d39afd ("drm/amdgpu: add amdgpu runpm usage trace for separate funcs"). Taking a runtime pm reference for DMA-buf is actually completely unnecessary and even dangerous. The problem is that calling pm_runtime_get_sync() from the DMA-buf callbacks is illegal because we have the reservation locked here which is also taken during resume. So this would deadlock. When the buffer is in GTT it is still accessible even when the GPU is powered down and when it is in VRAM the buffer gets migrated to GTT before powering down. The only use case which would make it mandatory to keep the runtime pm reference would be if we pin the buffer into VRAM, and that's not something we currently do. v2: improve the commit message 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> CC: stable@vger.kernel.org 2024-06-14T20:17:12+00:00 Lijo Lazar lijo.lazar@amd.com 2024-05-31T12:28:54+00:00 urn:sha1:3a86fdc422c926eab7d42a8194eaacf05e1d699e Skip scheduling coredump when gpu reset is intentionally triggered through debugfs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2024-06-14T20:15:58+00:00 Eric Huang jinhuieric.huang@amd.com 2024-06-04T15:46:56+00:00 urn:sha1:bac640ddb51e8066d1f35ed810e7a4c6dd341d39 To fullfill the reset event description. Suggested-by: Lijo Lazar <Lijo.Lazar@amd.com> Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2024-02-22T15:28:19+00:00 Kunwu Chan chentao@kylinos.cn 2024-02-21T09:59:05+00:00 urn:sha1:3d14cb026323f47dded416178c1cfa6125eae7d4 Use the new KMEM_CACHE() macro instead of direct kmem_cache_create to simplify the creation of SLAB caches. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2023-11-17T14:30:51+00:00 Prike Liang Prike.Liang@amd.com 2023-11-09T03:37:18+00:00 urn:sha1:425285d39afddaf4a9dab36045b816af0cc3e400 Add trace for amdgpu runpm separate funcs usage and this will help debugging on the case of runpm usage missed to dereference. In the normal case the runpm usage count referred by one kind of functionality pairwise and usage should be changed from 1 to 0, otherwise there will be an issue in the amdgpu runpm usage dereference. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2023-09-20T16:23:28+00:00 Lijo Lazar lijo.lazar@amd.com 2023-09-11T08:18:11+00:00 urn:sha1:4e8303cf2c4dd27374a16a8881ec1a1cd5baf86f Use an inline function for version check. Gives more flexibility to handle any format changes. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2023-08-16T15:34:57+00:00 Tim Huang Tim.Huang@amd.com 2023-08-14T07:13:04+00:00 urn:sha1:603b9a575d571557cf2de0d745d88b7c59b35be7 GFX v11.0.1 reported fence fallback timer expired issue on SDMA and GFX rings after S0ix resume. This is generated by EOP interrupts are disabled when S0ix suspend but fails to re-enable when resume because of the GFX is in GFXOFF. [ 203.349571] [drm] Fence fallback timer expired on ring sdma0 [ 203.349572] [drm] Fence fallback timer expired on ring gfx_0.0.0 [ 203.861635] [drm] Fence fallback timer expired on ring gfx_0.0.0 For S0ix, GFX is in GFXOFF state, avoid to touch the GFX registers to configure the fence driver interrupts for rings that belong to GFX. The interrupts configuration will be restored by GFXOFF exit. Signed-off-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2023-06-15T15:37:55+00:00 Christian König christian.koenig@amd.com 2023-04-17T10:52:18+00:00 urn:sha1:0a33b11d26c6b7e975b54d469a739ffac29f67ab When we force complete fences we should mark them as canceled. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 2023-06-15T15:37:54+00:00 Christian König christian.koenig@amd.com 2023-04-19T10:51:41+00:00 urn:sha1:b13eb02ba8ba7617d41212121891756da31f1d8b This allows us to insert some error codes into the bottom of the pipeline on an engine. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>