[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Andreas Noever]

On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever
<andreas.noever at gmail.com> wrote:
> On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas <bhelgaas at google.com> wrote:
>> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Prémont wrote:
>>> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
>>> Matthew Garrett introduced a efifb vga_default_device() so that EFI
>>> systems that do not load shadow VBIOS or setup VGA get proper value for
>>> boot_vga PCI sysfs attribute on the corresponding PCI device.
>>>
>>> Xorg is refusing to detect devices when boot_vga=0 which is the case on
>>> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
>>> the dri device but then bails out with "no devices detected".
>>>
>>> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
>>> reflects its state. When unset this attribute is 1 whenever
>>> IORESOURCE_ROM_SHADOW flag is set.
>>>
>>> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
>>> while having native drivers for the GPU also makes selecting
>>> sysfb/efifb optional.
>>>
>>> Remove the efifb implementation of vga_default_device() and initialize
>>> vgaarb's vga_default_device() with the PCI GPU that matches boot
>>> screen_info in pci_fixup_video().
>>>
>>> Tested-by: Anibal Francisco Martinez Cortina <linuxkid.zeuz at gmail.com>
>>> Cc: Matthew Garrett <matthew.garrett at nebula.com>
>>> Cc: stable at vger.kernel.org
>>> Signed-off-by: Bruno Prémont <bonbons at linux-vserver.org>
>>
>> I applied both with Matthew's ack to pci/misc for v3.17, thanks!
>
> I just tried to run the latest kernel.  It failed to boot and git
> bisect points to this commit (MacBookPro10,1 with Nvidia&Intel
> graphics).
>
> The (now removed) code in efifb_setup did always set default_vga, even
> if it had already been set earlier. The new code in pci_fixup_video
> runs only if vga_default_device() is NULL. Removing the check fixes
> the regression.
>
>
> The following calls to vga_set_default_device are made during boot:
>
> vga_arbiter_add_pci_device -> vga_set_default_device(intel)
> pci_fixup_video -> vga_set_default_device(intel) (there are two calls
> in pci_fixup_video, this one is the one near "Boot video device")
> pci_fixup_video -> vga_set_default_device(nvidia) (from the "Does
> firmware framebuffer belong to us?" loop, only if I remove the check)
>
> vga_arbiter_add_pci_device chooses intel simply because it is the
> first device. Next pci_fixup_video(intel) sees that it is the default
> device, sets the IORESOURCE_ROM_SHADOW flag and calls
> vga_set_default_device again. And finally (if the check is removed)
> pci_fixup_video(nvidia) sees that it owns the framebuffer and sets
> itself as the default device which allows the system to boot again.
>
> Does setting the ROM_SHADOW flag on (possibly) the wrong device have
> any effect?
Yes it does. Removing the line changes a long standing
i915 0000:00:02.0: Invalid ROM contents
into a
i915 0000:00:02.0: BAR 6: can't assign [??? 0x00000000 flags
0x20000000] (bogus alignment).

The first is logged at KERN_ERR and the second one only at KERN_INFO.
We are making progress.