On Wed, Sep 10, 2025 at 10:51:18AM -0300, Daniel Almeida wrote: > Add a Rust driver for ARM Mali CSF-based GPUs. It is a port of Panthor > and therefore exposes Panthor's uAPI and name to userspace, and the > product of a joint effort between Collabora, Arm and Google engineers. > > The aim is to incrementally develop Tyr with the abstractions that are > currently available until it is consider to be in parity with Panthor > feature-wise. > > The development of Tyr itself started in January, after a few failed > attempts of converting Panthor piecewise through a mix of Rust and C > code. There is a downstream branch that's much further ahead in terms of > capabilities than this initial patch. > > The downstream code is capable of booting the MCU, doing sync VM_BINDS > through the work-in-progress GPUVM abstraction and also doing (trivial) > submits through Asahi's drm_scheduler and dma_fence abstractions. So > basically, most of what one would expect a modern GPU driver to do, > except for power management and some other very important adjacent > pieces. It is not at the point where submits can correctly deal with > dependencies, or at the point where it can rotate access to the GPU > hardware fairly through a software scheduler, but that is simply a > matter of writing more code. > > This first patch, however, only implements a subset of the current > features available downstream, as the rest is not implementable without > pulling in even more abstractions. In particular, a lot of things depend > on properly mapping memory on a given VA range, which itself depends on > the GPUVM abstraction that is currently work-in-progress. For this > reason, we still cannot boot the MCU and thus, cannot do much for the > moment. > > This constitutes a change in the overall strategy that we have been > using to develop Tyr so far. By submitting small parts of the driver > upstream iteratively, we aim to: > > a) evolve together with Nova and rvkms, hopefully reducing regressions > due to upstream changes (that may break us because we were not there, in > the first place) > > b) prove any work-in-progress abstractions by having them run on a real > driver and hardware and, > > c) provide a reason to work on and review said abstractions by providing > a user, which would be tyr itself. > > Despite its limited feature-set, we offer IGT tests. It is only tested > on the rk3588, so any other SoC is probably not going to work at all for > now. > > The skeleton is basically taken from Nova and also > rust_platform_driver.rs. > > Lastly, the name "Tyr" is inspired by Norse mythology, reflecting ARM's > tradition of naming their GPUs after Nordic mythological figures and > places. > > Co-developed-by: Alice Ryhl <alicer...@google.com> > Signed-off-by: Alice Ryhl <alicer...@google.com> > Co-developed-by: Beata Michalska <beata.michal...@arm.com> > Signed-off-by: Beata Michalska <beata.michal...@arm.com> > Co-developed-by: Carsten Haitzler <carsten.haitz...@foss.arm.com> > Signed-off-by: Carsten Haitzler <carsten.haitz...@foss.arm.com> > Co-developed-by: Rob Herring <r...@kernel.org> > Signed-off-by: Rob Herring <r...@kernel.org> > > Link: > https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html > Signed-off-by: Daniel Almeida <daniel.alme...@collabora.com>
[aliceryhl: minor Kconfig update on apply] [aliceryhl: s/drm::device::/drm::/] Applied to drm-rust-next. Thanks!
