On Sun, 10 August 2014 Andreas Noever andreas.noever@gmail.com wrote:
On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever andreas.noever@gmail.com wrote:
On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas bhelgaas@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@gmail.com Cc: Matthew Garrett matthew.garrett@nebula.com Cc: stable@vger.kernel.org Signed-off-by: Bruno Prémont bonbons@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.
How does your system behave if you change vga_arbiter_add_pci_device() not to set vga_set_default_device() with the first device registered?
That is remove the #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE code block in vga_arbiter_add_pci_device().
How did your system behave in the past if you did not enable efifb?
Bruno