linux-kernel - [PATCH 4/5] drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel

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-next>] [day] [month] [year] [list]

Date:   Mon, 18 Jan 2021 20:48:48 -0500
From:   Lyude Paul <lyude@...hat.com>
To:     nouveau@...ts.freedesktop.org
Cc:     Martin Peres <martin.peres@...e.fr>,
        Jeremy Cline <jcline@...hat.com>,
        Simon Ser <contact@...rsion.fr>,
        Ben Skeggs <bskeggs@...hat.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Dave Airlie <airlied@...il.com>,
        dri-devel@...ts.freedesktop.org (open list:DRM DRIVER FOR NVIDIA
        GEFORCE/QUADRO GPUS), linux-kernel@...r.kernel.org (open list)
Subject: [PATCH 4/5] drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel

While working on igt support for nouveau, I noticed that CRC calculation
appeared to be broken when the cursor channel was being used. For example,
if I had an igt test that would compare a software rendered image of a
completely black fb with a green square in it, and then attempt to
reproduce that image by positioning the cursor channel and setting it to a
green rectangle, the CRCs output by the hardware would differ between the
reference fb's CRC and the output's CRC. This was bizarre particularly
because through use of the Chamelium I have, I was able to confirm that the
image coming out of the display was identical between the reference and
output. As well, the issue wouldn't happen when using the outp CRC sources
that use the SF CRC source (so, DisplayPort) - only sources using the SOR
CRC source (so, everything other then DisplayPort and VGA). It also didn't
happen with the ovly plane, only the cursor plane.

Eventually I noticed 0x00000040 being set in the default state cache values
for the CRC methods, which isn't in Nvidia's open-gpu-docs and as such
appears to be inadvertently cleared to 0s when we enable CRCs. After
enabling this again during CRC capture, CRCs appear to be calculated
normally in all circumstances now.

Note that we might need to do this for Volta+ as well, but I'm not
entirely sure yet as there seem to be some bugs with how Volta+ handles
cursors that are currently causing kms_cursor_crc tests to fail.

Cc: Martin Peres <martin.peres@...e.fr>
Cc: Jeremy Cline <jcline@...hat.com>
Cc: Simon Ser <contact@...rsion.fr>
Signed-off-by: Lyude Paul <lyude@...hat.com>
---
 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc907d.c b/drivers/gpu/drm/nouveau/dispnv50/crc907d.c
index 0a89ae9523d4..f9cb484437aa 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc907d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc907d.c
@@ -32,7 +32,8 @@ crc907d_set_src(struct nv50_head *head, int or, enum nv50_crc_source_type source
 		       NVDEF(NV907D, HEAD_SET_CRC_CONTROL, EXPECT_BUFFER_COLLAPSE, FALSE) |
 		       NVDEF(NV907D, HEAD_SET_CRC_CONTROL, TIMESTAMP_MODE, FALSE) |
 		       NVDEF(NV907D, HEAD_SET_CRC_CONTROL, SECONDARY_OUTPUT, NONE) |
-		       NVDEF(NV907D, HEAD_SET_CRC_CONTROL, CRC_DURING_SNOOZE, DISABLE);
+		       NVDEF(NV907D, HEAD_SET_CRC_CONTROL, CRC_DURING_SNOOZE, DISABLE) |
+		       0x00000040;
 	int ret;

 	switch (source) {
-- 
2.29.2