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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
