From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Andreas Noever <andreas.noever@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Dave Airlie <airlied@linux.ie>,
Matthew Garrett <matthew.garrett@nebula.com>
Subject: Re: [PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
Date: Sun, 10 Aug 2014 11:26:54 +0200 [thread overview]
Message-ID: <20140810112654.1bf684d6@neptune.home> (raw)
In-Reply-To: <CAMxnaaXGQe4vg9cY5e2KZBnG4F-z49OriwxEGUE-DCE6MKUryQ@mail.gmail.com>
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
next prev parent reply other threads:[~2014-08-10 9:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 20:43 [Patch] x86, ia64, efifb: Move boot_vga fixup from pci to vgaarb Bruno Prémont
2014-05-27 23:42 ` Bjorn Helgaas
2014-06-02 18:16 ` Bruno Prémont
2014-06-02 18:19 ` [PATCH 2/2] x86, ia64: Merge common vga fixup code Bruno Prémont
2014-06-02 18:19 ` [PATCH 1/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Bruno Prémont
2014-06-17 22:35 ` Bjorn Helgaas
2014-06-18 6:09 ` Bruno Prémont
2014-06-24 20:41 ` Bruno Prémont
2014-06-24 22:55 ` [PATCH 1/2 v2] " Bruno Prémont
2014-06-24 22:58 ` [PATCH 2/2 v2] x86, ia64: Merge common vga fixup code Bruno Prémont
2014-06-24 23:02 ` [PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Matthew Garrett
2014-07-05 17:15 ` Bjorn Helgaas
2014-08-10 0:21 ` Andreas Noever
2014-08-10 0:36 ` Andreas Noever
2014-08-10 9:26 ` Bruno Prémont [this message]
2014-08-10 9:56 ` Andreas Noever
2014-08-10 16:34 ` Bruno Prémont
2014-08-14 0:40 ` Andreas Noever
2014-08-16 17:21 ` [PATCH 0/2] " Bruno Prémont
2014-08-16 17:25 ` [PATCH 1/2] vgaarb: Drop obsolete #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE Bruno Prémont
2014-08-16 17:30 ` [PATCH 2/2] x86, ia64: Don't default to first video device Bruno Prémont
2014-08-19 15:45 ` [PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Andreas Noever
2014-08-20 5:55 ` Bruno Prémont
2014-08-20 7:11 ` Bruno Prémont
[not found] ` <CAMxnaaUodONkqmdPWedN-Q1qheHiJAScFcG_XbX1--ZmiOQZDg@mail.gmail.com>
2014-08-21 21:34 ` Bruno Prémont
2014-08-22 4:39 ` Bjorn Helgaas
2014-08-22 6:23 ` Bruno Prémont
[not found] ` <CAMxnaaU9EiMcne-aQjS1sY1Orn6xGbVHEnd057ogcZ77p74Y=Q@mail.gmail.com>
2014-08-23 11:06 ` Bruno Prémont
2014-08-24 21:09 ` [PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io Bruno Prémont
2014-08-26 15:32 ` Andreas Noever
2014-08-28 20:47 ` Bruno Prémont
2014-09-12 11:19 ` Bruno Prémont
2014-09-12 14:28 ` Bjorn Helgaas
2014-09-18 23:26 ` Dave Airlie
2014-09-19 5:18 ` Bjorn Helgaas
2014-08-24 21:13 ` [PATCH 2/2 v2] vgaarb: Drop obsolete #ifndef Bruno Prémont
2014-08-25 12:16 ` [PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() Daniel Vetter
2014-08-25 12:39 ` Bruno Prémont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140810112654.1bf684d6@neptune.home \
--to=bonbons@linux-vserver.org \
--cc=airlied@linux.ie \
--cc=andreas.noever@gmail.com \
--cc=bhelgaas@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew.garrett@nebula.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).