linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	<nouveau@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>,
	<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: gpu: nova-core: arm32 build errors
Date: Thu, 28 Aug 2025 21:57:16 +0200	[thread overview]
Message-ID: <DCEBQZ7WA1KI.1G8TNWH32QWG@kernel.org> (raw)
In-Reply-To: <CANiq72mkPqFnb4ztiCokE6+ntVSmgOTgERshg-4SMmLboFOqNg@mail.gmail.com>

On Thu Aug 28, 2025 at 9:31 PM CEST, Miguel Ojeda wrote:
> On Thu, Aug 28, 2025 at 9:24 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> Maybe I spoke too soon, it's actually pretty painful to keep 32-bit
>> compatibility, even though it would be nice for testing purposes.
>>
>> I'll paste the diff to fix it below, I think that makes it obvious why I say
>> that.
>>
>> Instead, we should really just depend on CONFIG_64BIT (which implies
>> ARCH_DMA_ADDR_T_64BIT).
>
> Yeah, it isn't great.
>
> If it were just that, maybe it it is worth it (and a `DmaAddress`
> newtype, not just a typedef, could perhaps be nice anyway?)

What do you have in mind what the newtype can do?

I assume the idea is to make it provide methods {to,from}_u64, where to_u64()
has to be fallible? This would be an improvement, but not really solve the issue
entirely.

The annoying part really is

	pub(super) fn read_sysmem_flush_page_ga100(bar: &Bar0) -> DmaAddress {
	    let addr = u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08())
	        << FLUSH_SYSMEM_ADDR_SHIFT
	        | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
	            << FLUSH_SYSMEM_ADDR_SHIFT_HI;
	
	    addr.try_into().unwrap_or_else(|_| {
	        kernel::warn_on!(true);
	
	        0
	    })
	}

i.e. when we read a u64 from registers, but we know that what we've orignally
written there is a DmaAddress, so we can assume that a cast to DmaAddress is
fine.

But this really depends on driver specific semantics.

> but if
> you think it will become increasingly painful later, then it may be
> best to focus on what matters.

We'll have a couple more such cases for sure; I think being able to assume that
DmaAddress is always 64-bit will result in simpler and less distracting code.

But if we can come up with a good idea to deal with this with a DmaAddress type;
I'm open to that.

> It is unlikely there is going to be actual users on a 32-bit platform, right?

Yeah, I doubt that someone could think it's a great idea to run a Turing+ GPU on
some 32-bit machine.

  parent reply	other threads:[~2025-08-28 19:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-28 16:02 gpu: nova-core: arm32 build errors Miguel Ojeda
2025-08-28 17:54 ` Danilo Krummrich
2025-08-28 19:24   ` Danilo Krummrich
2025-08-28 19:31     ` Miguel Ojeda
2025-08-28 19:36       ` Miguel Ojeda
2025-08-28 19:58         ` Danilo Krummrich
2025-08-28 21:27           ` Danilo Krummrich
2025-08-28 19:57       ` Danilo Krummrich [this message]
2025-08-28 21:45       ` John Hubbard
2025-08-28 21:54         ` Danilo Krummrich

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=DCEBQZ7WA1KI.1G8TNWH32QWG@kernel.org \
    --to=dakr@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).