From nobody Fri Mar 17 05:48:39 2023 X-Original-To: dev-commits-src-branches@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PdCqC4m6dz407St; Fri, 17 Mar 2023 05:48:39 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdCqC4HQ6z412t; Fri, 17 Mar 2023 05:48:39 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679032119; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aOjab3x2PZjtWGbh33Tqz+1Myy16nlwxXLkUGdkQzrc=; b=TS/LQbz/n8YMWNv2Q6GPGcq6B1Gmz6ZJIJlov8OtliUgxAywlFhdYE2sLH0Wv7u+ITaWco AnC8wbok22DiRVG+vV4Nb+7JXTmfvLrt0EHpVR6UYadyKoEobdI5C0+5jVeO2aGtBUKOP+ 9Gv7df601br/PXb7kWCAn7AumdTFYWaLrIJ532le/PFedFD5ClV5e4cCFiffe3tfBl9TPl BzVpHzjT4Olm/QdJU3ImFHR4GxY2MeYWcAACvkc6NWADE5HlFBzF2mZDBIBIwnR2zfwIkE cweqjIN18OlPaPyPzP2LZlI0Oj6tQOoQ8RuUiWI/g51MdZXdBWDhGcyXmiG9rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679032119; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aOjab3x2PZjtWGbh33Tqz+1Myy16nlwxXLkUGdkQzrc=; b=D3bvii21N9cmjgBGnKRMZOc5mG2RslRfGLiYlNc7pp1Of1HvXRwJevyv2OYTRlYzxNn3hH Vo96cCyCWMQ0BKUxZMIHAzkl3HQiIMiA9JdAp02JHTSSNU9J82XCdnhzVEyQzHNK38QizB lpPRqg5g6JCSWijuL2cGUX8LBDmvryl9W7qLxfXEWarhU2QvO2gCZQgOqDZOEMvSk9GW6B 21Vo5RZkuMkD5LzdyT2YJ3+mv2dYwGlDYePegQuHQsoj+p/r/GlnBj75o9M9CACQzbtsNh ilG2L7iSBJM1FZSeHEVk/B57jRyoFam94tVxls063MateRKgJ7U+8kPMpUvxSQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679032119; a=rsa-sha256; cv=none; b=JI2RnS/sD2c+apXARmYl0iu/HkiuL4CoaaxY0k1BoRPxurgifg9sfRxKB+B0QZyUIfMpXy 38CH5paeZp2Cy8tFn4Ry7DhcW4jDiTmODqZyHSCBkMG9e4Lg2LqO22RlHJQ/UxpMnxkgGI CUefpN3HXLGhtzagWByHNIiWdL92CeHmECo0m19S9EfPXKjfW/AI4Yd0gyJ9jaM+oFWLsd 3Trnvl+BC32oHSg916VM3+LViZzrkZz0RcKEax3aWDuIP5MH9qsj+z9Izo/eY07CDlBtbr zbYylDSXQsmh9HTV4uvtgrtzYgepwjEUcwCQubAqaNmQE1kmF4E+oTICJCaHXQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PdCqC3Kflz1Cqt; Fri, 17 Mar 2023 05:48:39 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 32H5mdsQ006334; Fri, 17 Mar 2023 05:48:39 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 32H5mdjE006333; Fri, 17 Mar 2023 05:48:39 GMT (envelope-from git) Date: Fri, 17 Mar 2023 05:48:39 GMT Message-Id: <202303170548.32H5mdjE006333@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org From: Kyle Evans Subject: git: 6fdb5daba679 - stable/13 - efifb: add a tunable to select the framebuffer cache attribute List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-branches@freebsd.org X-BeenThere: dev-commits-src-branches@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: kevans X-Git-Repository: src X-Git-Refname: refs/heads/stable/13 X-Git-Reftype: branch X-Git-Commit: 6fdb5daba679128b11b6ce3a401fb74d0db07fd8 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch stable/13 has been updated by kevans: URL: https://cgit.FreeBSD.org/src/commit/?id=6fdb5daba679128b11b6ce3a401fb74d0db07fd8 commit 6fdb5daba679128b11b6ce3a401fb74d0db07fd8 Author: Kyle Evans AuthorDate: 2023-03-01 06:04:49 +0000 Commit: Kyle Evans CommitDate: 2023-03-17 05:01:45 +0000 efifb: add a tunable to select the framebuffer cache attribute Mapping the framebuffer with WC (Write Combined) memory type can, in practice, cause some memory transactions to be rate-limited at a fraction of the fb write rate. WC allows one core to queue up many globally visible write transactions, and in the process some unrelated transactions may end up having to wait for all of the queued up PCI writes to be flushed. Add an hw.efifb.cache_attr tunable to allow mapping the framebuffer as uncacheable instead. We should likely be taking a more careful approach of checking the memory map to determine which cacheability attributes are feasible, but the knob lets us use our historically functional behavior while offering a convenient way to switch on a stock kernel. The only valid values for hw.efifb.cache_attr at this time are "uc" and "wc". Original patch by Marc De La Gueronniere along with previous testing. Reviewed by: imp Sponsored by: Verisign, Inc. Sponsored by: Klara, Inc. (cherry picked from commit 8dff0b6761407357c5bb42ee799c5c9f465557a3) --- sys/dev/vt/hw/efifb/efifb.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/sys/dev/vt/hw/efifb/efifb.c b/sys/dev/vt/hw/efifb/efifb.c index 3aaeebcb1b5e..20822629d0c5 100644 --- a/sys/dev/vt/hw/efifb/efifb.c +++ b/sys/dev/vt/hw/efifb/efifb.c @@ -103,7 +103,32 @@ vt_efifb_init(struct vt_device *vd) struct fb_info *info; struct efi_fb *efifb; caddr_t kmdp; + int memattr; int roff, goff, boff; + char attr[16]; + + /* + * XXX TODO: I think there's more nuance here than we're acknowledging, + * and we should look into it. It may be that the framebuffer lives in + * a segment of memory that doesn't support one or both of these. We + * should likely be consulting the memory map for any applicable + * cacheability attributes before making a final decision. + */ + memattr = VM_MEMATTR_WRITE_COMBINING; + if (TUNABLE_STR_FETCH("hw.efifb.cache_attr", attr, sizeof(attr))) { + /* + * We'll allow WC but it's currently the default, UC is the only + * other tested one at this time. + */ + if (strcasecmp(attr, "wc") != 0 && + strcasecmp(attr, "uc") != 0) { + printf("efifb: unsupported cache attr specified: %s\n", + attr); + printf("efifb: expected \"wc\" or \"uc\"\n"); + } else if (strcasecmp(attr, "uc") == 0) { + memattr = VM_MEMATTR_UNCACHEABLE; + } + } info = vd->vd_softc; if (info == NULL) @@ -141,7 +166,7 @@ vt_efifb_init(struct vt_device *vd) info->fb_size = info->fb_height * info->fb_stride; info->fb_pbase = efifb->fb_addr; info->fb_vbase = (intptr_t)pmap_mapdev_attr(info->fb_pbase, - info->fb_size, VM_MEMATTR_WRITE_COMBINING); + info->fb_size, memattr); vt_fb_init(vd);