public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
To: devel@edk2.groups.io
Cc: lersek@redhat.com, leif.lindholm@linaro.org, ray.ni@intel.com,
	afish@apple.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [RFC PATCH] ArmPkg/PlatformBmLib: defer GOP console discovery after Driver#### dispatch
Date: Wed, 15 Jan 2020 11:22:17 +0100	[thread overview]
Message-ID: <20200115102217.3027-1-ard.biesheuvel@linaro.org> (raw)

Currently, ArmPkg's implementation of PlatformBootManagerBeforeConsole()
iterates over all PCI I/O handles in the database and connects the ones
that may produce an instance of the Graphics Output Protocol (GOP) once
connected. After that, it enumerates all the GOP instances and adds them
to the stdout/stderr console variables so that they will be used for
console output.

At this point in the boot, the BDS has not dispatched drivers loaded via
Driver#### options yet, making Driver#### options unsuitable for loading
drivers that are needed to produce GOP consoles. This is unfortunate, since
it prevents us from using commodity GFX hardware that ships without AARCH64
option ROMs on AARCH64 hardware and load the driver from the ESP.

So let's fix this, by deferring the discovery of PCI backed GOP instances
until PlatformBootManagerAfterConsole(). Note that non-PCI GOP instances
are still connected in the original spot, so platform framebuffers will
still work as before. Also note that the entire dance of connecting PCI
root bridges and I/O handles, matching PCI class codes and updating console
variables is all encapsulated in EfiBootManagerConnectVideoController(),
so let's just call that from PlatformBootManagerAfterConsole().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---

Tested on AMD Overdrive with an AMD Radeon GPU plugged in and the
AARCH64 AmdGop.efi driver loaded via Driver0000.

 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 81 ++------------------
 1 file changed, 7 insertions(+), 74 deletions(-)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
index e6e788e0f107..7c63a7b98847 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -219,66 +219,6 @@ FilterAndProcess (
 }
 
 
-/**
-  This FILTER_FUNCTION checks if a handle corresponds to a PCI display device.
-**/
-STATIC
-BOOLEAN
-EFIAPI
-IsPciDisplay (
-  IN EFI_HANDLE   Handle,
-  IN CONST CHAR16 *ReportText
-  )
-{
-  EFI_STATUS          Status;
-  EFI_PCI_IO_PROTOCOL *PciIo;
-  PCI_TYPE00          Pci;
-
-  Status = gBS->HandleProtocol (Handle, &gEfiPciIoProtocolGuid,
-                  (VOID**)&PciIo);
-  if (EFI_ERROR (Status)) {
-    //
-    // This is not an error worth reporting.
-    //
-    return FALSE;
-  }
-
-  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint32, 0 /* Offset */,
-                        sizeof Pci / sizeof (UINT32), &Pci);
-  if (EFI_ERROR (Status)) {
-    DEBUG ((EFI_D_ERROR, "%a: %s: %r\n", __FUNCTION__, ReportText, Status));
-    return FALSE;
-  }
-
-  return IS_PCI_DISPLAY (&Pci);
-}
-
-
-/**
-  This CALLBACK_FUNCTION attempts to connect a handle non-recursively, asking
-  the matching driver to produce all first-level child handles.
-**/
-STATIC
-VOID
-EFIAPI
-Connect (
-  IN EFI_HANDLE   Handle,
-  IN CONST CHAR16 *ReportText
-  )
-{
-  EFI_STATUS Status;
-
-  Status = gBS->ConnectController (
-                  Handle, // ControllerHandle
-                  NULL,   // DriverImageHandle
-                  NULL,   // RemainingDevicePath -- produce all children
-                  FALSE   // Recursive
-                  );
-  DEBUG ((EFI_ERROR (Status) ? EFI_D_ERROR : EFI_D_VERBOSE, "%a: %s: %r\n",
-    __FUNCTION__, ReportText, Status));
-}
-
-
 /**
   This CALLBACK_FUNCTION retrieves the EFI_DEVICE_PATH_PROTOCOL from the
   handle, and adds it to ConOut and ErrOut.
@@ -554,20 +494,6 @@ PlatformBootManagerBeforeConsole (
   //
   EfiBootManagerDispatchDeferredImages ();
 
-  //
-  // Locate the PCI root bridges and make the PCI bus driver connect each,
-  // non-recursively. This will produce a number of child handles with PciIo on
-  // them.
-  //
-  FilterAndProcess (&gEfiPciRootBridgeIoProtocolGuid, NULL, Connect);
-
-  //
-  // Find all display class PCI devices (using the handles from the previous
-  // step), and connect them non-recursively. This should produce a number of
-  // child handles with GOPs on them.
-  //
-  FilterAndProcess (&gEfiPciIoProtocolGuid, IsPciDisplay, Connect);
-
   //
   // Now add the device path of all handles with GOP on them to ConOut and
   // ErrOut.
@@ -674,6 +600,13 @@ PlatformBootManagerAfterConsole (
   UINTN                         PosX;
   UINTN                         PosY;
 
+  //
+  // Defer this call to PlatformBootManagerAfterConsole () so that devices
+  // managed by drivers that were loaded via Driver#### options are covered
+  // as well.
+  //
+  EfiBootManagerConnectVideoController (NULL);
+
   FirmwareVerLength = StrLen (PcdGetPtr (PcdFirmwareVersionString));
 
   //
-- 
2.20.1


             reply	other threads:[~2020-01-15 10:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 10:22 Ard Biesheuvel [this message]
2020-01-15 12:50 ` [RFC PATCH] ArmPkg/PlatformBmLib: defer GOP console discovery after Driver#### dispatch Laszlo Ersek
2020-01-15 13:02   ` Ard Biesheuvel
2020-01-15 14:52     ` Laszlo Ersek
2020-01-15 14:58       ` Ard Biesheuvel

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-list 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=20200115102217.3027-1-ard.biesheuvel@linaro.org \
    --to=devel@edk2.groups.io \
    /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