Message-Id: <DC0D1E12-75A9-4FFC-871C-05831FA67504@collabora.com>
Date: Wed, 30 Jul 2025 09:47:43 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Steven Price <steven.price@....com>
Cc: Alexandre Courbot <acourbot@...dia.com>,
 Danilo Krummrich <dakr@...nel.org>,
 David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>,
 Beata Michalska <beata.michalska@....com>,
 nouveau@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org,
 rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 John Hubbard <jhubbard@...dia.com>,
 Nouveau <nouveau-bounces@...ts.freedesktop.org>
Subject: Re: [PATCH v2 01/19] gpu: nova-core: register: minor grammar and
 spelling fixes

[…]

>>> 
>>>> The idea of register blocks is interesting. I wonder how that would
>>>> translate in terms of access to invididual registers, i.e. does the
>>>> block end up just being a prefix into the full register name, or is it
>>>> something else? From your example declaration I picture that accesses
>>>> would look something like `MMU_AS_CONTROL[4]::MEMATTR::read(bar)`, which
>>>> ngl looks great, but I also cannot think of a construct that would allow
>>>> such a syntax... Happy to think more about it though.
>>> 
>>> Yes, that is the sort of syntax I was imagining, although I was hoping
>>> you could do something like:
>>> 
>>>  let as = MMU_AS_CONTROL[as_id]::try_get(&bar)?;
>>> 
>>>  let memattr = as.MEMATTR.read(&bar);
>>>  memattr.set_attr0(3).write(&bar);
>>>  as.TRANSTAB.write(&bar, 0x1000);
>>> 
>>> Which I'm sure shows how little Rust I've written, but hopefully you get
>>> the idea - only the first line is a try_xxx which can fail and takes the
>>> address space ID from a variable and bounds checks it. The other
>>> accesses we already know the bounds so there's no need to deal with
>>> failure, and we don't have to consider the situation where MEMATTR is
>>> written but the TRANSTAB write fails (which couldn't actually happen
>>> with non-contiguous register arrays but the compiler wouldn't be able to
>>> tell).
>> 
>> That for sure looks elegant. Now the question is how can we implement
>> something similar using only ZSTs? `MMU_AS_CONTROL` would have to be a
>> static array. Then `as` needs to be some sort of struct?
>> 
>> The way this works looks very similar to what I suggested above with
>> register arrays and validating once that a given index is valid for the
>> register array accesses. Then the non-try accessors can be used, knowing
>> that the compiler will be able to infer that the index is valid. The
>> only drawback being that each `read` and `write` will have to carry the
>> `as_id`.
> 
> Presumably it should be possible to implement with 'as' being a type
> which actually contains 'as_id' (as opposed to an actual ZST) so you
> don't need to explicitly pass that in. Otherwise there's a possibility
> of passing the wrong as_id in and so the compiler won't be able to infer
> that it must be valid.
> 
>> This would work, but if someone wants to experiment to try and implement
>> something closer to the interface you proposed, I'm very open to the
>> idea. I wonder if we could do this without any runtime overhead...
> 
> Since my Rust knowledge is very limited there might be a better way of
> doing this, but that this seemed like the most natural interface to me.
> I can see how a similar approach could be used in C with minimal/no
> overhead so I would have thought this is possible in Rust.

I hate macros with a passion, but I can try tackling this in the interest of
moving it forward :)

— Daniel

Powered by blists - more mailing lists