On 7/16/25 6:23 PM, Bjorn Helgaas wrote:
On Mon, Jul 14, 2025 at 04:21:37PM -0500, Mario Limonciello wrote:
From: Mario Limonciello <mario.limoncie...@amd.com>

This series started out as changes to VGA arbiter to try to handle a case
of a system with 2 GPUs that are not VGA devices.  This was discussed
but decided not to overload the VGA arbiter for non VGA devices.

Instead move the x86 specific detection of framebuffer resources into x86
specific code that the fbcon can use to properly identify the primary
device. This code is still called from the VGA arbiter, and the logic does
not change there. To avoid regression default to VGA arbiter and only fall
back to looking up with x86 specific detection method.

In order for userspace to also be able to discover which device was the
primary video display device create a new sysfs file 'boot_display'.

A matching userspace implementation for this file is available here:
Link: https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/39
Link: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2038

Dave Airlie has been pinged for a comment on this approach.
Dave had suggested in the past [1]:

"
  But yes if that doesn't work, then maybe we need to make the boot_vga
  flag mean boot_display_gpu, and fix it in the kernel
"

This was one of the approached tried in earlier revisions and it was
rejected in favor of creating a new sysfs file (which is what this
version does).

It is suggested that this series merge entirely through the PCI tree.

Link: 
https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/37#note_2938602
 [1]

There's an underlying bug that we're trying to fix with this series
and the related libpciaccess and xserver changes, isn't there?  Can we
include that somewhere to help motivate this?  (I guess it's really
only the last two or three patches that are strictly related, right?)

Do you mean in the cover letter of another spin of the series or just inline here?

The issue is that on systems with more than one GPU userspace doesn't know which one to be used to treat as primary. The concept of primary is important to be able to decide which GPU is used for display and which is used for rendering. If it's guessed wrong then both GPUs will be kept awake burning a lot of power.

Historically it would use the "boot_vga" attribute but this isn't present on modern GPUs. So this series introduces a new attribute to give a hint to userspace which was used for display at bootup. The matching patches to libpciaccess and xorg-server utilize this new sysfs file to set things up as intended.

And yes, the last few ones are the only ones strictly related to this issue. The other patches were just cleanups to use the same new helper from these patches elsewhere in the kernel too.


v8 fixes an LKP robot reported issue

Mario Limonciello (9):
   PCI: Add helper for checking if a PCI device is a display controller
   vfio/pci: Use pci_is_display()
   vga_switcheroo: Use pci_is_display()
   iommu/vt-d: Use pci_is_display()
   ALSA: hda: Use pci_is_display()
   Fix access to video_is_primary_device() when compiled without
     CONFIG_VIDEO
   PCI/VGA: Replace vga_is_firmware_default() with a screen info check
   fbcon: Use screen info to find primary device
   PCI: Add a new 'boot_display' attribute

  Documentation/ABI/testing/sysfs-bus-pci |  8 +++++
  arch/parisc/include/asm/video.h         |  2 +-
  arch/sparc/include/asm/video.h          |  2 ++
  arch/x86/include/asm/video.h            |  2 ++
  arch/x86/video/video-common.c           | 17 ++++++++-
  drivers/gpu/vga/vga_switcheroo.c        |  2 +-
  drivers/iommu/intel/iommu.c             |  2 +-
  drivers/pci/pci-sysfs.c                 | 46 +++++++++++++++++++++++++
  drivers/pci/vgaarb.c                    | 31 +++--------------
  drivers/vfio/pci/vfio_pci_igd.c         |  3 +-
  include/linux/pci.h                     | 15 ++++++++
  sound/hda/hdac_i915.c                   |  2 +-
  sound/pci/hda/hda_intel.c               |  4 +--
  13 files changed, 101 insertions(+), 35 deletions(-)

--
2.43.0


Reply via email to