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

From: Deborah Brouwer

Date: Tue Apr 28 2026 - 13:07:59 EST


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@xxxxxxxxxxxxx> 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@xxxxxxxxxx
> > >
> > > - [PATCH v6 0/5] Rust GPUVM immediate mode
> > > https://lore.kernel.org/rust-for-linux/20260409-gpuvm-rust-v6-0-b16e6ada7261@xxxxxxxxxx/
> > >
> > > - [PATCH v6 0/5] Introduce DeviceContext
> > > https://lore.kernel.org/rust-for-linux/20260320233645.950190-1-lyude@xxxxxxxxxx/
> > >
> > > - [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@xxxxxxxxxxxxx/
> > >
> > > 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@xxxxxxxxxxxxx
> > >
> > > 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@xxxxxxxxxxxxx/
> > >
> > > 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@xxxxxxxxxxxxx/
> > >
> > > Signed-off-by: Deborah Brouwer <deborah.brouwer@xxxxxxxxxxxxx>
> > >
> > > ---
> > > 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