On 07/14/14 10:53, Konstantin Belousov wrote:
On Mon, Jul 14, 2014 at 05:42:22PM +0000, Nathan Whitehorn wrote:
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);
+}
+
Could you use pmap_change_attr() ? This would save some KVA.

Does that work with the direct map? I'm pretty hesitant to muck with the direct map region this way...
-Nathan
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to