Date: Mon, 14 Jul 2014 20:53:45 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Nathan Whitehorn <nwhitehorn@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb Message-ID: <20140714175345.GK93733@kib.kiev.ua> In-Reply-To: <201407141742.s6EHgMNt094168@svn.freebsd.org> References: <201407141742.s6EHgMNt094168@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--UQu++aFZ1G7bq4T5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >=20 > Log: > On my Lenovo laptop, the firmware maps the EFI framebuffer with MTRRs s= et > 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. > =20 > MFC after: 2 weeks >=20 > Modified: > head/sys/dev/vt/hw/efifb/efifb.c >=20 > Modified: head/sys/dev/vt/hw/efifb/efifb.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- 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$"); > =20 > static vd_init_t vt_efifb_init; > static vd_probe_t vt_efifb_probe; > +static void vt_efifb_remap(void *efifb_data); > =20 > static struct vt_driver vt_efifb_driver =3D { > .vd_name =3D "efifb", > @@ -68,6 +69,8 @@ static struct vt_driver vt_efifb_driver=20 > static struct fb_info local_info; > VT_DRIVER_DECLARE(vt_efifb, vt_efifb_driver); > =20 > +SYSINIT(efifb_remap, SI_SUB_KMEM, SI_ORDER_ANY, vt_efifb_remap, &local_i= nfo); > + > static int > vt_efifb_probe(struct vt_device *vd) > { > @@ -133,9 +136,9 @@ vt_efifb_init(struct vt_device *vd) > info->fb_size =3D info->fb_height * info->fb_stride; > info->fb_pbase =3D 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 =3D PHYS_TO_DMAP(efifb->fb_addr); > =20 > @@ -163,3 +166,22 @@ vt_efifb_init(struct vt_device *vd) > =20 > return (CN_INTERNAL); > } > + > +static void > +vt_efifb_remap(void *xinfo) > +{ > + struct fb_info *info =3D xinfo; > + > + if (info->fb_pbase =3D=3D 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 =3D (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. --UQu++aFZ1G7bq4T5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTxBkpAAoJEJDCuSvBvK1BWD0QAIr3MWdSesuImzjg55kN0RFG Hc3Xwz3uHw8NS+fg1VD2ldSjxASXAWb3pBYDa/l7qQVOSHEZsurinL5QIf3G5e84 S+Uv7tTcwdRekBfxLrDNVMq6ruuqkucXvAFYlsq67CwOFq+9uUj8kRuDLYtJR71u fR9UO+6r2sqly2cuBVyauxtTQIXDIUYSQ52KRRMnAGWm+9jl8SgZef85eaNHwVJg ubeidpJ7ueV3qnFAAyMTCKq7uxnYGNWvdsHht+M6pbqWYU8/5FCazHfzHZtwyLD+ VuuXHxHAh+khaCjVCbf/L4CotTDN2dUgwxH4UZ6NrwQKfel9x/UOuMu5/p0J5OO8 7ErN7rlIL4+/SMct3nWsHdWoIfi2qlEbtQAPA6zI2KxtRpW3rB6T54vgoI2SQcsW T7jglooJ/2B0jd0PDWptYq0AUTcXGIPMcIJWa4pghFByOAG4Wdi1HF/1BoOL7FzO ZU8G6gH/kEppzPk5rTdPTpCQ1ildp3yP8WhngFhR1zReelzIQxHqiSFg0zF1P4li yM9ZU13Pn/T1rthCYVi11K0nKFlbAC8NNpbTjJ8hStWQAK8FjJCEaRMQP2agT9va uvly6wApmEm90WAwU7lyfxWB2E7Gie4g9SsgKw9OiqKNyFMAHSwnzd9ql0PX7YKQ UvwsrtDrnk3omMW298P8 =z9Nu -----END PGP SIGNATURE----- --UQu++aFZ1G7bq4T5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140714175345.GK93733>