Changes since v2:

The main change since v2 has been to make all firmware bindings
completely opaque. It has been made clear this is a pre-requisite for
this series to progress upstream as it should make supporting
different firmware versions easier in future.

Overall the extra constructors and accessors add a couple of hundred
lines of code and a few extra unsafe statements.

Other changes include addressing a bunch of other comments - see the
individual patches for further details. There are also still some
outstanding comments and TODO's to address which I have not gotten to
yet - these will be done in the next version of this series.

Changes since v1:

 - Based on feed back from Alex the GSP command queue logic was reworked
   extensively. This involved creating a new data struct (DmaGspMem) to
   manage the shared memory areas between CPU and GSP.

 - This data structure helps ensure the safety constraints are meet when
   the CPU is reading/writing the shared memory queues.

 - Several other minor comments were addressed, as noted in the individual
   patches.

This series builds on top of Alex's series[1], most of which has been
merged into drm-rust-next, to continue initialising the GSP into a state
where it becomes active and it starts communicating with the host. A tree
including these patches with the prerequisite patches is available at [2].

It includes patches to initialise several important data structures
required to boot the GSP. The biggest change is the implementation of the
command/message circular queue used to establish communication between GSP
and host in patch 6. Admittedly this patch is rather large - if necessary
it could be split into send and receive patches if people prefer.

This is required to configure and boot the GSP. However this series does
not get the GSP to a fully active state. Instead it gets it to a state
where the GSP sends a message to the host with a sequence of instructions
which need running to get to the active state. A subsequent series will
implement processing of this message and allow the GSP to get to the fully
active state.

A full tree including the prerequisites for this patch series is available
at https://github.com/apopple-nvidia/linux/tree/nova-core-for-upstream.

[1] - https://lore.kernel.org/rust-for-linux/20250911-nova_firmware-v5-0-5a8a33bddca1@nvidia.com/
[2] - https://github.com/apopple-nvidia/linux/tree/nova-core-for-upstream-v2

To: rust-for-linux@vger.kernel.org
To: dri-devel@lists.freedesktop.org
To: Danilo Krummrich <dakr@kernel.org>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Alex Gaynor <alex.gaynor@gmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Gary Guo <gary@garyguo.net>
Cc: Björn Roy Baron <bjorn3_gh@protonmail.com>
Cc: Benno Lossin <lossin@kernel.org>
Cc: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Trevor Gross <tmgross@umich.edu>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Timur Tabi <ttabi@nvidia.com>
Cc: linux-kernel@vger.kernel.org
Cc: nouveau@lists.freedesktop.org

Alistair Popple (10):
  gpu: nova-core: Set correct DMA mask
  gpu: nova-core: Create initial Gsp
  gpu: nova-core: gsp: Create wpr metadata
  gpu: nova-core: Add GSP command queue bindings
  gpu: nova-core: gsp: Add GSP command queue handling
  gpu: nova-core: gsp: Create rmargs
  gpu: nova-core: Add bindings and accessors for GspSystemInfo
  gpu: nova-core: Add bindings for the GSP RM registry tables
  gpu: nova-core: gsp: Create RM registry and sysinfo commands
  nova-core: gsp: Boot GSP

Joel Fernandes (3):
  gpu: nova-core: Add a slice-buffer (sbuffer) datastructure
  nova-core: falcon: Add support to check if RISC-V is active
  nova-core: falcon: Add support to write firmware version

 drivers/gpu/nova-core/driver.rs               |   8 +-
 drivers/gpu/nova-core/falcon.rs               |  16 +
 drivers/gpu/nova-core/fb.rs                   |   1 -
 drivers/gpu/nova-core/firmware/gsp.rs         |   3 +-
 drivers/gpu/nova-core/firmware/riscv.rs       |   9 +-
 drivers/gpu/nova-core/gpu.rs                  |   2 +-
 drivers/gpu/nova-core/gsp.rs                  | 111 +++-
 drivers/gpu/nova-core/gsp/boot.rs             |  77 ++-
 drivers/gpu/nova-core/gsp/cmdq.rs             | 419 +++++++++++++
 drivers/gpu/nova-core/gsp/commands.rs         | 101 +++
 drivers/gpu/nova-core/gsp/fw.rs               | 419 ++++++++++++-
 drivers/gpu/nova-core/gsp/fw/commands.rs      |  80 +++
 .../gpu/nova-core/gsp/fw/r570_144/bindings.rs | 577 ++++++++++++++++++
 drivers/gpu/nova-core/nova_core.rs            |   1 +
 drivers/gpu/nova-core/regs.rs                 |  15 +
 drivers/gpu/nova-core/sbuffer.rs              | 188 ++++++
 scripts/Makefile.build                        |   2 +-
 17 files changed, 2006 insertions(+), 23 deletions(-)
 create mode 100644 drivers/gpu/nova-core/gsp/cmdq.rs
 create mode 100644 drivers/gpu/nova-core/gsp/commands.rs
 create mode 100644 drivers/gpu/nova-core/gsp/fw/commands.rs
 create mode 100644 drivers/gpu/nova-core/sbuffer.rs

-- 
2.50.1

On 9/30/25 3:16 PM, Alistair Popple wrote:
> Changes since v2:
> 
> The main change since v2 has been to make all firmware bindings
> completely opaque. It has been made clear this is a pre-requisite for
> this series to progress upstream as it should make supporting
> different firmware versions easier in future.
> 
> Overall the extra constructors and accessors add a couple of hundred
> lines of code and a few extra unsafe statements.

A bit of additional code is expected, but it's not clear to me why this would
require additional unsafe blocks.

Can you please elaborate?

On 2025-09-30 at 23:26 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On 9/30/25 3:16 PM, Alistair Popple wrote:
> > Changes since v2:
> > 
> > The main change since v2 has been to make all firmware bindings
> > completely opaque. It has been made clear this is a pre-requisite for
> > this series to progress upstream as it should make supporting
> > different firmware versions easier in future.
> > 
> > Overall the extra constructors and accessors add a couple of hundred
> > lines of code and a few extra unsafe statements.
> 
> A bit of additional code is expected, but it's not clear to me why this would
> require additional unsafe blocks.
> 
> Can you please elaborate?

See patch 5 and 6 and specifically cpu_read_ptr(), etc. The message
headers are embedded in a structure within a DMA coherent mapping, `struct
DmaGspMem(CoherentAllocation<GspMem>)`, in cmdq.rs. Obviously we can't
call `dma_write!()` on them because we can't get to the opaque fields,
and even getting to the methods requires accessing the GspMem within the
CoherentAllocation which requires some unsafe code to get the CPU pointer.

I'm open to suggestions though, maybe I missed something as it was late when I
was trying to pull this all togeather.

On 9/30/25 6:16 AM, Alistair Popple wrote:
> Changes since v2:
> 
> The main change since v2 has been to make all firmware bindings
> completely opaque. It has been made clear this is a pre-requisite for

Any hints about where to see this aspect would be welcome. 

...

> A full tree including the prerequisites for this patch series is available
> at https://github.com/apopple-nvidia/linux/tree/nova-core-for-upstream.
> 
> [1] - https://lore.kernel.org/rust-for-linux/20250911-nova_firmware-v5-0-5a8a33bddca1@nvidia.com/
> [2] - https://github.com/apopple-nvidia/linux/tree/nova-core-for-upstream-v2

Could you maybe push up a nova-core-for-upstream-v3 branch please?


thanks,
-- 
John Hubbard

On 2025-10-01 at 12:02 +1000, John Hubbard <jhubbard@nvidia.com> wrote...
> On 9/30/25 6:16 AM, Alistair Popple wrote:
> > Changes since v2:
> > 
> > The main change since v2 has been to make all firmware bindings
> > completely opaque. It has been made clear this is a pre-requisite for
> 
> Any hints about where to see this aspect would be welcome. 

The changes to fw.rs in patch 5 for example.

> ...
> 
> > A full tree including the prerequisites for this patch series is available
> > at https://github.com/apopple-nvidia/linux/tree/nova-core-for-upstream.
> > 
> > [1] - https://lore.kernel.org/rust-for-linux/20250911-nova_firmware-v5-0-5a8a33bddca1@nvidia.com/
> > [2] - https://github.com/apopple-nvidia/linux/tree/nova-core-for-upstream-v2
> 
> Could you maybe push up a nova-core-for-upstream-v3 branch please?

Done.
 
> thanks,
> -- 
> John Hubbard
>