[PATCH 3/7] amdgpu: resize BAR0 to the maximum available size, even if it doesn't cover VRAM (v2)

[Christian König]

Am 14.12.20 um 16:46 schrieb Darren Salt:
> I demand that Christian König may or may not have written...
>
>> Am 11.12.20 um 18:31 schrieb Darren Salt:
>> < [SNIP]
>>>> If that isn't the case use fls() to get the highest set bit < 13.
>>> That suggests that it'll be easiest to clear each bit after the
>>> corresponding size is checked, I think.
>> Ok, well you don't seem to understand my constrain here: Never check
>> more than one size!
> Checking context: it appeared to be the for() statement itself rather than
> the whole loop. It didn't help that “try and error” looks like “try to error”
> to me; I now think that you meant “trial and error”.

I'm not a native speaker of English, so bear with me if I get such stuff 
wrong.

>> Find the first valid size which is good for you and then try to resize
>> to that one, if this doesn't work abort.
> So, basically, stop even when the next size down would be fine, e.g. 16GB →
> 8GB. Just as well that size limiting is done in a later patch, though I
> wonder whether that should allow per-GPU configuration (not something for
> this patch series, though).

Yes, just try the whole dance with exactly one size and not multiple times.

>
>>> Also, this looks like it's adding complexity to try to make
>>> rarely-executed code slightly faster in some cases (I can't see it
>>> helping where available_sizes == 0x3F00, for example).
>> The intention here is not to make the code faster, but to prevent issues on
>> system where we probe multiple GPUs at once.
> Presumably simultaneous probes and random ordering…

Exactly.

Good news is that I think I've figured out why that happens and our 
hardware/VBIOS engineers are investigating now what's the best approach 
to make thinks work as it should :)

We most likely will end up with a static quirk for this 
PCI-ID/revision/board/manufacturer.

Regards,
Christian.