On Wed, Aug 23, 2017 at 02:48:42PM +0100, Ard Biesheuvel wrote: > On 22 August 2017 at 23:19, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote: > >> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote: > >> > A system without PCI legacy resources (e.g. ARM64) may find that no > >> > default/boot VGA device has been marked, because the VGA arbiter > >> > checks for legacy resource decoding before marking a card as default. > >> > >> I do not understand this paragraph, in particular: > >> > >> - "A system without PCI legacy resources (e.g. ARM64)". What does this > >> mean ? I take this as "ARM64 does not support IO space"; if a PCI host > >> bridge supports IO space, there is nothing from an architectural > >> point of view that prevents an MMIO based IO space implementation to > >> work on ARM64. It is PCI bridge specific, not arch specific. > > > > This reference to ARM64 is the same thing I stumbled over. Maybe it > > could be written along the lines of: > > > > The VGA arbiter selects a default VGA device that is enabled and > > reachable via the legacy VGA resources (mem 0xa0000-0xbffff, io > > 0x3b0-0x3bb, io 0x3c0-0x3df, etc). > > > > If there is no such device, e.g., because there's no enabled VGA > > device, the host bridge doesn't support access to those legacy > > resources, or a PCI-PCI bridge doesn't have VGA Enable set, a > > platform may select an arbitrary device by calling > > vga_set_default_device(). > > > > Then I think this patch changes the previous behavior by allowing the > > arbiter to select a device that is enabled and has a driver but may > > not be reachable via the legacy VGA resources. > > > > I don't know what all the consequences of that would be, but it does > > muddy the VGA arbiter waters a bit. AIUI, the main reason for the > > arbiter is to allow multiple legacy VGA devices by manipulating bridge > > VGA Enable bits so only one receives the legacy resources at a time. > > > > These devices that do not need the legacy resources don't need that > > special treatment because they don't care about the bridge VGA Enable > > bits and several can coexist in the system with no need for VGA > > arbitration. > > > > I guess the powerpc fixup_vga() already selects a device that doesn't > > need the VGA resources, so we already have that situation. > > > > Perhaps it is unclear that the whole point of tinkering with the VGA > arbiter is that X may refuse to use a GFX card if it is not tagged as > the default VGA device by the arbiter. I have suggested before that > fixing X may be more appropriate in this case, given that ownership of > the legacy VGA resources may not correlate at all with being the > primary display device on non-x86 architectures. Yeah, maybe it's time to disconnect the "default display device" idea from the VGA arbiter. I have no idea what (if any) dependencies X has on the legacy VGA resources. I assume X works fine on power, where it sounds like those resources are rarely or never available.
