Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation
From: Alexander Graf
Date: Thu Apr 28 2016 - 12:41:50 EST
On 04/28/2016 06:20 PM, Bjorn Helgaas wrote:
On Thu, Apr 28, 2016 at 12:22:24AM +0200, Alexander Graf wrote:
When booting with efifb, we get a frame buffer address passed into the system.
This address can be backed by any device, including PCI devices.
I guess we get the frame buffer address via EFI, but it doesn't tell
us what PCI device it's connected to?
Pretty much, yes. We can get the frame buffer address from a multitude
of sources using various boot protocols, but the case where I ran into
this was with efi on arm64.
This same thing could happen on any EFI arch, I guess. Maybe even on
Yes and no :). I would've put it into whatever code "owns" screen_info,
but I couldn't find any. So instead I figured I'd make the approach as
generic as I could and implemented the calculation for the case where I
saw it break.
The reason we don't see this on x86 (if I understand all pieces of the
puzzle correctly) is that we get the BAR allocation from firmware using
_CRS attributes in ACPI, so firmware tells the OS where to put the BARs.
In the device tree case (which is what I'm running on arm64) we however
allocate BARs dynamically.
non-EFI arches, if there's a way to discover the frame buffer address
as a bare address rather than a "offset X into BAR Y of PCI device Z"
sort of thing.
It'd be perfectly doable today - we do get a cpu physical address and
use that in the notifier. All we would need to do is move the code that
I added in arm64/efi.c to something more generic that "owns" the frame
buffer address. Then any boot protocol that passes a screen_info in
would get the frame buffer relocated on BAR remap. Drivers like vesafb
might benefit from this as well - though apparently x86 fixed this using
ACPI.
I'm not sure if offb could potentially also break. At the end of the
day, it might, depending on how it's backed. For that we would then need
another callback, since it doesn't use screen_info.
I don't feel incredibly comfortable preemptively fixing issues people
haven't seen yet. There's just a good chance we end up breaking more
than we fix :). But if you like and can point me to a better place for
the screen_info modification, I'm happy to move it there.
Alex