[PATCH] amdgpu: resize BAR0 to the maximum available size, even if it doesn't cover VRAM

[Christian König]

Am 10.12.20 um 14:59 schrieb Darren Salt:
> I demand that Christian König may or may not have written...
>
>> Am 10.12.20 um 01:57 schrieb Darren Salt:
>>> This allows BAR0 resizing to be done for cards which don't advertise
>>> support for a size large enough to cover the VRAM but which do advertise
>>> at least one size larger than the default. For example, my RX 5600 XT,
>>> which advertises 256MB, 512MB and 1GB.
>> I've never seen such a configuration except for engineering samples. Can
>> you send me a dump of the relevant PCI configuration space?
> “lspci -nn -v -xxxx” output is attached. (Sapphire RX 5600 XT Pulse; not an
> early one.)

Thanks. Going to double check tomorrow.

>
> My current kernel has another patch, applied on top of this patch, which
> allows ignoring the size list. As such, that BAR is currently 8GB instead of
> the 1GB which it should be. I've not noticed any significant problems as yet.

Please grab umr, take a look at the amdgpu_vram_mm debugfs file and see 
if you can get some bytes from a buffer at the end of VRAM.

If that doesn't return 0x0 or 0xffffffff then it is probably working 
quite fine.

> If the card should be advertising larger sizes too then its VBIOS needs
> fixing; but as a lot of these already out there won't get that fix, some sort
> of override (quirk, I expect, with a module option for cards not covered)
> would, I think, be warranted.

I'm really wondering what the heck is going on here. I've heard from 
boards which don't have resizeable BARs, but that there should be an 
artificial 1GB limit sounds strongly like a VBIOS bug to me.

Anyway I agree that a PCI subsystem quirk might be appropriated.

>> In general we could do this, but instead of just blindly trying
>> different values we should just pick a supported one in the first place.
> By using pci_rebar_get_possible_sizes() etc.? That looks reasonable to me.

Yes, exactly.

> It'll also require some patching in the PCI subsystem to expose relevant
> functions.

Just send that to me as a complete and clean patchset.

I'm the one who added the code in the first place and I have no problem 
arguing with Bjorn why we need that in a driver now.

Thanks,
Christian.

>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20201210/125e879b/attachment.htm>