From: Alice Ryhl <aliceryhl@google.com>
To: Deborah Brouwer <deborah.brouwer@collabora.com>
Cc: Daniel Almeida <daniel.almeida@collabora.com>,
Danilo Krummrich <dakr@kernel.org>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>, Benno Lossin <lossin@kernel.org>,
Gary Guo <gary@garyguo.net>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org, boris.brezillon@collabora.com,
samitolvanen@google.com, acourbot@nvidia.com,
alvin.sun@linux.dev, laura.nao@collabora.com,
work@onurozkan.dev, beata.michalska@arm.com,
steven.price@arm.com, lyude@redhat.com
Subject: Re: [PATCH v6 3/7] drm/tyr: add Memory Management Unit (MMU) support
Date: Fri, 10 Jul 2026 13:45:24 +0000 [thread overview]
Message-ID: <alD3dMEuYHduWlzp@google.com> (raw)
In-Reply-To: <20260709-fw-boot-b4-v6-3-ca391e1a4108@collabora.com>
On Thu, Jul 09, 2026 at 02:36:43PM -0700, Deborah Brouwer wrote:
> From: Boris Brezillon <boris.brezillon@collabora.com>
>
> Add Memory Management Unit (MMU) support in Tyr. The MMU module wraps a
> SlotManager instance to allocate MMU address-space slots for use by
> virtual memory (VM) address spaces. The MMU's SlotManager uses an
> AddressSpaceManager to handle the hardware-specific callbacks. For
> example, the AddressSpaceManager activates and evicts VMs from slots by
> writing commands to the MMU registers.
>
> Add an implementation block for the MMU's MEMATTR register to provide
> a method for translating the Memory Attribute Indirection Register (MAIR)
> format from the pagetable configuration to a format understood by the MMU.
>
> Create an mmu instance during probe, it will be used by subsequent patches
> in this series.
>
> Wrap the iomem stored in TyrDrmRegistrationData in an Arc. The iomem
> is stored in the mmu through its AddressSpaceManager. In anticipation
> of the iomem also being stored in the firmware object, set up shared
> ownership of the iomem now.
>
> Update Kconfig to add the new MMU and IOMMU dependencies required
> by this MMU module.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> Co-developed-by: Deborah Brouwer <deborah.brouwer@collabora.com>
> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
> +//! Memory Management Unit (MMU) module.
> +//!
> +//! The GPU MMU provides a limited number of memory address spaces for use by command streams.
> +//! The MMU translates virtual addresses to physical addresses and manages memory configuration
> +//! and access permissions.
> +//!
> +//! This MMU module is essentially a locked wrapper around a [`SlotManager`] instance.
> +//! The [`SlotManager`] manages the assignment of virtual address spaces to hardware address-space
> +//! (AS) slots. MMU commands such as updates and flushes are carried out by the
> +//! [`AddressSpaceManager`] which actually writes to the MMU registers.
> +#![allow(dead_code)]
This occurs in a few different commits, but I'd make sure to use
expect(dead_code) here so we are sure to remove it when everything is
used.
> +/// Virtual memory (VM) address space data for use in MMU operations.
> +#[pin_data]
> +pub(crate) struct VmAsData<'bound> {
> + /// The address space seat tracks this VM's binding to a hardware address space slot.
> + /// Uses [`LockedBy`] to ensure safe concurrent access to the slot assignment state,
> + /// protected by the [`AsSlotManager`] lock.
> + as_seat: LockedBy<Seat, AsSlotManager<'bound>>,
Why not use the LockedSeat type alias here?
> + let lockaddr_val = LOCKADDR::zeroed()
> + .try_with_size(lockaddr_size)?
> + .try_with_base(lockaddr_base)?
> + .into_raw();
Should this be:
let lockaddr_val = LOCKADDR::zeroed()
.try_with_size(lockaddr_size)?
.try_with_base(lockaddr_base >> 12)?
.into_raw();
or even just
let lockaddr_val = lockaddr_size | lockaddr_base;
?
Alice
next prev parent reply other threads:[~2026-07-10 13:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 21:36 [PATCH v6 0/7] drm/tyr: firmware loading and MCU boot support Deborah Brouwer
2026-07-09 21:36 ` [PATCH v6 1/7] drm/tyr: add resources to RegistrationData Deborah Brouwer
2026-07-09 21:36 ` [PATCH v6 2/7] drm/tyr: add a generic slot manager Deborah Brouwer
2026-07-10 13:23 ` Alice Ryhl
2026-07-09 21:36 ` [PATCH v6 3/7] drm/tyr: add Memory Management Unit (MMU) support Deborah Brouwer
2026-07-10 13:45 ` Alice Ryhl [this message]
2026-07-09 21:36 ` [PATCH v6 4/7] drm/tyr: add GPU virtual memory (VM) support Deborah Brouwer
2026-07-10 14:15 ` Alice Ryhl
2026-07-14 3:12 ` Deborah Brouwer
2026-07-10 14:27 ` Alice Ryhl
2026-07-09 21:36 ` [PATCH v6 5/7] drm/tyr: add a kernel buffer object Deborah Brouwer
2026-07-09 21:36 ` [PATCH v6 6/7] drm/tyr: add parser for firmware binary Deborah Brouwer
2026-07-09 21:36 ` [PATCH v6 7/7] drm/tyr: add Microcontroller Unit (MCU) booting Deborah Brouwer
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=alD3dMEuYHduWlzp@google.com \
--to=aliceryhl@google.com \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alvin.sun@linux.dev \
--cc=beata.michalska@arm.com \
--cc=boris.brezillon@collabora.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=deborah.brouwer@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=laura.nao@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.