mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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



  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®