svn commit: r268624 - head/sys/dev/vt/hw/efifb

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140714/8d46a0b1/attachment.sig>