All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Danilo Krummrich" <dakr@kernel.org>,
	"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" <lossin@kernel.org>,
	"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>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 02/11] gpu: nova-core: move GSP boot code out of `Gpu` constructor
Date: Wed, 10 Sep 2025 13:48:12 +0900	[thread overview]
Message-ID: <DCOUK0Z4YV6M.2R0CFE57DY5CR@nvidia.com> (raw)
In-Reply-To: <DCOCL398HXDH.3QH9U6UGGIUP1@kernel.org>

On Tue Sep 9, 2025 at 11:43 PM JST, Danilo Krummrich wrote:
> On Tue Sep 9, 2025 at 4:11 PM CEST, Alexandre Courbot wrote:
>> On Wed Sep 3, 2025 at 5:27 PM JST, Danilo Krummrich wrote:
>>> On Wed Sep 3, 2025 at 9:10 AM CEST, Alexandre Courbot wrote:
>>>> On Wed Sep 3, 2025 at 8:12 AM JST, Danilo Krummrich wrote:
>>>>> On 9/2/25 4:31 PM, Alexandre Courbot wrote:
>>>>>>       pub(crate) fn new(
>>>>>>           pdev: &pci::Device<device::Bound>,
>>>>>>           devres_bar: Arc<Devres<Bar0>>,
>>>>>
>>>>> The diff is hiding it, but with this patch we should also make sure that this 
>>>>> returns impl PinInit<Self, Error> rather than Result<impl PinInit<Self>.
>>>>>
>>>>> I think this should be possible now.
>>>>
>>>> There is still code that can return errors (falcon creation, etc) - do
>>>> you mean that we should move it into the pin initializer and turn it
>>>> into a `try_pin_init`?
>>>
>>> Yeah, that would be better practice, if it doesn't work out for a good reason
>>> we can also fall back to Result<impl PinInit<Self, Error>, but we should at
>>> least try to avoid it.
>>
>> I tried but could not do it in a way that is satisfying. The problem is
>> that `Gpu::new` receives a `Arc<Devres<Bar0>>`, which we need to
>> `access` in order to do anything useful with it. If we first store it
>> into the `Gpu` structure, then every subsequent member needs to `access`
>> it in its own code block in order to perform their own initialization.
>> This is quite cumbersome.
>>
>> If there is a way to obtain the `Bar0` once after the `bar` member of
>> `Gpu` is initialized, and then use that instance with each remaining
>> member, then that problem would go away but I am not aware of such a
>> thing.
>
> What about this?
>
> 	impl Gpu {
> 	    pub(crate) fn new<'a>(
> 	        dev: &'a Device<Bound>,
> 	        bar: &'a Bar0
> 	        devres_bar: Arc<Devres<Bar0>>,
> 	    ) -> impl PinInit<Self, Error> + 'a {
> 	        try_pin_init(Self {
> 	            bar: devres_bar,
> 	            spec: Spec::new(bar)?,
> 	            gsp_falcon: Falcon::<Gsp>::new(dev, spec.chipset)?,
> 	            sec2_falcon: Falcon::<Sec2>::new(dev, spec.chipset)?,
> 	            sysmem_flush: SysmemFlush::register(dev, bar, spec.chipset)?
> 	            gsp <- Gsp::new(gsp_falcon, sec2_falcon, sysmem_flush)?,
> 	        })
> 	    }
> 	}

It does work. The bizareness of passing the `bar` twice aside, here is
what it looks like when I got it to compile:

    pub(crate) fn new<'a>(
        pdev: &'a pci::Device<device::Bound>,
        devres_bar: Arc<Devres<Bar0>>,
        bar: &'a Bar0,
    ) -> impl PinInit<Self, Error> + 'a {
        try_pin_init!(Self {
            spec: Spec::new(bar).inspect(|spec| {
                dev_info!(
                    pdev.as_ref(),
                    "NVIDIA (Chipset: {}, Architecture: {:?}, Revision: {})\n",
                    spec.chipset,
                    spec.chipset.arch(),
                    spec.revision
                );
            })?,

            sysmem_flush: SysmemFlush::register(pdev.as_ref(), bar, spec.chipset)?,

            gsp_falcon: Falcon::<Gsp>::new(
                pdev.as_ref(),
                spec.chipset,
                bar,
                spec.chipset > Chipset::GA100,
            )
            .inspect(|falcon| falcon.clear_swgen0_intr(bar))?,

            sec2_falcon: Falcon::<Sec2>::new(pdev.as_ref(), spec.chipset, bar, true)?,

            gsp: Self::start_gsp(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?,

            bar: devres_bar,
        })
    }

The wait for GFW initialization had to be moved to `probe`, but that's
fine IMO. I do however find the code less readable in this form, less
editable as well. And LSP seems lost, so I don't get any syntax
highlighting in the `try_pin_init` block.

Fundamentally, this changes the method from a fallible method returning
a non-fallible initializer into a non-fallible method returning a
fallible initializer. I'm ok with that, and maybe this new form will
encourage us to keep this method short, which is what we want, but other
than that what benefit are we getting from this change?

  reply	other threads:[~2025-09-10  4:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 14:31 [PATCH v3 00/11] gpu: nova-core: process and prepare more firmwares to boot GSP Alexandre Courbot
2025-09-02 14:31 ` [PATCH v3 01/11] gpu: nova-core: require `Send` on `FalconEngine` and `FalconHal` Alexandre Courbot
2025-09-02 14:31 ` [PATCH v3 02/11] gpu: nova-core: move GSP boot code out of `Gpu` constructor Alexandre Courbot
2025-09-02 19:53   ` Danilo Krummrich
2025-09-03  7:08     ` Alexandre Courbot
2025-09-03  7:21       ` Alexandre Courbot
2025-09-03  8:26       ` Danilo Krummrich
2025-09-03 10:44         ` Alexandre Courbot
2025-09-03 11:05           ` Danilo Krummrich
2025-09-03 12:29             ` Alexandre Courbot
2025-09-03 14:53               ` Danilo Krummrich
2025-09-04 15:28                 ` Joel Fernandes
2025-09-02 23:12   ` Danilo Krummrich
2025-09-03  7:10     ` Alexandre Courbot
2025-09-03  8:27       ` Danilo Krummrich
2025-09-09 14:11         ` Alexandre Courbot
2025-09-09 14:43           ` Danilo Krummrich
2025-09-10  4:48             ` Alexandre Courbot [this message]
2025-09-10  8:01               ` Danilo Krummrich
2025-09-10 11:18                 ` Alexandre Courbot
2025-09-10 11:22                   ` Alexandre Courbot
2025-09-10 11:22                   ` Danilo Krummrich
2025-09-02 14:31 ` [PATCH v3 03/11] gpu: nova-core: add Chipset::name() method Alexandre Courbot
2025-09-02 14:31 ` [PATCH v3 04/11] gpu: nova-core: firmware: move firmware request code into a function Alexandre Courbot
2025-09-02 14:31 ` [PATCH v3 05/11] gpu: nova-core: firmware: add support for common firmware header Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 06/11] gpu: nova-core: firmware: process Booter and patch its signature Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 07/11] gpu: nova-core: firmware: process and prepare the GSP firmware Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 08/11] gpu: nova-core: firmware: process the GSP bootloader Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 09/11] gpu: nova-core: firmware: use 570.144 firmware Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 10/11] gpu: nova-core: Add base files for r570.144 firmware bindings Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 11/11] gpu: nova-core: compute layout of more framebuffer regions required for GSP 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=DCOUK0Z4YV6M.2R0CFE57DY5CR@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --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=lossin@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.