All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Ben Skeggs" <bskeggs@nvidia.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 14/20] gpu: nova-core: add falcon register definitions and base code
Date: Mon, 2 Jun 2025 14:06:14 +0200	[thread overview]
Message-ID: <aD2Ttry3arneEzSd@pollux> (raw)
In-Reply-To: <20250521-nova-frts-v4-14-05dfd4f39479@nvidia.com>

On Wed, May 21, 2025 at 03:45:09PM +0900, Alexandre Courbot wrote:
> Add the common Falcon code and HAL for Ampere GPUs, and instantiate the
> GSP and SEC2 Falcons that will be required to boot the GSP.

Maybe add a few more words about the architectural approach taken here?

> +/// Valid values for the `size` field of the [`crate::regs::NV_PFALCON_FALCON_DMATRFCMD`] register.
> +#[repr(u8)]
> +#[derive(Debug, Default, Copy, Clone, PartialEq, Eq)]
> +pub(crate) enum DmaTrfCmdSize {
> +    /// 256 bytes transfer.
> +    #[default]
> +    Size256B = 0x6,

Can we use a constant from `regs` to assign this value? Or is *this* meant to be
the corresponding constant?

> +}

I wonder what's the correct thing to do for enum variants that do *not* have an
arbitrary value, but match a specific register value in general.

Should those be part of the `regs` module?

> +    /// Wait for memory scrubbing to complete.
> +    fn reset_wait_mem_scrubbing(&self, bar: &Bar0) -> Result {
> +        util::wait_on(Duration::from_millis(20), || {

I general, I think there can be quite a lot of parameters such timeouts can
depend on, e.g. chipset, firmware version, etc.

I think it could make sense to establish a rule for the project that for such
timeouts we require a dedicated `// TIMEOUT: ` comment that mentions the worst
case scenario, which we derived this timeout value from.

> +    /// Perform a DMA write according to `load_offsets` from `dma_handle` into the falcon's
> +    /// `target_mem`.
> +    ///
> +    /// `sec` is set if the loaded firmware is expected to run in secure mode.
> +    fn dma_wr(
> +        &self,
> +        bar: &Bar0,
> +        dma_handle: bindings::dma_addr_t,
> +        target_mem: FalconMem,
> +        load_offsets: FalconLoadTarget,
> +        sec: bool,
> +    ) -> Result {
> +        const DMA_LEN: u32 = 256;
> +
> +        // For IMEM, we want to use the start offset as a virtual address tag for each page, since
> +        // code addresses in the firmware (and the boot vector) are virtual.
> +        //
> +        // For DMEM we can fold the start offset into the DMA handle.
> +        let (src_start, dma_start) = match target_mem {
> +            FalconMem::Imem => (load_offsets.src_start, dma_handle),
> +            FalconMem::Dmem => (
> +                0,
> +                dma_handle + load_offsets.src_start as bindings::dma_addr_t,

We should make this a method of CoherentAllocation, such that we can get a
boundary check on the offset calculation.

For this purpose dma_rw() should also have the `F: FalconFirmware<Target = E>`
generic I think.

(No worries about the dependencies; I can create a shared tag for the DMA
patches and merge it into the nova tree, such that it doesn't block this
series.)

> +            // Wait for the transfer to complete.
> +            util::wait_on(Duration::from_millis(2000), || {

Yeah, I really think some timeout justification would be nice.

> +/// Hardware Abstraction Layer for Falcon cores.
> +///
> +/// Implements chipset-specific low-level operations. The trait is generic against [`FalconEngine`]
> +/// so its `BASE` parameter can be used in order to avoid runtime bound checks when accessing
> +/// registers.
> +pub(crate) trait FalconHal<E: FalconEngine>: Sync {
> +    // Activates the Falcon core if the engine is a risvc/falcon dual engine.
> +    fn select_core(&self, _falcon: &Falcon<E>, _bar: &Bar0) -> Result<()> {
> +        Ok(())
> +    }
> +
> +    /// Returns the fused version of the signature to use in order to run a HS firmware on this
> +    /// falcon instance. `engine_id_mask` and `ucode_id` are obtained from the firmware header.
> +    fn get_signature_reg_fuse_version(

Unless the method increases a reference count, please don't use the 'get'
prefix.

> +        &self,
> +        falcon: &Falcon<E>,
> +        bar: &Bar0,
> +        engine_id_mask: u16,
> +        ucode_id: u8,
> +    ) -> Result<u32>;
> +
> +    // Program the boot ROM registers prior to starting a secure firmware.
> +    fn program_brom(&self, falcon: &Falcon<E>, bar: &Bar0, params: &FalconBromParams)
> +        -> Result<()>;
> +}
> +
> +impl Chipset {
> +    /// Returns a boxed falcon HAL adequate for this chipset.
> +    ///
> +    /// We use a heap-allocated trait object instead of a statically defined one because the
> +    /// generic `FalconEngine` argument makes it difficult to define all the combinations
> +    /// statically.
> +    ///
> +    /// TODO: replace the return type with `KBox` once it gains the ability to host trait objects.

I think we can do this for v5. :-)

  parent reply	other threads:[~2025-06-02 12:06 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21  6:44 [PATCH v4 00/20] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Alexandre Courbot
2025-05-21  6:44 ` [PATCH v4 01/20] rust: dma: expose the count and size of CoherentAllocation Alexandre Courbot
2025-05-21  8:00   ` Danilo Krummrich
2025-05-22  5:24     ` Alexandre Courbot
2025-05-21 12:43   ` Boqun Feng
2025-05-21 15:57     ` Joel Fernandes
2025-05-21 15:59       ` Joel Fernandes
2025-05-22  5:29     ` Alexandre Courbot
2025-06-02  9:24       ` Danilo Krummrich
2025-05-21  6:44 ` [PATCH v4 02/20] rust: make ETIMEDOUT error available Alexandre Courbot
2025-05-21  7:27   ` Benno Lossin
2025-05-21  6:44 ` [PATCH v4 03/20] rust: sizes: add constants up to SZ_2G Alexandre Courbot
2025-05-21 12:45   ` Boqun Feng
2025-05-21  6:44 ` [PATCH v4 04/20] rust: add new `num` module with useful integer operations Alexandre Courbot
2025-05-22  4:00   ` Alexandre Courbot
2025-05-22  8:44     ` Miguel Ojeda
2025-05-22  9:31       ` Alexandre Courbot
2025-05-28 19:56   ` Alice Ryhl
2025-05-29  1:35     ` Alexandre Courbot
2025-05-28 20:17   ` Benno Lossin
2025-05-29  1:18     ` Alexandre Courbot
2025-05-29  7:27       ` Benno Lossin
2025-06-02  9:39         ` Danilo Krummrich
2025-06-03 22:53           ` Benno Lossin
2025-06-03 23:54             ` Alexandre Courbot
2025-06-04  7:21               ` Benno Lossin
2025-06-02 13:09         ` Alexandre Courbot
2025-06-03 23:02           ` Benno Lossin
2025-06-04  0:05             ` Alexandre Courbot
2025-06-04  7:18               ` Benno Lossin
2025-06-12 13:17                 ` Alexandre Courbot
2025-06-12 13:27                   ` Alexandre Courbot
2025-06-12 14:49                     ` Benno Lossin
2025-06-13  5:31                       ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 05/20] gpu: nova-core: use absolute paths in register!() macro Alexandre Courbot
2025-05-30 21:38   ` Lyude Paul
2025-05-21  6:45 ` [PATCH v4 06/20] gpu: nova-core: add delimiter for helper rules " Alexandre Courbot
2025-05-30 21:39   ` Lyude Paul
2025-05-21  6:45 ` [PATCH v4 07/20] gpu: nova-core: expose the offset of each register as a type constant Alexandre Courbot
2025-05-30 21:40   ` Lyude Paul
2025-05-21  6:45 ` [PATCH v4 08/20] gpu: nova-core: allow register aliases Alexandre Courbot
2025-05-21  8:37   ` Danilo Krummrich
2025-05-22  5:14     ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 09/20] gpu: nova-core: increase BAR0 size to 16MB Alexandre Courbot
2025-05-30 21:46   ` Lyude Paul
2025-06-02 11:21     ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 10/20] gpu: nova-core: add helper function to wait on condition Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 11/20] gpu: nova-core: wait for GFW_BOOT completion Alexandre Courbot
2025-05-30 21:51   ` Lyude Paul
2025-05-31 14:09     ` Miguel Ojeda
2025-05-31 14:37       ` Danilo Krummrich
2025-05-31 14:45         ` Miguel Ojeda
2025-06-02 11:21         ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 12/20] gpu: nova-core: add DMA object struct Alexandre Courbot
2025-05-30 21:53   ` Lyude Paul
2025-05-21  6:45 ` [PATCH v4 13/20] gpu: nova-core: register sysmem flush page Alexandre Courbot
2025-05-30 21:57   ` Lyude Paul
2025-06-02 11:09     ` Danilo Krummrich
2025-06-02 11:20       ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 14/20] gpu: nova-core: add falcon register definitions and base code Alexandre Courbot
2025-05-30 22:22   ` Lyude Paul
2025-06-03  8:03     ` Alexandre Courbot
2025-06-02 12:06   ` Danilo Krummrich [this message]
2025-06-03  7:59     ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 15/20] gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTS Alexandre Courbot
2025-05-30 22:23   ` Lyude Paul
2025-06-02 12:26   ` Danilo Krummrich
2025-06-04  3:58     ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 16/20] nova-core: Add support for VBIOS ucode extraction for boot Alexandre Courbot
2025-05-27 20:38   ` Joel Fernandes
2025-05-29  6:47     ` Alexandre Courbot
2025-06-03 21:15     ` Lyude Paul
2025-06-05 16:18       ` Joel Fernandes
2025-06-02 13:33   ` Danilo Krummrich
2025-06-02 15:15     ` Joel Fernandes
2025-06-03  8:12       ` Alexandre Courbot
2025-06-03 13:47         ` Joel Fernandes
2025-06-03 13:49           ` Danilo Krummrich
2025-06-03 14:29     ` Joel Fernandes
2025-06-04 18:23     ` Joel Fernandes
2025-06-03 21:05   ` Lyude Paul
2025-06-04 10:03     ` Miguel Ojeda
2025-06-05 16:09     ` Joel Fernandes
2025-06-05 16:21       ` Danilo Krummrich
2025-06-05 16:28         ` Joel Fernandes
2025-05-21  6:45 ` [PATCH v4 17/20] gpu: nova-core: compute layout of the FRTS region Alexandre Courbot
2025-06-03 21:14   ` Lyude Paul
2025-06-04  4:18     ` Alexandre Courbot
2025-06-04 10:24       ` Danilo Krummrich
2025-06-05 13:14         ` Alexandre Courbot
2025-06-04 10:23   ` Danilo Krummrich
2025-06-05 13:36     ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 18/20] gpu: nova-core: add types for patching firmware binaries Alexandre Courbot
2025-06-03 21:16   ` Lyude Paul
2025-06-04 10:28   ` Danilo Krummrich
2025-06-12  7:19     ` Alexandre Courbot
2025-06-12 10:54       ` Danilo Krummrich
2025-06-12 12:52         ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 19/20] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS Alexandre Courbot
2025-06-03 21:32   ` Lyude Paul
2025-06-04  1:11     ` Alexandre Courbot
2025-06-04 10:42   ` Danilo Krummrich
2025-06-12  7:20     ` Alexandre Courbot
2025-05-21  6:45 ` [PATCH v4 20/20] gpu: nova-core: load and " Alexandre Courbot
2025-05-29 21:30   ` Timur Tabi
2025-05-30 22:32     ` Lyude Paul
2025-06-04  1:37     ` Alexandre Courbot
2025-06-03 21:45   ` Lyude Paul
2025-06-04  1:38     ` Alexandre Courbot

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=aD2Ttry3arneEzSd@pollux \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=bskeggs@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    /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.