<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">Am 10.12.20 um 14:59 schrieb Darren Salt: </div> <blockquote type="cite" cite="mid:58E21FF244%25devspam@moreofthesa.me.uk"> <pre class="moz-quote-pre" wrap="">I demand that Christian König may or may not have written... </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Am 10.12.20 um 01:57 schrieb Darren Salt: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap=""> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I've never seen such a configuration except for engineering samples. Can you send me a dump of the relevant PCI configuration space? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> “lspci -nn -v -xxxx” output is attached. (Sapphire RX 5600 XT Pulse; not an early one.)</pre> </blockquote> Thanks. Going to double check tomorrow. <blockquote type="cite" cite="mid:58E21FF244%25devspam@moreofthesa.me.uk"> <pre class="moz-quote-pre" wrap=""> 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.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:58E21FF244%25devspam@moreofthesa.me.uk"> <pre class="moz-quote-pre" wrap="">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.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:58E21FF244%25devspam@moreofthesa.me.uk"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> By using pci_rebar_get_possible_sizes() etc.? That looks reasonable to me.</pre> </blockquote> Yes, exactly. <blockquote type="cite" cite="mid:58E21FF244%25devspam@moreofthesa.me.uk"> <pre class="moz-quote-pre" wrap="">It'll also require some patching in the PCI subsystem to expose relevant functions.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:58E21FF244%25devspam@moreofthesa.me.uk"> <pre class="moz-quote-pre" wrap=""> </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ amd-gfx mailing list <a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a> </pre> </blockquote> </body> </html>