diff mbox series

[v2,22/26] x86: video: Support copy framebuffer with probed devices

Message ID 20200524194852.v2.22.I77e552931a507922710db3d34954e8367239e531@changeid
State Accepted
Commit 551ca0e64744324b0f337bfa4a743db24a2800ca
Headers show
Series x86: video: Speed up the framebuffer | expand

Commit Message

Simon Glass May 25, 2020, 1:48 a.m. UTC
For PCI video devices that are not mentioned in the devicetree, U-Boot
does not bind a driver before relocation, since PCI is not fully probed
at that point. Furthermore it is possible for the video device to be on
a secondary bus which is not even scanned.

This is fine if the framebuffer is allocated in fixed memory, as it
normally is on x86. But when using this as a copy framebuffer, we also
need U-Boot to allocate its own cached framebuffer for working in. Since
the video driver is never bound before relocation, the framebuffer size
is never set and U-Boot does no allocation.

Add a new CONFIG option to reserve 16MB of memory for this eventuality.
This allows vesa devices to use the copy framebuffer.

Signed-off-by: Simon Glass <sjg at chromium.org>
Reviewed-by: Anatolij Gustschin <agust at denx.de>
---

Changes in v2: None

 drivers/video/Kconfig        | 19 +++++++++++++++++++
 drivers/video/video-uclass.c |  5 +++++
 2 files changed, 24 insertions(+)
diff mbox series

Patch

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1cf63efd48..3e65052359 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -14,6 +14,25 @@  config DM_VIDEO
 	  option compiles in the video uclass and routes all LCD/video access
 	  through this.
 
+config VIDEO_PCI_DEFAULT_FB_SIZE
+	hex "Default framebuffer size to use if no drivers request it"
+	depends on DM_VIDEO
+	default 0x1000000 if X86 && PCI
+	default 0 if !(X86 && PCI)
+	help
+	  Generally, video drivers request the amount of memory they need for
+	  the frame buffer when they are bound, by setting the size field in
+	  struct video_uc_platdata. That memory is then reserved for use after
+	  relocation. But PCI drivers cannot be bound before relocation unless
+	  they are mentioned in the devicetree.
+
+	  With this value set appropriately, it is possible for PCI video
+	  devices to have a framebuffer allocated by U-Boot.
+
+	  Note: the framebuffer needs to be large enough to store all pixels at
+	  maximum resolution. For example, at 1920 x 1200 with 32 bits per
+	  pixel, 2560 * 1600 * 32 / 8 = 0xfa0000 bytes are needed.
+
 config VIDEO_COPY
 	bool "Enable copying the frame buffer to a hardware copy"
 	depends on DM_VIDEO
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index aa543cb5df..b5a03042c2 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -97,6 +97,11 @@  int video_reserve(ulong *addrp)
 		debug("%s: Reserving %lx bytes at %lx for video device '%s'\n",
 		      __func__, size, *addrp, dev->name);
 	}
+
+	/* Allocate space for PCI video devices in case there were not bound */
+	if (*addrp == gd->video_top)
+		*addrp -= CONFIG_VIDEO_PCI_DEFAULT_FB_SIZE;
+
 	gd->video_bottom = *addrp;
 	debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
 	      gd->video_top);