[PATCH 0/4] Allow non-legacy cards to be vgaarb default
ard.biesheuvel at linaro.org
Fri Jul 21 19:05:33 AEST 2017
On 21 July 2017 at 00:52, Daniel Axtens <dja at axtens.net> wrote:
> Hi Ard,
>> (+ Laszlo)
>> On 19 July 2017 at 02:28, Daniel Axtens <dja at axtens.net> wrote:
>>> Hi all,
>>> Previously I posted a patch that provided a quirk for a hibmc card
>>> behind a particular Huawei bridge that allowed it to be marked as the
>>> default device in the VGA arbiter. This lead to some discussion.
>>> It was broadly suggested that a more generic solution would be better,
>>> something in the style of powerpc's fixup_vga() quirk.
>>> Here is my suggested solution:
>>> - Create a Kconfig option ARCH_WANT_VGA_ARB_FALLBACK
>>> - if an arch selects that option, install PCI_FIXUP_CLASS_ENABLE
>>> hook. This hook fires when a card is enabled, which will require
>>> that a driver has been bound.
>>> - if there is no default device when the hook fires, and the device
>>> can control memory and I/O, mark it as default.
>>> The patches are as follows:
>>> (1) powerpc: simplify and fix VGA default device behaviour
>>> This cleans up some quirks in the powerpc implementation of the
>>> vga_fixup. It should make the behaviour match the original
>>> (2) vgaarb: allow non-legacy cards to be marked as default
>>> Add the Kconfig option, and create the fixup in vgaarb.c gated
>>> behind the option. Nothing happens at this stage because no arch
>>> has selected the option yet.
>>> (3) powerpc: replace vga_fixup() with generic code
>>> Select the option on powerpc and remove the old code. The only
>>> change is that it moves from being a final fixup to an enable
>>> (4) arm64: allow non-legacy VGA devices to be default
>>> Select the option on arm64. This solves my problem with the D05,
>>> but may cause other cards to be marked as default on other
>>> boards. This shouldn't cause any real issues but is worth being
>>> aware of.
>> Hi Daniel,
>> Given that the whole point of the VGA arbiter is the ability to share
>> the legacy mem+io ranges between different cards, why do we care about
>> the VGA arbiter in the first place on arm64?
>> AFAIK, there have been some recent changes in Xorg to address the
>> auto-detection problem. I don't remember the exact details, but I have
>> added Laszlo, who was involved with this at the time.
> I haven't been able to locate those changes - I remember that the call
> to pci_device_is_boot_vga() in xf86pciBus.c  was critical and that is
> still there in the latest git.
> Indeed, the reason we care about the vga arbiter at all is because of
> that Xorg dependency on the boot VGA card. pci_device_is_boot_vga()
> reads a sysfs file, and that sysfs file is populated based on the
> vga_default_driver(), so it's very difficult to extricate ourselves from
> the vga arbiter and its concept of the default device.
> We could make this method an 'either/or' rather than a fallback - so
> platforms who didn't care about legacy resources didn't bother with
> those tests, but I'm not sure what benefit that would give and I find it
> harder to be confident of an absence of unexpected consequences.
I was referring to this commit
but reading the commit log, it may have less to do with this issue
than I thought originally.
But the fact remains that we are going about this the wrong way.
Whether a graphics card decodes legacy VGA ranges or not has *nothing*
to do with whether or not it is in fact the primary device on a
non-x86 system, and so I still think the VGA arbiter should be omitted
entirely for such platforms, and Xorg should be fixed instead.
More information about the Linuxppc-dev