[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer
ard.biesheuvel at linaro.org
Tue Mar 28 14:39:48 PDT 2017
On 28 March 2017 at 22:27, Sinan Kaya <okaya at codeaurora.org> wrote:
> Hi Lorenzo,
> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>> (or the legacy PCI bios) performed the resource assignment already.
>>> One could argue that this is equally the case when running arm64 in
>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>> on ARM/arm64 that has already taken care of this, and so the state of
>>> the BARs has to be presumed invalid.
>> The story is a bit more convoluted than that owing to x86 (and other
>> arches) legacy.
>> x86 tries to claim all PCI resources (in two passes - first enabled
>> devices, second disabled devices) and that predates ACPI/UEFI.
>> Mind, x86 reassign resources that can't be claimed too, the only
>> difference with ARM64 is that, for the better or the worse, we
>> have decided not to claim the FW PCI set-up on ARM64 even if it
>> is sane, we do not even try, it was a deliberate choice.
>> This patch should be harmless on x86 since if the FB PCI BAR is set
>> up sanely, claiming it again should be a nop (to be checked).
>> For all the talk about PCI being arch agnostic as I said manifold
>> times before, that's just theory. In practice different arches
>> treat PCI FW set-up differently, it would be ideal to make them
>> uniform but legacy is huge and there is a massive risk of triggering
>> regressions, it is no mean feat (if achievable at all).
> Can we explore having a uniform behavior across ALL ACPI bases systems
> by trying to reuse the resources assigned by firmware first and reassign
> them only if something is wrong?
> There are protocols like hotplug reservation in UEFI. It looks like Linux
> is not honoring any of these protocols by being too smart.
Could you be more specific? Which protocol do you mean exactly, and
how does not reusing resources interfere with it?
More information about the linux-arm-kernel