[RFC PATCH 2/2] drm/amdgpu/uvd: Ensure vcpu bos are within the uvd segment

[John Olender]

>> 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.
>>

I started implementing this and I realized two main problems with this
approach.

First, there's currently no guarantee the UVD FW does not cross a 256MB
boundary.  Checking for this and providing a fallback is going to make
this patch... not really any less complex than the original.

Second, most of time this is just going to end up selecting the first
segment anyway.  I'll go more into this below.

>> 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.
>>

During my initial investigation, I found out that the UVD FW got placed
in the first segment *because* things were already placed there.  This
is why adding a 'stolen_vga_memory' substitute was an effective workaround.

So, CIK is *already* forced to deal with an overloaded first segment
and, with the inverted approach, will continue to do so for typical use
cases.  Explicitly placing the UVD FW into the first segment just makes
this guaranteed.

I did implement a module parameter for testing that allows designating a
specific 256MB segment as the legacy UVD segment.  I can polish this up
so the user has the option to manually relieve some of the first segment
pressure on SI and CIK devices.

I haven't run into a situation where I've needed this during normal use,
but I can certainly appreciate it being available.

Thanks,
John