kernel/linux.git/drivers/gpu/drm/amd, branch v6.1.45

drm/amdgpu: Use apt name for FW reserved region

2023-08-11T10:08:27+00:00

commit db3b5cb64a9ca301d14ed027e470834316720e42 upstream Use the generic term fw_reserved_memory for FW reserve region. This region may also hold discovery TMR in addition to other reserve regions. This region size could be larger than discovery tmr size, hence don't change the discovery tmr size based on this. Signed-off-by: Lijo Lazar Reviewed-by: Le Ma Signed-off-by: Alex Deucher [ This change fixes reading IP discovery from debugfs. It needed to be hand modified because: * GC 9.4.3 support isn't introduced in older kernels until 228ce176434b ("drm/amdgpu: Handle VRAM dependencies on GFXIP9.4.3") * It also changed because of 58ab2c08d708 (drm/amdgpu: use VRAM|GTT for a bunch of kernel allocations) not being present. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2748 ] Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Remove unnecessary domain argument

2023-08-11T10:08:27+00:00

commit 3273f11675ef11959d25a56df3279f712bcd41b7 upstream Remove the "domain" argument to amdgpu_bo_create_kernel_at() since this function takes an "offset" argument which is the offset off of VRAM, and as such allocation always takes place in VRAM. Thus, the "domain" argument is unnecessary. Cc: Alex Deucher Cc: Christian König Cc: AMD Graphics Signed-off-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: add vram reservation based on vram_usagebyfirmware_v2_2

2023-08-11T10:08:26+00:00

commit 4864f2ee9ee2acf4a1009b58fbc62f17fa086d4e upstream Move TMR region from top of FB to 2MB for FFBM, so we need to reserve TMR region firstly to make sure TMR can be allocated at 2MB Signed-off-by: Tong Liu01 Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amd/display: skip CLEAR_PAYLOAD_ID_TABLE if device mst_en is 0

2023-08-11T10:08:25+00:00

commit a1c9a1e27022d13c70a14c4faeab6ce293ad043b upstream. [Why] Some dock and mst monitor don't like to receive CLEAR_PAYLOAD_ID_TABLE when mst_en is set to 0. It doesn't make sense to do so in source side, either. [How] Don't send CLEAR_PAYLOAD_ID_TABLE if mst_en is 0 Reviewed-by: George Shen Acked-by: Qingqing Zhuo Signed-off-by: Peichen Huang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher [ 6.1.y doesn't have the file rename from 54618888d1ea7 ("drm/amd/display: break down dc_link.c") ] Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Ensure that planes are in the same order

2023-08-11T10:08:25+00:00

commit bb46a6a9bab134b9d15043ea8fa9d6c276e938b8 upstream. The function dc_update_planes_and_stream handles multiple cases where DC needs to remove and add planes in the commit tail phase. After Linux started to use this function, some of the IGT kms_plane started to fail; one good example to illustrate why the new sequence regressed IGT is the subtest plane-position-hole which has the following diagram as a template: +--------------------+ +-----------------------+ | +-----+ | | +-----+ | | | | | | | +-----+ | | | +--+ | ==> | | | | | | | |__| | | +-|---+ | | | | | +-----+ | | | | | +--------------------+ +-----------------------+ (a) Final image (b) Composed image IGT expects image (a) as the final result of two plane compositions as described in figure (b). After the migration to the new sequence, the last plane order is changed, and DC generates the following image: +---------------------+ | +-----+ | | | | | | | | | | +-----+ | | | +---------------------+ Notice that the generated image by DC is different because the small square that should be composed on top of the primary plane is below the primary plane. For this reason, the CRC will mismatch with the expected value. Since the function dc_add_all_planes_for_stream re-append all the new planes back to the dc_validation_set, this commit ensures that the original sequence is maintained. After this change, all CI tests in all ASICs start to pass again. Reviewed-by: Harry Wentland Acked-by: Qingqing Zhuo Suggested-by: Melissa Wen Signed-off-by: Rodrigo Siqueira Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Write to correct dirty_rect

2023-08-03T08:24:18+00:00

commit 751281c55579f0cb0e56c9797d4663f689909681 upstream. When FB_DAMAGE_CLIPS are provided in a non-MPO scenario, the loop does not use the counter i. This causes the fill_dc_dity_rect() to always fill dirty_rects[0], causing graphical artifacts when a damage clip aware DRM client sends more than 1 damage clip. Instead, use the flip_addrs->dirty_rect_count which is incremented by fill_dc_dirty_rect() on a successful fill. Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2453 Signed-off-by: Benjamin Cheng Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman

drm/amd/display: perform a bounds check before filling dirty rectangles

2023-08-03T08:24:18+00:00

commit af22d6a869cc26b519bfdcd54293c53f2e491870 upstream. Currently, it is possible for us to access memory that we shouldn't. Since, we acquire (possibly dangling) pointers to dirty rectangles before doing a bounds check to make sure we can actually accommodate the number of dirty rectangles userspace has requested to fill. This issue is especially evident if a compositor requests both MPO and damage clips at the same time, in which case I have observed a soft-hang. So, to avoid this issue, perform the bounds check before filling a single dirty rectangle and WARN() about it, if it is ever attempted in fill_dc_dirty_rect(). Cc: stable@vger.kernel.org # 6.1+ Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support") Reviewed-by: Leo Li Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amd/display: set per pipe dppclk to 0 when dpp is off

2023-08-03T08:24:17+00:00

commit 6609141c49df1b86fbad26a8643d4b4044f28b11 upstream. The 'commit 52e4fdf09ebc ("drm/amd/display: use low clocks for no plane configs")' introduced a change that set low clock values for DCN31 and DCN32. As a result of these changes, DC started to spam the log with the following warning: ------------[ cut here ]------------ WARNING: CPU: 8 PID: 1486 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_dccg.c:58 dccg2_update_dpp_dto+0x3f/0xf0 [amdgpu] [..] CPU: 8 PID: 1486 Comm: kms_atomic Tainted: G W 5.18.0+ #1 RIP: 0010:dccg2_update_dpp_dto+0x3f/0xf0 [amdgpu] RSP: 0018:ffffbbd8025334d0 EFLAGS: 00010206 RAX: 00000000000001ee RBX: ffffa02c87dd3de0 RCX: 00000000000a7f80 RDX: 000000000007dec3 RSI: 0000000000000000 RDI: ffffa02c87dd3de0 RBP: ffffbbd8025334e8 R08: 0000000000000001 R09: 0000000000000005 R10: 00000000000331a0 R11: ffffffffc0b03d80 R12: ffffa02ca576d000 R13: ffffa02cd02c0000 R14: 00000000001453bc R15: ffffa02cdc280000 [..] dcn20_update_clocks_update_dpp_dto+0x4e/0xa0 [amdgpu] dcn32_update_clocks+0x5d9/0x650 [amdgpu] dcn20_prepare_bandwidth+0x49/0x100 [amdgpu] dcn30_prepare_bandwidth+0x63/0x80 [amdgpu] dc_commit_state_no_check+0x39d/0x13e0 [amdgpu] dc_commit_streams+0x1f9/0x3b0 [amdgpu] dc_commit_state+0x37/0x120 [amdgpu] amdgpu_dm_atomic_commit_tail+0x5e5/0x2520 [amdgpu] ? _raw_spin_unlock_irqrestore+0x1f/0x40 ? down_trylock+0x2c/0x40 ? vprintk_emit+0x186/0x2c0 ? vprintk_default+0x1d/0x20 ? vprintk+0x4e/0x60 We can easily trigger this issue by using a 4k@120 or a 2k@165 and running some of the kms_atomic tests. This warning is triggered because the per-pipe clock update is not happening; this commit fixes this issue by ensuring that DPPCLK is updated when calculating the watermark and dlg is invoked. Fixes: 2641c7b78081 ("drm/amd/display: use low clocks for no plane configs") Reported-by: Mark Broadworth Reviewed-by: Rodrigo Siqueira Signed-off-by: Dmytro Laktyushkin Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Unlock on error path in dm_handle_mst_sideband_msg_ready_event()

2023-08-03T08:24:06+00:00

[ Upstream commit 38ac4e8385ffb275b1837986ca6c16f26ea028c5 ] This error path needs to unlock the "aconnector->handle_mst_msg_ready" mutex before returning. Fixes: 4f6d9e38c4d2 ("drm/amd/display: Add polling method to handle MST reply packet") Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd: Fix an error handling mistake in psp_sw_init()

2023-08-03T08:24:05+00:00

[ Upstream commit c01aebeef3ce45f696ffa0a1303cea9b34babb45 ] If the second call to amdgpu_bo_create_kernel() fails, the memory allocated from the first call should be cleared. If the third call fails, the memory from the second call should be cleared. Fixes: b95b5391684b ("drm/amdgpu/psp: move PSP memory alloc from hw_init to sw_init") Signed-off-by: Mario Limonciello Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin