Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Jul 2014 17:42:22 +0000 (UTC)
From:      Nathan Whitehorn <nwhitehorn@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r268624 - head/sys/dev/vt/hw/efifb
Message-ID:  <201407141742.s6EHgMNt094168@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: nwhitehorn
Date: Mon Jul 14 17:42:22 2014
New Revision: 268624
URL: http://svnweb.freebsd.org/changeset/base/268624

Log:
  On my Lenovo laptop, the firmware maps the EFI framebuffer with MTRRs set
  to uncacheable. This leads to execrable console performance. Once PMAP is
  up, remap the framebuffer as write-combining. This reduces boot time on my
  laptop by 60% when booting with EFI.
  
  MFC after:	2 weeks

Modified:
  head/sys/dev/vt/hw/efifb/efifb.c

Modified: head/sys/dev/vt/hw/efifb/efifb.c
==============================================================================
--- head/sys/dev/vt/hw/efifb/efifb.c	Mon Jul 14 17:16:09 2014	(r268623)
+++ head/sys/dev/vt/hw/efifb/efifb.c	Mon Jul 14 17:42:22 2014	(r268624)
@@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$");
 
 static vd_init_t vt_efifb_init;
 static vd_probe_t vt_efifb_probe;
+static void vt_efifb_remap(void *efifb_data);
 
 static struct vt_driver vt_efifb_driver = {
 	.vd_name = "efifb",
@@ -68,6 +69,8 @@ static struct vt_driver vt_efifb_driver 
 static struct fb_info local_info;
 VT_DRIVER_DECLARE(vt_efifb, vt_efifb_driver);
 
+SYSINIT(efifb_remap, SI_SUB_KMEM, SI_ORDER_ANY, vt_efifb_remap, &local_info);
+
 static int
 vt_efifb_probe(struct vt_device *vd)
 {
@@ -133,9 +136,9 @@ vt_efifb_init(struct vt_device *vd)
 	info->fb_size = info->fb_height * info->fb_stride;
 	info->fb_pbase = efifb->fb_addr;
 	/*
-	 * We could use pmap_mapdev here except that the kernel pmap
-	 * hasn't been created yet and hence any attempt to lock it will
-	 * fail.
+	 * Use the direct map as a crutch until pmap is available. Once pmap
+	 * is online, the framebuffer will be remapped by vt_efifb_remap()
+	 * using pmap_mapdev_attr().
 	 */
 	info->fb_vbase = PHYS_TO_DMAP(efifb->fb_addr);
 
@@ -163,3 +166,22 @@ vt_efifb_init(struct vt_device *vd)
 
 	return (CN_INTERNAL);
 }
+
+static void
+vt_efifb_remap(void *xinfo)
+{
+	struct fb_info *info = xinfo;
+
+	if (info->fb_pbase == 0)
+		return;
+
+	/*
+	 * Remap as write-combining. This massively improves performance and
+	 * happens very early in kernel initialization, when everything is
+	 * still single-threaded and interrupts are off, so replacing the
+	 * mapping address is safe.
+	 */
+	info->fb_vbase = (intptr_t)pmap_mapdev_attr(info->fb_pbase,
+	    info->fb_size, VM_MEMATTR_WRITE_COMBINING);
+}
+



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201407141742.s6EHgMNt094168>