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. Bjorn _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
