From: Boqun Feng <boqun@kernel.org>
To: "Onur Özkan" <work@onurozkan.dev>
Cc: dakr@kernel.org, aliceryhl@google.com,
daniel.almeida@collabora.com, airlied@gmail.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 0/4] drm/tyr: implement GPU reset API
Date: Thu, 16 Apr 2026 11:45:56 -0700 [thread overview]
Message-ID: <aeEuZKgnvaz2Y6WO@tardis.local> (raw)
In-Reply-To: <20260416172347.209317-1-work@onurozkan.dev>
On Thu, Apr 16, 2026 at 08:23:45PM +0300, Onur Özkan wrote:
> On Thu, 16 Apr 2026 20:17:26 +0300
> Onur Özkan <work@onurozkan.dev> wrote:
>
> > This series adds GPU reset handling support for Tyr in a new module
> > drivers/gpu/drm/tyr/driver.rs which encapsulates the low-level reset
> > controller internals and exposes a ResetHandle API to the driver.
> >
> > This series is based on Alice's "Creation of workqueues in Rust" [1]
> > series.
> >
> > Changes since v1:
> > - Removed OrderedQueue and using Alice's workqueue implementation [1] instead.
> > - Added Resettable trait with pre_reset and post_reset hooks to be implemented by
> > reset-managed hardwares.
> > - Added SRCU abstraction and used it to synchronize the reset work and hardware access.
> >
> > 3 important points:
> > - There is no hardware using this API yet.
> > - On post_reset() failure, we don't do anything for now. We should unplug the GPU (that's
> > what Panthor does) but we don't have the infrastructure for that yet (see [2]).
> > - In schedule(), similar to panthor_device_schedule_reset(), we should have a PM check
> > but similar to the note above, we don't have the infrastructure for that yet.
> >
> > Link: https://lore.kernel.org/all/20260312-create-workqueue-v4-0-ea39c351c38f@google.com/ [1]
> > Link: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/29#note_3391826 [2]
> > Link: https://gitlab.freedesktop.org/panfrost/linux/-/issues/28
> >
> > Onur Özkan (4):
> > rust: add SRCU abstraction
> > MAINTAINERS: add Rust SRCU files to SRCU entry
> > rust: add Work::disable_sync
> > drm/tyr: add reset management API
> >
> > MAINTAINERS | 3 +
> > drivers/gpu/drm/tyr/driver.rs | 40 +---
> > drivers/gpu/drm/tyr/reset.rs | 293 +++++++++++++++++++++++++++
> > drivers/gpu/drm/tyr/reset/hw_gate.rs | 155 ++++++++++++++
> > drivers/gpu/drm/tyr/tyr.rs | 1 +
> > rust/helpers/helpers.c | 1 +
> > rust/helpers/srcu.c | 18 ++
> > rust/kernel/sync.rs | 2 +
> > rust/kernel/sync/srcu.rs | 109 ++++++++++
> > rust/kernel/workqueue/mod.rs | 15 ++
> > 10 files changed, 607 insertions(+), 30 deletions(-)
> > create mode 100644 drivers/gpu/drm/tyr/reset.rs
> > create mode 100644 drivers/gpu/drm/tyr/reset/hw_gate.rs
> > create mode 100644 rust/helpers/srcu.c
> > create mode 100644 rust/kernel/sync/srcu.rs
> >
> > --
> > 2.51.2
> >
>
> I messed up when sending the series (part of it was sent as a separate series
> [1]. I will resend this properly, sorry for the noise.
>
FWIW, I didn't receive your patch #3 (even from my subscription on
rust-for-linux list).
Could you add a doc test for disable_sync(), I'm curious about it
because you may disable a work that has not be executed yet, and
wouldn't that be leaking memory (IIUC, we rely on Arc::drop() in
WorkItemPointer::run() to decrease the refcounts), but maybe I'm missing
something subtle.
Regards,
Boqun
> [1]: https://lore.kernel.org/all/20260416171728.205141-1-work@onurozkan.dev/
>
> -Onur
>
next prev parent reply other threads:[~2026-04-16 18:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 17:17 [PATCH v2 0/4] drm/tyr: implement GPU reset API Onur Özkan
2026-04-16 17:17 ` [PATCH v2 3/4] rust: add Work::disable_sync Onur Özkan
2026-04-16 17:17 ` [PATCH v2 4/4] drm/tyr: add reset management API Onur Özkan
2026-04-16 17:23 ` [PATCH v2 0/4] drm/tyr: implement GPU reset API Onur Özkan
2026-04-16 18:45 ` Boqun Feng [this message]
2026-04-17 8:02 ` Onur Özkan
2026-04-16 17:43 ` [PATCH v2 RESEND 1/4] rust: add SRCU abstraction Onur Özkan
2026-04-16 17:43 ` [PATCH v2 RESEND 2/4] MAINTAINERS: add Rust SRCU files to SRCU entry Onur Özkan
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=aeEuZKgnvaz2Y6WO@tardis.local \
--to=boqun@kernel.org \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=work@onurozkan.dev \
/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