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

From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: christian.koenig@amd.com, amd-gfx@lists.freedesktop.org,
	Darren Salt <devspam@moreofthesa.me.uk>
Subject: Re: [PATCH] amdgpu: resize BAR0 to the maximum available size, even if it doesn't cover VRAM
Date: Thu, 10 Dec 2020 21:41:51 +0100	[thread overview]
Message-ID: <9d3cee7f-366e-4e7e-9f63-b0a51af7436c@gmail.com> (raw)
In-Reply-To: <58E21FF244%devspam@moreofthesa.me.uk>

[-- Attachment #1.1: Type: text/plain, Size: 2378 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4414 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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