From: Daniel Almeida <daniel.almeida@collabora.com>
To: Laura Nao <laura.nao@collabora.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.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>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
driver-core@lists.linux.dev, rust-for-linux@vger.kernel.org,
kernel@collabora.com
Subject: Re: [PATCH 4/9] drm/tyr: add McuVa and claim-checked MappedBo views
Date: Wed, 23 Sep 2026 17:42:13 -0300 [thread overview]
Message-ID: <C027787C-A04B-40AC-B0EF-62F0BBC156F9@collabora.com> (raw)
In-Reply-To: <20260915-tyr-interfaces-v1-4-5d28f1f75aca@collabora.com>
Hi Laura,
It’s been a while since I wrote this, and I now see this could use some
improvements.
I think the first problem is that this conflates "MappedBo" with "the MappedBo
backing the shared region". As soon as we try to add more users, this will be a
problem. I propose that we split this into two types that build upon each other:
a) a generic layer MappedBo, which remains roughly as-is:
gem.rs:
pub(crate) struct MappedBo<'drm> {
vmap: shmem::VMapOwned<BoData>,
bo: KernelBo<'drm>,
}
impl<'drm> MappedBo<'drm> {
// pub(crate) API:
// no Arc, McuMappedBo has to hold it by value, otherwise a second holder
// could write around the claims.
fn new(bo: KernelBo<'drm>) -> Result<Self>
fn va_range(...) -> ...
fn vmap(...) -> ...
}
impl Deref for MappedBo<'_> { type Target = Bo ... }
b) A MCU-specific BO type with the claims + offset logic:
fw/mcu_bo.rs:
pub(super) struct McuVa(...) + related McuVa impls.
#[pin_data]
pub(super) struct McuMappedBo<'drm> {
bo: MappedBo<'drm>, // private, no accessor
#[pin]
claims: Mutex<KVec<Range<u64>>>
}
impl<'drm> McuMappedBo<'drm> {
// pub super API
// builds its own MappedBo, checks the 32-bit range before allocating and
// copies the section data from the fw binary before any view can exist.
new(ddev, mcu_vm: Arc<Vm<'drm>>, va: McuVa, size: u64, flags: VmMapFlags,
data: &[u8]) -> Result<impl PinInit<Self,Error>> {...}
// views borrow: &'a self instead of self: &Arc<Self>
fn try_view<'a>(&'a self, va: McuVa, len: u64, reach: u64)
-> Result<McuView<'a>>
fn try_view_mut<'a>(&'a self, va: McuVa, len: u64, reach: u64)
-> Result<McuViewMut<'a>>
}
c) Views get renamed to McuView, McuViewMut:
#[derive(Clone)]
pub(super) struct McuView<'a> {
vmap: &'a VMapOwned<BoData>,
base: u64,
range: Range<u64>,
reach: u64, // <———— Store this
}
pub(super) struct McuViewMut<'a> {
view: McuView<'a>,
claims: &'a Mutex<KVec<Range<u64>>>,
}
impl<'a> Deref for McuViewMut<'a> {
type Target = McuView<'a>;
fn deref(&self) -> &Self::Target {
&self.view
}
}
impl Drop for McuViewMut<'_> {
// return claim here.
}
>
> +// SAFETY: `MappedBo` may move between threads: the CPU mapping's address is
> +// valid from any thread; `KernelBo`'s teardown (GPU unmap through `Arc<Vm>`
> +// and the GEM object release) goes through thread-safe C APIs; and the only
> +// interior mutability (`claims`) is mutex-protected.
> +unsafe impl Send for MappedBo<'_> {}
> +// SAFETY: `&MappedBo` exposes the mutex-protected claims table, the `Deref`
> +// surface to the GEM object (thread-safe C APIs), and the mapping itself,
> +// whose contents are only ever accessed through volatile operations. The
> +// memory is shared with the MCU by design, so concurrent access is part of
> +// the model rather than a race the type system must rule out.
> +unsafe impl Sync for MappedBo<'_> {}
I don’t think we need a manual implementation here.
The rest of the patch looks good to me.
— Daniel
next prev parent reply other threads:[~2026-09-23 20:43 UTC|newest]
Thread overview: 20+ 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-23 13:59 ` Daniel Almeida
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-21 10:06 ` Laura Nao
2026-09-15 10:57 ` [PATCH 3/9] drm/tyr: add MappedBo, a kernel BO with an always-valid CPU mapping Laura Nao
2026-09-23 20:43 ` Daniel Almeida
2026-09-15 10:57 ` [PATCH 4/9] drm/tyr: add McuVa and claim-checked MappedBo views Laura Nao
2026-09-23 20:42 ` Daniel Almeida [this message]
2026-09-15 10:57 ` [PATCH 5/9] drm/tyr: drop unused KernelBo::bo() function Laura Nao
2026-09-23 20:45 ` Daniel Almeida
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-22 12:57 ` Andreas Hindborg
2026-09-22 14:23 ` FUJITA Tomonori
2026-09-22 19:56 ` Gary Guo
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
2026-09-23 8:50 ` Alice Ryhl
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=C027787C-A04B-40AC-B0EF-62F0BBC156F9@collabora.com \
--to=daniel.almeida@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=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=laura.nao@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®