On Sun, Aug 10, 2014 at 11:26 AM, Bruno Prémont
<bonbons@xxxxxxxxxxxxxxxxx> wrote:
> On Sun, 10 August 2014 Andreas Noever <andreas.noever@xxxxxxxxx> wrote:
>
>> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever
>> <andreas.noever@xxxxxxxxx> wrote:
>> > On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> 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@xxxxxxxxx>
>> >>> Cc: Matthew Garrett <matthew.garrett@xxxxxxxxxx>
>> >>> Cc: stable@xxxxxxxxxxxxxxx
>> >>> Signed-off-by: Bruno Prémont <bonbons@xxxxxxxxxxxxxxxxx>
>> >>
>> >> 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().
The system does not boot. The Intel device is still set as the
default device in pci_fixup_video (near "Boot video device") and
prevents the nvidia device (which is initialized later) from becoming
the default one.
> How did your system behave in the past if you did not enable efifb?
I don't think that I ever did not enable efifb. It seems to have been
around for quite a while?
Andreas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
