Re: [PATCH v4 00/20] drm/tyr: firmware loading and MCU boot support

[Deborah Brouwer <deborah.brouwer@collabora.com>]

On Tue, Apr 28, 2026 at 10:56:17AM +0000, Alice Ryhl wrote:
> On Mon, Apr 27, 2026 at 10:07:04AM +0200, Boris Brezillon wrote:
> > On Fri, 24 Apr 2026 16:38:54 -0700
> > Deborah Brouwer <deborah.brouwer@collabora.com> wrote:
> > 
> > > This series adds firmware loading and MCU boot support to the Tyr DRM
> > > driver. It includes:
> > >  - A parser for the Mali CSF firmware binary format
> > >  - A kernel-managed BO type (KernelBo) for internal driver allocations
> > >  - GPU virtual memory (VM) integration using drm_gpuvm
> > >  - An MMU module and a generic slot manager
> > >  - Shmem-backed GEM support for Tyr
> > >  - Loading firmware, VM activation, and MCU boot at probe()
> > >  - Initialization of Command Stream Frontend (CSF) firmware interfaces
> > > 
> > > Dependencies:
> > >  - [PATCH v12 0/5] Rust bindings for gem shmem
> > >     https://lore.kernel.org/rust-for-linux/20260421235346.672794-1-lyude@redhat.com
> > > 
> > >  - [PATCH v6 0/5] Rust GPUVM immediate mode
> > >     https://lore.kernel.org/rust-for-linux/20260409-gpuvm-rust-v6-0-b16e6ada7261@google.com/
> > > 
> > >  - [PATCH v6 0/5] Introduce DeviceContext
> > >     https://lore.kernel.org/rust-for-linux/20260320233645.950190-1-lyude@redhat.com/
> > > 
> > >  - [PATCH v5 0/6] drm/tyr: Use register! macro
> > >     https://lore.kernel.org/rust-for-linux/20260409-b4-tyr-use-register-macro-v5-v5-0-8abfff8a0204@collabora.com/
> > > 
> > > Other Prerequisites:
> > >  This series also depends on additional prerequisite fixes not included in
> > >  this posting. The full stack (base + prerequisites + this series) is
> > >  available here:
> > >   https://gitlab.freedesktop.org/dbrouwer/linux/-/tree/dbrouwer/fw-boot
> > >     
> > >   Development history / discussion:
> > >    https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/56
> > >     
> > > 
> > > ---
> > > Changes in v4:
> > >  New commits:
> > >   - drm/tyr: program CSF global interface
> > >   - rust: time: add arch_timer_get_rate wrapper
> > >   - drm/tyr: add CSF firmware interface support
> > >   - drm/tyr: validate presence of CSF shared section
> > >   - drm/tyr: wait for global interface readiness
> > >   - drm/tyr: add Job IRQ handling
> > >   - drm/tyr: add Wait type for GPU events
> > > 
> > >  The existing commits from v3 remain unchanged.
> > >  - Link to v3: https://lore.kernel.org/r/20260413-b4-fw-boot-v3-v3-0-b422f3c03885@collabora.com
> > >     
> > > Changes in v3:
> > >  New commits:
> > >   - drm/tyr: remove unused device from platform data
> > >   - drm/tyr: use shmem GEM object type in TyrDrmDriver
> > >     
> > >  drm/tyr: select required dependencies in Kconfig
> > >   - Rename commit since the dependencies are not limited to DRM.
> > >   - Select new RUST_DRM_GEM_SHMEM_HELPER instead of DRM_GEM_SHMEM_HELPER.
> > >     
> > >  drm/tyr: set DMA mask using GPU physical address
> > >   - Use register macro to read pa_bits instead of separate helper function.
> > >     
> > >  drm/tyr: add MMU module
> > >   - Switch MMU code to typed register APIs (TRANSCFG, MEMATTR, STATUS, LOCKADDR, etc.).
> > >   - Use MmuCommand enum for MMU commands instead of raw constants.
> > >   - Minor cleanups and renaming (MAX_AS, AS_PRESENT handling).
> > >     
> > >  drm/tyr: add GPU virtual memory module
> > >   - Extract VA/PA bits via typed MMU_FEATURES register.
> > >   - Update the VM code to match the new GPUVM v6 and shmem GEM v10 APIs.
> > >     
> > >  drm/tyr: add a kernel buffer object
> > >   - Reject zero-sized KernelBo allocations up front.
> > >     
> > >  drm/tyr: add firmware loading and MCU boot support
> > >   - Use typed GPU control registers.
> > >   - Pass iomem by Arc into Firmware::new() since we store it eventually.
> > >     
> > >   - Link to v2: https://lore.kernel.org/rust-for-linux/20260302232500.244489-1-deborah.brouwer@collabora.com/
> > >     
> > > Changes in v2:
> > >  - The whole series is rebased on drm-rust-next including v7.0-rc1.
> > >  - Each patch has its own changelog.
> > >     
> > >  Link to v1: https://lore.kernel.org/rust-for-linux/20260212013713.304343-1-deborah.brouwer@collabora.com/
> > > 
> > > Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
> > > 
> > > ---
> > > Alvin Sun (1):
> > >       drm/tyr: use shmem GEM object type in TyrDrmDriver
> > > 
> > > Beata Michalska (1):
> > >       drm/tyr: set DMA mask using GPU physical address
> > > 
> > > Boris Brezillon (5):
> > >       drm/tyr: select required dependencies in Kconfig
> > >       drm/tyr: rename TyrObject to BoData
> > >       drm/tyr: Add generic slot manager
> > >       drm/tyr: add MMU module
> > >       drm/tyr: add GPU virtual memory module
> > > 
> > > Daniel Almeida (1):
> > >       drm/tyr: add parser for firmware binary
> > > 
> > > Deborah Brouwer (12):
> > >       drm/tyr: remove unused device from platform data
> > >       drm/tyr: move clock cleanup into Clocks Drop impl
> > >       drm/tyr: add shmem backing for GEM objects
> > >       drm/tyr: add a kernel buffer object
> > >       drm/tyr: add firmware loading and MCU boot support
> > >       drm/tyr: add Wait type for GPU events
> > >       drm/tyr: add Job IRQ handling
> > >       drm/tyr: wait for global interface readiness
> > >       drm/tyr: validate presence of CSF shared section
> > >       drm/tyr: add CSF firmware interface support
> > >       rust: time: add arch_timer_get_rate wrapper
> > >       drm/tyr: program CSF global interface
> > 
> > This series starts to be quite big, and it seems new features have been
> > added to v4 (interactions with the FW). I'd recommend that we extract
> > the uncontroversial bits (I'd say patch 1-2, 4-7) or have them applied
> > to drm-rust-next right away. I know it's tempting to add features
> > between revisions, but the more you do that the longer it will take to
> > get the foundation merged.
> 
> How about I pick up patches 1, 3, 4, 5, 6, 7 for drm-rust-next now?

Don't pick patch 1 because it depends on the Device Context series.
The DRM device only because redundant once it's Registered, so we can't
remove it yet.

Patch 3: "drm/tyr: move clock cleanup into Clocks Drop impl" applies
cleanly to drm-rust-next so that could go.

Patches 4-7 need conflict resolution.

How about I prepare a new series of stuff that could go in
immediately and that will at least make this fw-boot series shorter?

> 
> Otherwise yeah I agree it's better to split up work and have multiple
> series that depend on each other, because then I can just pick up whole
> series on their own as they reach a finished state.

Ack.

> 
> Alice