From: Vladislav Zaharov <vladazaharova2018@gmail.com>
To: dakr@kernel.org, jhubbard@nvidia.com
Cc: acourbot@nvidia.com, aliceryhl@google.com, ttabi@nvidia.com,
gary@garyguo.net, nova-gpu@lists.linux.dev,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org,
Vladislav Zaharov <vladazaharova2018@gmail.com>
Subject: [PATCH v6 0/3] gpu: nova-core: retain the GSP-RM log buffers
Date: Wed, 14 Oct 2026 22:45:51 +0700 [thread overview]
Message-ID: <20261014154554.231015-1-vladazaharova2018@gmail.com> (raw)
The GSP-RM log buffers are exposed through debugfs, but they are DMA
allocations of the device, so they go away as soon as the GPU is unbound,
and in particular when probe() fails. That is the case todo.rst asks
about, and the one where a GSP log is most useful.
Patch 1 moves the debugfs root into the module data. Patch 2 adds a
gsp_keep_logs module parameter: when it is set, whatever the GSP wrote
is copied into module memory and kept under a "retained" directory until
the module is unloaded. Patch 3 drops the completed item from todo.rst.
v5 got no comments, so this version only carries one fix and a rebase.
Changes since v5:
- keep the "put" pointer read before the barrier in the copy, rather
than the one the copy reads again, which is not ordered against the
rest of the data (reported by the Sashiko review bot)
- rebase onto current drm-rust-next
Tested on a GB203 on top of drm-rust-next with the TLV firmware images:
- without gsp_keep_logs nothing changes, and no "retained" directory
is created;
- with gsp_keep_logs=1, retained/<BDF>/{loginit,logintr,logrm} hold
the full 64 KiB of each buffer after unbind;
- binding again does not disturb the copies, and a second unbind
replaces them, leaving one set;
- with a failure injected after the GSP has booted, probe() fails with
-EINVAL and the logs of that attempt are still readable;
- with a failure injected into the driver registration, the module
fails to load, leaves no debugfs directory behind, and the next load
works;
- repeated load/unload cycles leave nothing behind.
No warnings or oopses in dmesg. Each patch builds on its own, and the
series is clean with CLIPPY=1, rustfmtcheck and checkpatch --strict
(apart from the MAINTAINERS note for the new file, which is already
covered by "F: drivers/gpu/nova-core/").
v5: https://lore.kernel.org/nova-gpu/20260923045551.229259-1-vladazaharova2018@gmail.com/
Vladislav Zaharov (3):
gpu: nova-core: move the debugfs root into the module data
gpu: nova-core: gsp: retain the GSP-RM log buffers after unbind
Documentation: nova: remove completed GSP log buffer task
Documentation/gpu/nova/core/todo.rst | 12 --
drivers/gpu/nova-core/gsp.rs | 100 ++--------
drivers/gpu/nova-core/gsp/logbuffer.rs | 255 +++++++++++++++++++++++++
drivers/gpu/nova-core/nova_core.rs | 101 ++++++++--
4 files changed, 356 insertions(+), 112 deletions(-)
create mode 100644 drivers/gpu/nova-core/gsp/logbuffer.rs
base-commit: 5a1b7121a6c4db6c0239d3ac3fd1c2bb33a40025
--
2.56.0
next reply other threads:[~2026-10-14 15:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 15:45 Vladislav Zaharov [this message]
2026-10-14 15:45 ` [PATCH v6 1/3] gpu: nova-core: move the debugfs root into the module data Vladislav Zaharov
2026-10-14 15:45 ` [PATCH v6 2/3] gpu: nova-core: gsp: retain the GSP-RM log buffers after unbind Vladislav Zaharov
2026-10-14 15:45 ` [PATCH v6 3/3] Documentation: nova: remove completed GSP log buffer task Vladislav Zaharov
2026-11-06 20:51 ` [PATCH v6 0/3] gpu: nova-core: retain the GSP-RM log buffers Timur Tabi
2026-11-06 22:52 ` Danilo Krummrich
2026-11-06 23:15 ` John Hubbard
2026-11-06 23:08 ` Alexandre Courbot
2026-11-06 23:15 ` Alexandre Courbot
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=20261014154554.231015-1-vladazaharova2018@gmail.com \
--to=vladazaharova2018@gmail.com \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ttabi@nvidia.com \
/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®