linux-kernel - [PATCH 5.4 68/80] drm/nouveau/kms/nv50-: Limit MST BPC to 8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Dec 2019 19:35:00 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Lyude Paul <lyude@...hat.com>,
        Ben Skeggs <bskeggs@...hat.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        David Airlie <airlied@...hat.com>,
        Jerry Zuo <Jerry.Zuo@....com>,
        Harry Wentland <harry.wentland@....com>,
        Juston Li <juston.li@...el.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Sean Paul <seanpaul@...omium.org>
Subject: [PATCH 5.4 68/80] drm/nouveau/kms/nv50-: Limit MST BPC to 8

From: Lyude Paul <lyude@...hat.com>

commit ae5769d4670982bc483885b120b557a9ffd57527 upstream.

Noticed this while working on some unrelated CRC stuff. Currently,
userspace has very little support for BPCs higher than 8. While this
doesn't matter for most things, on MST topologies we need to be careful
about ensuring that we do our best to make any given display
configuration fit within the bandwidth restraints of the topology, since
otherwise less people's monitor configurations will work.

Allowing for BPC settings higher than 8 dramatically increases the
required bandwidth for displays in most configurations, and consequently
makes it a lot less likely that said display configurations will pass
the atomic check.

In the future we want to fix this correctly by making it so that we
adjust the bpp for each display in a topology to be as high as possible,
while making sure to lower the bpp of each display in the event that we
run out of bandwidth and need to rerun our atomic check. But for now,
follow the behavior that both i915 and amdgpu are sticking to.

Signed-off-by: Lyude Paul <lyude@...hat.com>
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs <bskeggs@...hat.com>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: David Airlie <airlied@...hat.com>
Cc: Jerry Zuo <Jerry.Zuo@....com>
Cc: Harry Wentland <harry.wentland@....com>
Cc: Juston Li <juston.li@...el.com>
Cc: Sam Ravnborg <sam@...nborg.org>
Cc: Sean Paul <seanpaul@...omium.org>
Cc: <stable@...r.kernel.org> # v5.1+
Signed-off-by: Ben Skeggs <bskeggs@...hat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 drivers/gpu/drm/nouveau/dispnv50/disp.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -798,7 +798,14 @@ nv50_msto_atomic_check(struct drm_encode
 	if (!state->duplicated) {
 		const int clock = crtc_state->adjusted_mode.clock;

-		asyh->or.bpc = connector->display_info.bpc;
+		/*
+		 * XXX: Since we don't use HDR in userspace quite yet, limit
+		 * the bpc to 8 to save bandwidth on the topology. In the
+		 * future, we'll want to properly fix this by dynamically
+		 * selecting the highest possible bpc that would fit in the
+		 * topology
+		 */
+		asyh->or.bpc = min(connector->display_info.bpc, 8U);
 		asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3);
 	}