Rust for Linux List
 help / color / mirror / Atom feed
From: Daniel Almeida <daniel.almeida@collabora.com>
To: "Danilo Krummrich" <dakr@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Boris Brezillon" <boris.brezillon@collabora.com>
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	 linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: [PATCH 0/2] DRM 'feature' support for DRM drivers
Date: Mon, 19 Jan 2026 20:34:45 -0300	[thread overview]
Message-ID: <20260119-drm-render-v1-0-8326e4d5cb44@collabora.com> (raw)

This series introduces feature support for DRM drivers, as this will soon
be needed by Tyr and rvkms.

Patch 1 introduces the unsafe DriverFeatures trait. It underpins the design
by forcing drivers to comply with its safety requirements when enabling
features. It also introduces the compute_features() helper in order to
centralize the decision of which features to enable based on the value of
FeatureFoo::ENABLED.

Patch two showcases the design by implementing FEAT_RENDER. This adds a
safety requirement to the DriverFeatures trait that applies when the
corresponding feature is enabled. It is enabled on Tyr while Nova defaults
to NoRender, as it's unclear whether it's something that they want to
enable at the moment. This has the bonus of highlighting how features can
be disabled in a given driver in a non-disruptive manner.

Optionally, features can require that additional traits be implemented.
These traits may come with their own safety requirements and the type
system will ensure that they're indeed implemented if the feature is
enabled by the driver.

The commit message for patch one describes how this can be achieved in
rough terms. It's not a reference, though, as a lot of the boilerplate was
omitted for brevity. In any case, I tested an imaginary "ModesetOps" trait
in both Tyr and Nova and everything seems to work from a type system's
perspective.

Finally, the current approach is extensible as new features can be
described with traits and types without disrupting existing ones. They can
also convey their own safety requirements and even their own API, as
described above.

Please feel free to suggest new names for any of the types or patterns
used. They're somewhat illustrative and not intended as final.

---
Daniel Almeida (2):
      rust: drm: add support for driver features
      rust: drm: add FeatureRender

 drivers/gpu/drm/nova/driver.rs |  7 ++++++
 drivers/gpu/drm/tyr/driver.rs  | 11 +++++++++
 rust/kernel/drm/device.rs      | 14 +++++++++++-
 rust/kernel/drm/driver.rs      | 52 +++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 82 insertions(+), 2 deletions(-)
---
base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
change-id: 20260116-drm-render-e85e615641f6

Best regards,
-- 
Daniel Almeida <daniel.almeida@collabora.com>


             reply	other threads:[~2026-01-19 23:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-19 23:34 Daniel Almeida [this message]
2026-01-19 23:34 ` [PATCH 1/2] rust: drm: add support for driver features Daniel Almeida
2026-01-21 17:31   ` Gary Guo
2026-01-21 19:05     ` Daniel Almeida
2026-05-05 10:13     ` Laura Nao
2026-01-19 23:34 ` [PATCH 2/2] rust: drm: add FeatureRender Daniel Almeida

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=20260119-drm-render-v1-0-8326e4d5cb44@collabora.com \
    --to=daniel.almeida@collabora.com \
    --cc=a.hindborg@kernel.org \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    /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