From: Laura Nao <laura.nao@collabora.com>
To: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "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>,
"Tamir Duberstein" <tamird@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
"FUJITA Tomonori" <fujita.tomonori@gmail.com>,
"Frederic Weisbecker" <frederic@kernel.org>,
"Lyude Paul" <lyude@redhat.com>,
"Thomas Gleixner" <tglx@kernel.org>,
"Anna-Maria Behnsen" <anna-maria@linutronix.de>,
"John Stultz" <jstultz@google.com>,
"Stephen Boyd" <sboyd@kernel.org>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
driver-core@lists.linux.dev, rust-for-linux@vger.kernel.org,
kernel@collabora.com, Laura Nao <laura.nao@collabora.com>
Subject: [PATCH 3/9] drm/tyr: add MappedBo, a kernel BO with an always-valid CPU mapping
Date: Tue, 15 Sep 2026 12:57:36 +0200 [thread overview]
Message-ID: <20260915-tyr-interfaces-v1-3-5d28f1f75aca@collabora.com> (raw)
In-Reply-To: <20260915-tyr-interfaces-v1-0-5d28f1f75aca@collabora.com>
From: Daniel Almeida <daniel.almeida@collabora.com>
Firmware sections need CPU access at well-defined points: once at load
time to copy the section payload in, and, for the shared section, for
the lifetime of the driver to talk to the CSF interface blocks.
Introduce MappedBo, which pairs a KernelBo with one persistent vmap so
the GPU mapping and the CPU mapping share a single lifetime, and hold it
in Section instead of the bare KernelBo. Section payload initialization
now writes through the persistent mapping.
This is the foundation for resolving firmware-reported MCU virtual
addresses into validated views of the shared section: the object that
owns both mappings is the natural place for those checks to live.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Laura Nao <laura.nao@collabora.com>
---
drivers/gpu/drm/tyr/fw.rs | 14 ++++++-------
drivers/gpu/drm/tyr/gem.rs | 49 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tyr/fw.rs b/drivers/gpu/drm/tyr/fw.rs
index 19bdeee858ce..fb4d47ab35a3 100644
--- a/drivers/gpu/drm/tyr/fw.rs
+++ b/drivers/gpu/drm/tyr/fw.rs
@@ -144,7 +144,7 @@ struct Section<'drm> {
// Keep the BO backing this firmware section so that both the
// GPU mapping and CPU mapping remain valid until the Section is dropped.
#[expect(dead_code)]
- mem: gem::KernelBo<'drm>,
+ mem: Arc<gem::MappedBo<'drm>>,
}
/// Loaded firmware with sections mapped into MCU VM.
@@ -171,13 +171,13 @@ fn drop(&mut self) {
}
impl<'drm> Firmware<'drm> {
- fn init_section_mem(dev: &Device, mem: &mut KernelBo<'drm>, data: &KVec<u8>) -> Result {
+ fn init_section_mem(dev: &Device, mem: &gem::MappedBo<'drm>, data: &KVec<u8>) -> Result {
if data.is_empty() {
return Ok(());
}
- let vmap = mem.bo().vmap::<0>()?;
- let size = mem.bo().size();
+ let vmap = mem.vmap();
+ let size = mem.size();
if data.len() > size {
dev_err!(dev, "fw section {} bigger than BO {}", data.len(), size);
@@ -235,13 +235,13 @@ pub(crate) fn new(
let va = u64::from(parsed.va.start);
- let mut mem = KernelBo::new(
+ let mem = gem::MappedBo::new(KernelBo::new(
ddev,
vm.clone(),
size,
KernelBoVaAlloc::Explicit(va),
parsed.vm_map_flags,
- )?;
+ )?)?;
let section_start = parsed.data_range.start as usize;
let section_end = parsed.data_range.end as usize;
@@ -252,7 +252,7 @@ pub(crate) fn new(
let bytes = fw_data.get(section_start..section_end).ok_or(EINVAL)?;
data.extend_from_slice(bytes, GFP_KERNEL)?;
- Self::init_section_mem(dev, &mut mem, &data)?;
+ Self::init_section_mem(dev, &mem, &data)?;
sections.push(Section { data, mem }, GFP_KERNEL)?;
}
diff --git a/drivers/gpu/drm/tyr/gem.rs b/drivers/gpu/drm/tyr/gem.rs
index 3bf3787f5c3f..4763b5b2cd80 100644
--- a/drivers/gpu/drm/tyr/gem.rs
+++ b/drivers/gpu/drm/tyr/gem.rs
@@ -136,6 +136,12 @@ pub(crate) fn new(
pub(crate) fn bo(&self) -> &Bo {
&self.bo
}
+
+ /// Returns the GPU virtual address range occupied by this buffer.
+ #[expect(dead_code)]
+ pub(crate) fn va_range(&self) -> Range<u64> {
+ self.va_range.clone()
+ }
}
impl Drop for KernelBo<'_> {
@@ -158,3 +164,46 @@ fn drop(&mut self) {
}
}
}
+
+/// A kernel-owned buffer object with an always-valid kernel (CPU) mapping.
+///
+/// This pairs a [`KernelBo`] with a persistent vmap of its backing GEM object,
+/// so the GPU mapping and the CPU mapping share one lifetime. Consumers that
+/// need CPU access to the buffer contents (e.g. the firmware interface blocks
+/// in the CSF shared section) hold an `Arc<MappedBo>` instead of creating
+/// short-lived vmaps at every use site.
+pub(crate) struct MappedBo<'drm> {
+ /// Persistent CPU mapping of `kernel_bo`'s backing object.
+ ///
+ /// Declared before `kernel_bo` so the mapping is dropped first.
+ vmap: shmem::VMapOwned<BoData>,
+ /// The underlying kernel-owned buffer object.
+ #[expect(dead_code)]
+ kernel_bo: KernelBo<'drm>,
+}
+
+impl<'drm> MappedBo<'drm> {
+ /// Wraps `kernel_bo` together with a persistent CPU mapping of its buffer.
+ pub(crate) fn new(kernel_bo: KernelBo<'drm>) -> Result<Arc<Self>> {
+ let vmap = kernel_bo.bo.owned_vmap::<0>()?;
+ Ok(Arc::new(Self { vmap, kernel_bo }, GFP_KERNEL)?)
+ }
+
+ /// Returns the persistent CPU mapping of the buffer.
+ pub(crate) fn vmap(&self) -> &shmem::VMapOwned<BoData> {
+ &self.vmap
+ }
+
+ /// Returns the GPU virtual address range occupied by the buffer.
+ pub(crate) fn va_range(&self) -> Range<u64> {
+ self.kernel_bo.va_range()
+ }
+}
+
+impl core::ops::Deref for MappedBo<'_> {
+ type Target = Bo;
+
+ fn deref(&self) -> &Bo {
+ self.vmap.owner()
+ }
+}
--
2.39.5
next prev parent reply other threads:[~2026-09-15 10:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 10:57 [PATCH 0/9] drm/tyr: add CSF firmware interface support Laura Nao
2026-09-15 10:57 ` [PATCH 1/9] drm/tyr: validate presence of CSF shared section Laura Nao
2026-09-15 10:57 ` [PATCH 2/9] rust: io: drop the CONFIG_64BIT restriction on system memory u64 access Laura Nao
2026-09-15 11:18 ` Gary Guo
2026-09-15 10:57 ` Laura Nao [this message]
2026-09-15 10:57 ` [PATCH 4/9] drm/tyr: add McuVa and claim-checked MappedBo views Laura Nao
2026-09-15 10:57 ` [PATCH 5/9] drm/tyr: drop unused KernelBo::bo() function Laura Nao
2026-09-15 10:57 ` [PATCH 6/9] drm/tyr: add CSF firmware interface support Laura Nao
2026-09-15 10:57 ` [PATCH 7/9] rust: time: add arch_timer_get_rate wrapper Laura Nao
2026-09-15 10:57 ` [PATCH 8/9] drm/tyr: program CSF global interface Laura Nao
2026-09-15 10:57 ` [PATCH 9/9] drm/tyr: wait for global interface readiness Laura Nao
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=20260915-tyr-interfaces-v1-3-5d28f1f75aca@collabora.com \
--to=laura.nao@collabora.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=anna-maria@linutronix.de \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=frederic@kernel.org \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=jstultz@google.com \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=simona@ffwll.ch \
--cc=tamird@kernel.org \
--cc=tglx@kernel.org \
--cc=tmgross@umich.edu \
--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
all inboxes | Powered by JetHome®