Hi Maciej, I tested this patch on a second MacBookPro11,5 (Radeon R9 M370X, Verde, 1002:6821, subsystem 106b:0149). Here the dGPU is a headless PRIME offload GPU and the panel is on i915. The kernel is linux 7.3-rc7, with amdgpu rebuilt from that tree with this patch on top and nothing else changed in amdgpu (amdgpu.si_support=1 radeon.si_support=0, mem_sleep=deep).
Without the patch, VRAM is at 0 after boot and every S3 resume fails with "ring gfx test failed (-110)". With it, amdgpu logs "PCI CONFIG reset" and "GPU posting now..." at load, and VRAM ends up at 0x000000F400000000. I then ran four S3 cycles: two on battery and two on AC, from 9 minutes to 13 h 19 min asleep. After each resume the GART table was still at 0x000000F400000000 and the kernel log showed no ring timeouts, -110 errors or GPU recovery. After the last (overnight) resume, DRI_PRIME=1 glxgears (radeonsi) and vkcube (RADV) ran, and VA-API H.264 encode (VCE) and decode (UVD) both worked through ffmpeg. One thing I noticed: on 2 of the 4 resumes, about a second after resume, vce_v1_0_stop() logged: amdgpu 0000:01:00.0: VCE busy: VCE_STATUS=0x2, SRBM_STATUS2=0x80 VCE encode worked straight afterwards, so it doesn't seem to break anything. I didn't see it in about 11 resumes with a local workaround that kept VRAM at 0, so it may come with the new layout, but I haven't looked further. Mentioning it in case it's known. This supersedes the gmc6 patch I sent on 20 Oct for the same failure: https://lore.kernel.org/amd-gfx/[email protected]/ Tested-by: Brad Drury <[email protected]> # MacBookPro11,5, Radeon R9 M370X Thanks, Brad
