Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb
--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--
討論串 (同標題文章)
完整討論串 (本文為第 2 之 8 篇)：