Re: [PATCH] Revert "drm/amd/display: Allocate DCN32/1 dmub memory to GTT"

[Josh Kasten <jkasten@gmail.com>]

I am able to reproduce this issue on kernel 7.3 on the AMD RX 7900 XT GPU.
* XT is not a typo, however both XT & XTX variants are Navi 31 anyway.
Never seen this issue on 7.2.8, 7.2.11, or 6.18.54.

### Conditions to reproduce banding issue
#### 1. When sub-viewport (AKA SubVP) is enabled
Check if it is enabled with the following command:
`sudo sh -c 'head -v /sys/kernel/debug/dri/0000:*/amdgpu_dm_capabilities'`

I think the amdgpu driver is in control when SubVP is enabled. In my testing
with a single active display this gets enabled when at 4K and it's frequency
is 100hz to 120 hz, inclusive.
Mikhail Gavrilov gave me this description for additional conditions if SubVP
get enabled:
> On DCN 3.2, SubVP itself is limited to:

> * refresh below 120 Hz; or 120–175 Hz for 3840x2160, 3440x1440, 2560x1440
> and 1920x1080 without scaling, and then, on a single display, only with
> FreeSync off;
> * pixel rate up to 1800 MHz;
> * no overlay planes and no rotation.

#### 2. Memory clock changes
Make sure the video memory clocks are not locked as the banding only happens
when the GPU changes it's memory frequency when the frame is being outputted.

This happens more often if the GPU is mostly idle and you move a window or
resize it in a desktop environment like KDE. I see it as often as a few times
a second, but sometimes it takes up to 10 seconds of doing this.

#### 3. 10x more often if amdgpu overdrive is enabled
While I know AMD overdrive needs to be disabled before reporting a bug enabling
it will allow you to reproduce the bug more often and faster. When 
`amdgpu.ppfeaturemask=0xfffd7fff` is set I see this bug about 10x more often.

### Confirmed revert of a637a140 fully fixes this
I confirm on next-20261023 by reverting a637a140 I am no longer seeing this
issue.

The revert didn't go clean on kernel next-20261023, as there was some changes
on top, so attached is the patch I generated for the revert of commit a637a140.

### Summary

I don't understand the optimization done in commit a637a140, or if there is
another related commit that should also be reverted. However what I can say
is I haven't notice any side effects after running with this revert for a few
days so far. It might be worth considering reverting commit a637a140 in a 7.3.x
patch release until a new fix can be tested in next.

Hoping this gets resolved in a future kernel release soon, the banding gets
to me sometimes and won't want this happing on other AMD GPUs. :(
Let me know if I can help at all with any additional testing or information!

Signed-off-by: Josh Kasten <jkasten@gmail.com>
---
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_dmub.c
@@ -538,7 +538,6 @@ int dm_dmub_sw_init(struct amdgpu_device *adev)
 		DMUB_WINDOW_MEMORY_TYPE_FB,		/* DMUB_WINDOW_CURSOR_OFFLOAD */
 	};
 	int r;
-	int mem_domain = AMDGPU_GEM_DOMAIN_GTT;
 
 	switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) {
 	case IP_VERSION(2, 1, 0):
@@ -675,19 +674,13 @@ int dm_dmub_sw_init(struct amdgpu_device *adev)
 		return -EINVAL;
 	}
 
-	/* Limit to allocate dmub to GTT on DCN32/1
-	 * TODO: Other asics with GDDR7 may have worse latency
-	 */
-	if (dmub_asic != DMUB_ASIC_DCN32 &&
-	    dmub_asic != DMUB_ASIC_DCN321)
-		mem_domain |= AMDGPU_GEM_DOMAIN_VRAM;
-
 	/*
 	 * Allocate a framebuffer based on the total size of all the regions.
 	 * TODO: Move this into GART.
 	 */
 	r = dmub_bo_create_kernel(adev, region_info.fb_size, PAGE_SIZE,
-				  mem_domain,
+				  AMDGPU_GEM_DOMAIN_VRAM |
+				  AMDGPU_GEM_DOMAIN_GTT,
 				  &adev->dm.dmub_bo,
 				  &adev->dm.dmub_bo_gpu_addr,
 				  &adev->dm.dmub_bo_cpu_addr);
---