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
This commit is contained in:
Nathan Whitehorn 2014-07-14 17:42:22 +00:00
parent db3ddfd672
commit b85beee188

View File

@ -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);
}