On 6/2/25 6:00 AM, Christian König wrote: > Hi John, > > first of all thanks a lot for taking a look into this. > >>> Okay, I did a read and compare after each write. >>> >>> Both writes seem to go through on both the Kaveri and s9150: >>> >>> Kaveri (512MB UMA Buffer): >>> amdgpu 0000:00:01.0: amdgpu: [drm] uvd_v4_2_mc_resume: mmUVD_LMI_ADDR_EXT: >>> gpu_addr=0xF41FA00000, addr=0x00000001, wrote 0x00001001, read 0x00001001 >>> [same] >>> amdgpu 0000:00:01.0: amdgpu: [drm] uvd_v4_2_mc_resume: >>> mmUVD_LMI_EXT40_ADDR: gpu_addr=0xF41FA00000, addr=0x000000F4, wrote >>> 0x800900F4, read 0x800900F4 [same] >>> >>> s9150: >>> amdgpu 0000:41:00.0: amdgpu: [drm] uvd_v4_2_mc_resume: mmUVD_LMI_ADDR_EXT: >>> gpu_addr=0xF7FFA00000, addr=0x0000000F, wrote 0x0000F00F, read 0x0000F00F >>> [same] >>> amdgpu 0000:41:00.0: amdgpu: [drm] uvd_v4_2_mc_resume: >>> mmUVD_LMI_EXT40_ADDR: gpu_addr=0xF7FFA00000, addr=0x000000F7, wrote >>> 0x800900F7, read 0x800900F7 [same] >>> >> >> I've also confirmed the patch works fine when segments other than >> [0, 256M) are used. >> >> E.g.: Both init and VA-API playback work fine with a UVD segment of >> [1792M, 2048M) on Kaveri with a 2G UMA buffer. > > Oh, that's a very interesting find. Could you try to turn around the way the > patch works? > > E.g. instead of forcing the UVD FW into the first segment, change > amdgpu_uvd_force_into_uvd_segment() so that the BOs are forced into the same > segment as the UVD firmware. > > That would resolve my concern that this could overload the first segment. The > feedback and message BO are usually rather small (4 or 128k IIRC), but the > firmware is a couple of megabytes in size. > > When we have other FW and VGA emulation buffers in the first segment as well > then that could result into clashing that segment to much. > > Thanks, > Christian. >
Okay, yeah, that should make for a significantly simpler fix. >>>>> I will try to find a Kaveri system which is still working to reproduce >>>>> the issue. > > I unfortunately couldn't find a working box of hand. Would need to search in > our HW stash for a box which still works and get that shipped to me. > > And that is overhead for this issue I would rather like to avoid. > > So if you can come up with a simpler patch which works for you I'm happy to > take that. > > Regards, > Christian. Sounds good. I'll get started on this variant. Thanks, John
