From: Lyude Paul <lyude@redhat.com>
To: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Cc: Dave Airlie <airlied@gmail.com>,
Danilo Krummrich <dakr@kernel.org>,
Dave Airlie <airlied@redhat.com>, Timur Tabi <ttabi@nvidia.com>,
Suraj Kandpal <suraj.kandpal@intel.com>,
James Jones <jajones@nvidia.com>,
Faith Ekstrand <faith.ekstrand@collabora.com>,
stable@vger.kernel.org,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Ben Skeggs" <bskeggs@nvidia.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Maxime Ripard" <mripard@kernel.org>,
"Lyude Paul" <lyude@redhat.com>
Subject: [PATCH] drm/nouveau/kms/nvd9-: Use contiguous memory for CRC notifier context
Date: Fri, 1 May 2026 17:58:55 -0400 [thread overview]
Message-ID: <20260501215856.840898-1-lyude@redhat.com> (raw)
It looks like CRC read back has been slightly broken for a while now, in
particular on GPUs using GSP. On my test machines, it's worked normally
when attempting to use it from fbcon. After gnome-shell gets started
however, attempting to read /sys/kernel/debug/dri/$CARD/$CRTC/crc/data just
returns -EINVAL.
It turns out what's been happening is that since we've been using
nvif_mem_ctor_map() to both allocate and map the CRC notifier region - we
haven't actually asked for a contiguous allocation, and simply ask for
whatever type of memory allocation nouveau can find first. This doesn't
work because the CRC engine on nvidia GPUs doesn't support non-contiguous
allocations, which also causes us to fail setting up the kmsCrcNtfyCtxDma
object on pre-blackwell platforms since we don't have a single memory
address we can point nvif_object_ctor() to. Instead, ctx->mem.addr gets set
to ~0ULL.
It does however, seem to work when fbcon is running. The only reason I can
think of this is that before we start up a display environment, there is
pretty much nothing allocated in our VRAM that wasn't allocated by nouveau
itself - making it dramatically more likely that we end up finding a
contiguous allocation by default.
So, fix this by manually requesting a contiguous allocation when we
allocate our context notifiers.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support")
Cc: Lyude Paul <lyude@redhat.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Timur Tabi <ttabi@nvidia.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: James Jones <jajones@nvidia.com>
Cc: Faith Ekstrand <faith.ekstrand@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.9+
---
drivers/gpu/drm/nouveau/dispnv50/crc.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c b/drivers/gpu/drm/nouveau/dispnv50/crc.c
index deb6af40ef328..5817f39934a8b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
@@ -10,6 +10,7 @@
#include <nvif/class.h>
#include <nvif/cl0002.h>
#include <nvif/timer.h>
+#include <nvif/if900b.h>
#include <nvhw/class/cl907d.h>
@@ -499,16 +500,24 @@ nv50_crc_raster_type(enum nv50_crc_source source)
* notifier needs it's own handle
*/
static inline int
-nv50_crc_ctx_init(struct nv50_head *head, struct nvif_mmu *mmu,
+nv50_crc_ctx_init(struct drm_device *dev, struct nv50_head *head, struct nvif_mmu *mmu,
struct nv50_crc_notifier_ctx *ctx, size_t len, int idx)
{
- struct nv50_core *core = nv50_disp(head->base.base.dev)->core;
+ struct nv50_core *core = nv50_disp(dev)->core;
int ret;
- ret = nvif_mem_ctor_map(mmu, "kmsCrcNtfy", NVIF_MEM_VRAM, len, &ctx->mem);
+ /* The display engine requires a contiguous region of memory for the CRC notifier context */
+ ret = nvif_mem_ctor(mmu, "kmsCrcNtfy", mmu->mem, NVIF_MEM_VRAM | NVIF_MEM_MAPPABLE, 0, len,
+ &(struct gf100_mem_v0) {
+ .contig = true,
+ }, sizeof(struct gf100_mem_v0), &ctx->mem);
if (ret)
return ret;
+ ret = nvif_object_map(&ctx->mem.object, NULL, 0);
+ if (ret)
+ goto fail_fini;
+
/* No CTXDMAs on Blackwell. */
if (core->chan.base.user.oclass >= GB202_DISP_CORE_CHANNEL_DMA)
return 0;
@@ -576,7 +585,7 @@ int nv50_crc_set_source(struct drm_crtc *crtc, const char *source_str)
if (source) {
for (i = 0; i < ARRAY_SIZE(head->crc.ctx); i++) {
- ret = nv50_crc_ctx_init(head, mmu, &crc->ctx[i],
+ ret = nv50_crc_ctx_init(dev, head, mmu, &crc->ctx[i],
func->notifier_len, i);
if (ret)
goto out_ctx_fini;
base-commit: 29d6da40d0b8bf3bbc3dcd1d2198434a0e1f71b0
--
2.54.0
next reply other threads:[~2026-05-01 21:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 21:58 Lyude Paul [this message]
2026-05-04 4:01 ` [PATCH] drm/nouveau/kms/nvd9-: Use contiguous memory for CRC notifier context Dave Airlie
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=20260501215856.840898-1-lyude@redhat.com \
--to=lyude@redhat.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=bskeggs@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith.ekstrand@collabora.com \
--cc=jajones@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
--cc=suraj.kandpal@intel.com \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox