On Tue, 27 May 2014 Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> On Wed, May 14, 2014 at 10:43:39PM +0200, Bruno Prémont wrote:
> > With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
>
> I think there's an emerging convention to use reference commits as
> <12-char-SHA1> ("subject"), i.e.,
>
> b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
>
> for this case. Also, s/Garret/Garrett/.
Adjusted
> > 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 autodetect 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".
> >
> > 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() [x86 and ia64 pci_fixup_video merged
> > into common function in vgaarb.c].
>
> I think it would be good to split this into two patches:
>
> 1) Merge the x86 and ia64 pci_fixup_video() implementations. This should
> have no functional change at all.
>
> 2) Whatever else you need to actually fix the bug. This will be much
> smaller, and the actual bug fix will be easier to see.
>
> It would also be nice to have a URL for a bugzilla or mailing list report
> of the problem, where there might be dmesg and/or Xorg logs.
>
> This sounds like it might be applicable for the stable kernels. If so, you
> probably should order these so the small bug-fix comes first (even though
> this may mean applying the same bugfix for x86 and ia64), and the merge
> second. That way the fix can be applied to the stable kernels without the
> merge.
Split up patches come in reply to this mail
> > Other architectures with PCI GPU might need a similar fixup.
> >
> > Note: If CONFIG_VGA_ARB is unset vga_default_device() is only available
> > as a stub that returns NULL, making this adjustment insufficient.
> > In addition, with the merge of x86/ia64 fixup code, this would
> > also result in disabled fixup.
> > Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
>
> I'm not quite sure what this means, or if this is hint that something is
> still wrong even with this patch. Do you mean that if CONFIG_VGA_ARB is
> unset, something still doesn't work?
>
> Maybe this will become obvious to me when you split up the patch.
This means that if someone unsets CONFIG_VGA_ARB (he need to set CONFIG_EXPERT
to do so) the fixup will not happen at all.
Without fixup the systems that need to set the IORESOURCE_ROM_SHADOW
flag will not have it, and boot_vga pci device attribute will be 0
more often as well.
Moving the unified function somewhere else than vgaarb.c would fix the new
IORESOURCE_ROM_SHADOW fixup dependency on VGA_ARB, though not prevent the
issue I try to fix as vga_default_device() always returns NULL without VGA_ARB.
One possible location would be drivers/pci/quirks.c.
Bruno
> > Signed-off-by: Bruno Prémont <bonbons@xxxxxxxxxxxxxxxxx>
> > ---
> > This is ported to changes in pci/fixup.c that landed in 3.15-rcs.
> >
> > Is this fine to go in, if so who will take it?
> >
> > I got no feedback on my last respin (on top of 3.14 a couple of weeks ago,
> > which added moving the ia64 pci boot_vga fixup).
> > I've been running this revision for a week or so on 3.15-rc kernels here
> > (mostly EFI-enabled system, the mentioned MBA as wells as non-Apple systems
> > where the patch was not required).
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
