Thread (39 messages) 39 messages, 7 authors, 2017-05-20
STALE3320d

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

From: Sinan Kaya <hidden>
Date: 2017-03-22 19:49:21
Also in: linux-efi, linux-pci

On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
quoted
As far as I know, kernel honors resource assignments done by the UEFI BIOS if
they are correct. Kernel will reassign the resources only if something is wrong.
No, the kernel always reassigns all BARs on arm64.
I think this is where the problem is.

I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
combination only. 

I see that kernel honored the resources assigned by UEFI BIOS if I compare
the BAR addresses.

I see reassignment only when something is horribly broken. Then, there would
be a bridge configuration invalid message in the boot log to confirm this.
quoted
Will this code break other platforms/architectures?
Which platforms/architectures are you referring to? EFIFB on a PCI
device is currently broken on arm64. 
In general or on your particular platform?
On x86, it works, given that BARs
are usually not reassigned, and so the patch should be a no-op in that
case (although I'd argue it is still an improvement to check whether
the device that owns the BAR actually has memory decoding enabled
before we attach the framebuffer driver to it)
I'm fine as long as it doesn't break anything. That's why, I'm asking.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help