public inbox for chrome-platform@lists.linux.dev
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: tzungbi@kernel.org, briannorris@chromium.org,
	jwerner@chromium.org, javierm@redhat.com,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, simona@ffwll.ch
Cc: chrome-platform@lists.linux.dev, dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH 5/8] video/aperture: Support coreboot devices
Date: Thu,  8 Jan 2026 15:19:45 +0100	[thread overview]
Message-ID: <20260108145058.56943-6-tzimmermann@suse.de> (raw)
In-Reply-To: <20260108145058.56943-1-tzimmermann@suse.de>

Add support for coreboot devices. Until now, all devices with system
framebuffers were on the platform bus. On systems with a coreboot
firmware, the system framebuffer can be represented as coreboot device
on the coreboot bus. Handling the related graphics apertures requires
new interfaces and a custom way of removing the coreboot device. The
core aperture code is independent from the type of device.

Also move around a comment that refers to both, platform and coreboot,
devices.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/video/aperture.c | 60 ++++++++++++++++++++++++++++++++--------
 include/linux/aperture.h | 16 +++++++++++
 2 files changed, 64 insertions(+), 12 deletions(-)

diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 2b5a1e666e9b..15e664a4478b 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: MIT
 
 #include <linux/aperture.h>
+#include <linux/coreboot.h>
 #include <linux/device.h>
 #include <linux/list.h>
 #include <linux/mutex.h>
@@ -197,22 +198,47 @@ static int devm_aperture_acquire(struct device *dev,
 	return devm_add_action_or_reset(dev, devm_aperture_acquire_release, ap);
 }
 
+#if defined(CONFIG_GOOGLE_COREBOOT_TABLE)
+static void aperture_detach_coreboot_device(struct device *dev)
+{
+	struct coreboot_device *cbdev = dev_to_coreboot_device(dev);
+
+	device_unregister(&cbdev->dev);
+}
+
+/**
+ * devm_aperture_acquire_for_coreboot_device - Acquires ownership of an aperture
+ *                                             on behalf of a coreboot device.
+ * @cbdev:	the coreboot device to own the aperture
+ * @base:	the aperture's byte offset in physical memory
+ * @size:	the aperture size in bytes
+ *
+ * Installs the given device as the new owner of the aperture. The function
+ * expects the aperture to be provided by a coreboot device. If another
+ * driver takes over ownership of the aperture, aperture helpers will then
+ * unregister the coreboot device automatically. All acquired apertures are
+ * released automatically when the underlying device goes away.
+ *
+ * The function fails if the aperture, or parts of it, is currently
+ * owned by another device. To evict current owners, callers should use
+ * remove_conflicting_devices() et al. before calling this function.
+ *
+ * Returns:
+ * 0 on success, or a negative errno value otherwise.
+ */
+int devm_aperture_acquire_for_coreboot_device(struct coreboot_device *cbdev,
+					      resource_size_t base,
+					      resource_size_t size)
+{
+	return devm_aperture_acquire(&cbdev->dev, base, size, aperture_detach_coreboot_device);
+}
+EXPORT_SYMBOL(devm_aperture_acquire_for_coreboot_device);
+#endif
+
 static void aperture_detach_platform_device(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 
-	/*
-	 * Remove the device from the device hierarchy. This is the right thing
-	 * to do for firmware-based fb drivers, such as EFI, VESA or VGA. After
-	 * the new driver takes over the hardware, the firmware device's state
-	 * will be lost.
-	 *
-	 * For non-platform devices, a new callback would be required.
-	 *
-	 * If the aperture helpers ever need to handle native drivers, this call
-	 * would only have to unplug the DRM device, so that the hardware device
-	 * stays around after detachment.
-	 */
 	platform_device_unregister(pdev);
 }
 
@@ -264,6 +290,16 @@ static void aperture_detach_devices(resource_size_t base, resource_size_t size)
 		ap->dev = NULL; /* detach from device */
 		list_del(&ap->lh);
 
+		/*
+		 * Remove the device from the device hierarchy. This is the right thing
+		 * to do for firmware-based fb drivers, such as EFI, VESA or VGA. After
+		 * the new driver takes over the hardware, the firmware device's state
+		 * will be lost.
+		 *
+		 * If the aperture helpers ever need to handle native drivers, this call
+		 * would only have to unplug the DRM device, so that the hardware device
+		 * stays around after detachment.
+		 */
 		ap->detach(dev);
 	}
 
diff --git a/include/linux/aperture.h b/include/linux/aperture.h
index 1a9a88b11584..459823f86dc8 100644
--- a/include/linux/aperture.h
+++ b/include/linux/aperture.h
@@ -5,10 +5,17 @@
 
 #include <linux/types.h>
 
+struct coreboot_device;
 struct pci_dev;
 struct platform_device;
 
 #if defined(CONFIG_APERTURE_HELPERS)
+#if defined(CONFIG_GOOGLE_COREBOOT_TABLE)
+int devm_aperture_acquire_for_coreboot_device(struct coreboot_device *cbdev,
+					      resource_size_t base,
+					      resource_size_t size);
+#endif
+
 int devm_aperture_acquire_for_platform_device(struct platform_device *pdev,
 					      resource_size_t base,
 					      resource_size_t size);
@@ -20,6 +27,15 @@ int __aperture_remove_legacy_vga_devices(struct pci_dev *pdev);
 
 int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *name);
 #else
+#if defined(CONFIG_GOOGLE_COREBOOT_TABLE)
+static inline int devm_aperture_acquire_for_coreboot_device(struct coreboot_device *cbdev,
+							    resource_size_t base,
+							    resource_size_t size)
+{
+	return 0;
+}
+#endif
+
 static inline int devm_aperture_acquire_for_platform_device(struct platform_device *pdev,
 							    resource_size_t base,
 							    resource_size_t size)
-- 
2.52.0


  parent reply	other threads:[~2026-01-08 14:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-08 14:19 [PATCH 0/8] drm, coreboot: Add DRM coreboot driver Thomas Zimmermann
2026-01-08 14:19 ` [PATCH 1/8] firmware: google: Do sysfb test before creating coreboot framebuffer Thomas Zimmermann
2026-01-08 16:55   ` Julius Werner
2026-01-09  9:17     ` Thomas Zimmermann
2026-01-09 10:21       ` Javier Martinez Canillas
2026-01-13 22:32         ` Julius Werner
2026-01-14  8:13           ` Thomas Zimmermann
2026-01-14 20:32             ` Julius Werner
2026-01-08 14:19 ` [PATCH 2/8] firmware: google: Init coreboot bus with subsys_initcall() Thomas Zimmermann
2026-01-09 10:24   ` Javier Martinez Canillas
2026-01-08 14:19 ` [PATCH 3/8] firmware: google: Clean up include statements in coreboot_table.h Thomas Zimmermann
2026-01-09 10:24   ` Javier Martinez Canillas
2026-01-08 14:19 ` [PATCH 4/8] firmware: google: Export coreboot driver and device interfaces Thomas Zimmermann
2026-01-09 10:26   ` Javier Martinez Canillas
2026-01-08 14:19 ` Thomas Zimmermann [this message]
2026-01-09 10:30   ` [PATCH 5/8] video/aperture: Support coreboot devices Javier Martinez Canillas
2026-01-08 14:19 ` [PATCH 6/8] drm/sysfb: Remove duplicate declarations Thomas Zimmermann
2026-01-09 10:31   ` Javier Martinez Canillas
2026-01-14  9:02     ` Thomas Zimmermann
2026-01-08 14:19 ` [PATCH 7/8] drm/sysfb: Generalize pixel-format matching Thomas Zimmermann
2026-01-09 10:32   ` Javier Martinez Canillas
2026-01-08 14:19 ` [PATCH 8/8] drm/sysfb: corebootdrm: Add DRM driver for coreboot framebuffers Thomas Zimmermann
2026-01-14 21:49   ` kernel test robot
2026-01-14 22:12   ` kernel test robot
2026-01-08 18:10 ` [PATCH 0/8] drm, coreboot: Add DRM coreboot driver Brian Norris
2026-01-09  8:50   ` Thomas Zimmermann
2026-01-09 10:37     ` Javier Martinez Canillas

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=20260108145058.56943-6-tzimmermann@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@gmail.com \
    --cc=briannorris@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=jwerner@chromium.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzungbi@kernel.org \
    /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