From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Noever 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:56:48 +0200 Message-ID: References: <20140514224339.7f8be3a9@neptune.home> <20140527234255.GJ11907@google.com> <20140602201650.35f0e936@neptune.home> <20140602201926.4d476818@neptune.home> <20140625005501.7ff7e982@neptune.home> <20140705171503.GC6247@google.com> <20140810112654.1bf684d6@neptune.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20140810112654.1bf684d6@neptune.home> Sender: linux-pci-owner@vger.kernel.org To: =?UTF-8?Q?Bruno_Pr=C3=A9mont?= Cc: Bjorn Helgaas , DRI mailing list , Linux PCI , Dave Airlie , Matthew Garrett List-Id: dri-devel@lists.freedesktop.org On Sun, Aug 10, 2014 at 11:26 AM, Bruno Pr=C3=A9mont wrote: > On Sun, 10 August 2014 Andreas Noever wrot= e: > >> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever >> wrote: >> > On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas wrote: >> >> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Pr=C3=A9mont wrot= e: >> >>> 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 va= lue for >> >>> boot_vga PCI sysfs attribute on the corresponding PCI device. >> >>> >> >>> Xorg is refusing to detect devices when boot_vga=3D0 which is th= e case on >> >>> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and f= inds >> >>> the dri device but then bails out with "no devices detected". >> >>> >> >>> Note: When vga_default_device() is set boot_vga PCI sysfs attrib= ute >> >>> 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 o= bsolete >> >>> while having native drivers for the GPU also makes selecting >> >>> sysfb/efifb optional. >> >>> >> >>> Remove the efifb implementation of vga_default_device() and init= ialize >> >>> vgaarb's vga_default_device() with the PCI GPU that matches boot >> >>> screen_info in pci_fixup_video(). >> >>> >> >>> Tested-by: Anibal Francisco Martinez Cortina >> >>> Cc: Matthew Garrett >> >>> Cc: stable@vger.kernel.org >> >>> Signed-off-by: Bruno Pr=C3=A9mont >> >> >> >> 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_vide= o >> > runs only if vga_default_device() is NULL. Removing the check fixe= s >> > 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 ca= lls >> > 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 che= ck) >> > >> > vga_arbiter_add_pci_device chooses intel simply because it is the >> > first device. Next pci_fixup_video(intel) sees that it is the defa= ult >> > 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= =2E >> > >> > Does setting the ROM_SHADOW flag on (possibly) the wrong device ha= ve >> > 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= =2E >> 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