All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lyude Paul <lyude@redhat.com>
To: nouveau@lists.freedesktop.org
Cc: Martin Peres <martin.peres@free.fr>,
	Jeremy Cline <jcline@redhat.com>, Simon Ser <contact@emersion.fr>,
	Ben Skeggs <bskeggs@redhat.com>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>, Dave Airlie <airlied@gmail.com>,
	dri-devel@lists.freedesktop.org (open list:DRM DRIVER FOR NVIDIA
	GEFORCE/QUADRO GPUS), linux-kernel@vger.kernel.org (open list)
Subject: [PATCH 4/5] drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel
Date: Mon, 18 Jan 2021 20:48:48 -0500	[thread overview]
Message-ID: <20210119014849.2509965-5-lyude@redhat.com> (raw)
In-Reply-To: <20210119014849.2509965-1-lyude@redhat.com>

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@free.fr>
Cc: Jeremy Cline <jcline@redhat.com>
Cc: Simon Ser <contact@emersion.fr>
Signed-off-by: Lyude Paul <lyude@redhat.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


WARNING: multiple messages have this Message-ID (diff)
From: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>,
	open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Subject: [PATCH 4/5] drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel
Date: Mon, 18 Jan 2021 20:48:48 -0500	[thread overview]
Message-ID: <20210119014849.2509965-5-lyude@redhat.com> (raw)
In-Reply-To: <20210119014849.2509965-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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-GANU6spQydw@public.gmane.org>
Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 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

WARNING: multiple messages have this Message-ID (diff)
From: Lyude Paul <lyude@redhat.com>
To: nouveau@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel@lists.freedesktop.org>,
	Jeremy Cline <jcline@redhat.com>, Ben Skeggs <bskeggs@redhat.com>
Subject: [PATCH 4/5] drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel
Date: Mon, 18 Jan 2021 20:48:48 -0500	[thread overview]
Message-ID: <20210119014849.2509965-5-lyude@redhat.com> (raw)
In-Reply-To: <20210119014849.2509965-1-lyude@redhat.com>

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@free.fr>
Cc: Jeremy Cline <jcline@redhat.com>
Cc: Simon Ser <contact@emersion.fr>
Signed-off-by: Lyude Paul <lyude@redhat.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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2021-01-19  1:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19  1:48 [PATCH 0/5] drm/nouveau: CRC fixes Lyude Paul
2021-01-19  1:48 ` [PATCH 1/5] drm/nouveau/kms/nv50-: Use drm_dbg_kms() in crc.c Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-01-19 10:25   ` Simon Ser
2021-01-19 10:25     ` Simon Ser
2021-01-19 10:25     ` Simon Ser
2021-01-19  1:48 ` [PATCH 2/5] drm/nouveau/kms/nv50-: Check vbl count after CRC context flip Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-01-19  1:48 ` [PATCH 3/5] drm/nouveau/kms/nv140-: Use hard-coded wndws or core channel for CRC channel Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-01-19  1:48 ` Lyude Paul [this message]
2021-01-19  1:48   ` [PATCH 4/5] drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-02-23 23:56   ` [PATCH v2] " Lyude Paul
2021-02-23 23:56     ` Lyude Paul
2021-02-23 23:56     ` [Nouveau] " Lyude Paul
2021-01-19  1:48 ` [PATCH 5/5] drm/nouveau/kms/nv140-: Add CRC methods to gv100_disp_core_mthd_head Lyude Paul
2021-01-19  1:48   ` Lyude Paul
2021-01-19  1:48   ` Lyude Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210119014849.2509965-5-lyude@redhat.com \
    --to=lyude@redhat.com \
    --cc=airlied@gmail.com \
    --cc=airlied@linux.ie \
    --cc=bskeggs@redhat.com \
    --cc=contact@emersion.fr \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jcline@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.peres@free.fr \
    --cc=nouveau@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.