mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hamin Sung <hamin@saltyming.net>
To: Lyude Paul <lyude@redhat.com>, Danilo Krummrich <dakr@kernel.org>
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-kernel@vger.kernel.org, David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Yonatan Maman <Ymaman@Nvidia.com>,
	Gal Shalom <GalShalom@Nvidia.com>,
	Ben Skeggs <bskeggs@nvidia.com>, Hamin Sung <hamin@saltyming.net>,
	stable@vger.kernel.org
Subject: [PATCH] drm/nouveau: request a privileged CE channel only on Kepler and later
Date: Sun,  4 Oct 2026 07:32:44 +0900	[thread overview]
Message-ID: <20261003223244.63133-1-hamin@saltyming.net> (raw)

Since commit 04e0481526e3 ("nouveau/dmem: Fix privileged error in copy
engine channel"), nouveau_accel_ce_init() always asks for a privileged
channel.  Privileged channels are only implemented by the Kepler and
later FIFO code, so on GPUs with a copy engine but an older FIFO (GT21x,
MCP89 and Fermi) nvkm_chan_new_() rejects the request, and every boot
logs:

  nouveau 0000:01:00.0: drm: failed to create ce channel, -22

On Fermi, TTM then cannot use the COPY0/COPY1 classes, which are only
available on the CE channel, and falls back to M2MF on the graphics
channel for buffer moves.  GT21x and MCP89 create their copy engine
object on the main channel, so there only the error message is visible.

The privileged channel is only needed by nouveau_dmem, which requires
Pascal or later.  Request it only where the FIFO supports it, and keep
using an unprivileged CE channel on older GPUs as before.

Fixes: 04e0481526e3 ("nouveau/dmem: Fix privileged error in copy engine channel")
Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/427
Assisted-by: Claude:claude-opus-5-5 sparse # max effort
Assisted-by: Claude:claude-fable-5-1 # max effort, review
Signed-off-by: Hamin Sung <hamin@saltyming.net>
---

Notes:
    Tested on a GeForce 310M (GT218) with 6.18.54: without this patch every
    boot logs "drm: failed to create ce channel, -22"; with it the message is
    gone.  Both kernels report "MM: using COPY for buffer copies", as GT21x
    creates its copy engine object on the main channel.  I have no Fermi to
    test the M2MF fallback described above, which comes from reading
    nouveau_bo_move_init().
    
    Found while setting up nouveau on that machine with an AI coding
    assistant, which also wrote the patch and ran the tests above on it;
    I have reviewed the patch and the test results.

 drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2c7077a49888..ddf6fb74f85a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -337,6 +337,7 @@ static void
 nouveau_accel_ce_init(struct nouveau_drm *drm)
 {
 	struct nvif_device *device = &drm->client.device;
+	bool priv;
 	u64 runm;
 	int ret = 0;
 
@@ -349,7 +350,14 @@ nouveau_accel_ce_init(struct nouveau_drm *drm)
 		return;
 	}
 
-	ret = nouveau_channel_new(&drm->client, true, runm, NvDmaFB, NvDmaTT, &drm->cechan);
+	/*
+	 * nouveau_dmem copies need a privileged channel, but only the Kepler
+	 * and later FIFO implementations support those; older ones reject the
+	 * request.
+	 */
+	priv = device->info.family >= NV_DEVICE_INFO_V0_KEPLER;
+
+	ret = nouveau_channel_new(&drm->client, priv, runm, NvDmaFB, NvDmaTT, &drm->cechan);
 	if (ret)
 		NV_ERROR(drm, "failed to create ce channel, %d\n", ret);
 }

base-commit: bca45af5998a05f34b13a2ef11e639bac9c62643
-- 
2.55.0



             reply	other threads:[~2026-10-03 22:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-03 22:32 Hamin Sung [this message]
2026-10-03 23:53 ` Lyude Paul
2026-10-04  0:26   ` Hamin Sung

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=20261003223244.63133-1-hamin@saltyming.net \
    --to=hamin@saltyming.net \
    --cc=GalShalom@Nvidia.com \
    --cc=Ymaman@Nvidia.com \
    --cc=airlied@gmail.com \
    --cc=bskeggs@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --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=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

all inboxes | Powered by JetHome®