From nobody Wed Mar 1 06:05:03 2023 X-Original-To: dev-commits-src-all@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 4PRNxW4gMrz3vSM8; Wed, 1 Mar 2023 06:05:03 +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 4PRNxW4B4Tz3qsv; Wed, 1 Mar 2023 06:05:03 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677650703; 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=TyUfSgrWsT+3QD3/41xYCts1fHFVLilsYns3Fb/wnqk=; b=U8qtujzwVsokJrPWrHXOF4vypnqy9ohUb6q+9v6PoFfh97MXkok7wqIMv7wcybdshdW413 1MiH7JQkUjRzb279N708Ix+x6OEnfURaeBQ10Bn/CvXZbSRcMSNVKiParpKbfG9IeQIRve 0oswBS8g+B2tEYSiPKdnE53MP3nfQDNOlzotn83gIi96Zv7IIHw1+T3UR8b5HWZ9u6imK1 qiiaYxPCcxH1A1BLcgBg/slNg7fffgiDfCZ0KMOYEgfBmC8eRro0EO13NnyvCnsG6so4ZQ 8Az2/ElYMKT4ZVE6m1Py/Up+xrRlpovkNua3gKEIdyV1XHRSXFjzfkfTGd2oSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677650703; 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=TyUfSgrWsT+3QD3/41xYCts1fHFVLilsYns3Fb/wnqk=; b=ngujIXG2gy8yiDpM2ISRK4sXecEYD4+7k2Smi4gVLIe+6CIVkJaxenQY3bucfKQt4wVlIx xyNwmPuNe1i8H1rx3jLhXDNHWK7ttzThTwIadRJPCn+/gWh3wZd2KybTKICKPvKhhs36SM 2sAeE6oK4J+P1sYlYmujgacwbIk40r38fGBMLNpqFLvHlGopOFitBA1cXt3g4r6R68cBNF w799xR7FmAm8Du2TqhTz2Vzi4gunauo+43o49VwjNKF+JSkN72xXCkVVC7NMFzgBCHl+an +eU+IMq3JPihstKQY/4CC9kYRqX9GpQ/KiJfiFA0VsWQ11eF7xo0Vex4RAuvyw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677650703; a=rsa-sha256; cv=none; b=g2/a5T1sZ/sDotOG3ivuGt7RCE6LVv1XRxpgkYNRYbSgyxMBWlNX4M+9kMhODKskP9EmHL ea+PuC6sKRoNk+u5W9MFByR1IKpgYuCW89Zsy42vsnBZ/zLmKbOzZYd4T4DgKj4pJMCn5C ah0c7hPrExEym3frU3RHDp3dlkEa1L392VVmmwGS2CyQZ7rNDFTc9aiYIvKHvGunJX4VAz smePUZ1dd7xjWxG7A0P2wBnCld2my0vyHgeyzvX6OlmEy/3V82aYJ8YH+pVCKkeAUeKmam JjU/cFcOaCjANXadbVgzjNNtkyK9x7qZQgoR6WMdr3wgMnwrsbacGVUO/ofN7Q== 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 4PRNxW3FpwzNSh; Wed, 1 Mar 2023 06:05:03 +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 321653uH067134; Wed, 1 Mar 2023 06:05:03 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 3216530f067133; Wed, 1 Mar 2023 06:05:03 GMT (envelope-from git) Date: Wed, 1 Mar 2023 06:05:03 GMT Message-Id: <202303010605.3216530f067133@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org From: Kyle Evans Subject: git: 8dff0b676140 - main - efifb: add a tunable to select the framebuffer cache attribute List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@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/main X-Git-Reftype: branch X-Git-Commit: 8dff0b6761407357c5bb42ee799c5c9f465557a3 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by kevans: URL: https://cgit.FreeBSD.org/src/commit/?id=8dff0b6761407357c5bb42ee799c5c9f465557a3 commit 8dff0b6761407357c5bb42ee799c5c9f465557a3 Author: Kyle Evans AuthorDate: 2023-03-01 06:04:49 +0000 Commit: Kyle Evans CommitDate: 2023-03-01 06:04:49 +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 MFC after: 1 week Sponsored by: Verisign, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D17884 --- 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 b30b1d29e205..1d243599e70c 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);