From: "Danilo Krummrich" <dakr@kernel.org>
To: "Deborah Brouwer" <deborah.brouwer@collabora.com>
Cc: "Daniel Almeida" <daniel.almeida@collabora.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Benno Lossin" <lossin@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Tamir Duberstein" <tamird@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org, laura.nao@collabora.com,
samitolvanen@google.com, lyude@redhat.com,
beata.michalska@arm.com, boris.brezillon@collabora.com,
steven.price@arm.com, alvin.sun@linux.dev
Subject: Re: [PATCH v10 3/7] drm/tyr: add Memory Management Unit (MMU) support
Date: Tue, 28 Jul 2026 23:19:29 +0200 [thread overview]
Message-ID: <DKAINVQDNE79.3JRKZDQJCSX9@kernel.org> (raw)
In-Reply-To: <amkSjDCt_P-TfXHD@um790>
On Tue Jul 28, 2026 at 10:35 PM CEST, Deborah Brouwer wrote:
> On Tue, Jul 28, 2026 at 09:31:50PM +0200, Danilo Krummrich wrote:
>> On Tue Jul 28, 2026 at 8:39 PM CEST, Deborah Brouwer wrote:
>> > +/// Locked wrapper for carrying out virtual memory (VM) operations on the MMU.
>> > +#[pin_data]
>> > +pub(crate) struct Mmu<'drm> {
>>
>> This shouldn't be 'drm, but 'mmu or just something generic like 'a.
>>
>> The rationale is that Mmu might be shorter lived than 'drm once we have
>> self-referencial pin-init. Currently it is straight forward, such as in
>>
>> struct Foo<'foo> {
>> dev: &'foo platform::Device<Bound>,
>> }
>>
>> struct Data<'bound> {
>> foo: Foo<'bound>,
>> }
>>
>> where the lifetime of `dev` really ties back to 'bound. However, with
>> self-referencial pin-init it could looks like this:
>>
>> struct Foo<'foo> {
>> dev: &'foo platform::Device<Bound>,
>> io: &'foo IoMem<'foo>,
>> }
>>
>> struct Data<'bound> {
>> foo: Foo<'io>,
>> io: IoMem<'bound>,
>> }
>>
>> Now Foo is not constrained to 'bound anymore, as this would be longer lived than
>> `io`, so it has to capture 'io instead in order to still compile.
>
> Danilo, would you be ok with renaming this lifetime as a follow up
> patch?
Sure; note that I also said that I'm happy for this to be a follow-up in the
previous version. :)
> Currently, if I understand this correctly, the mmu lifetime is still tied to
> the DRM registration data, so the name is not inaccurate for Tyr at least as
> it stands right now.
With the current implementation, the Mmu lifetime technically ties back to
'bound; the DRM registration data itself is shorter lived (it is dropped before
'bound ends).
The reason I mentioned not to use the 'bound lifetime name in the first place is
that we agreed to not use the 'bound lifetime name on structs that may be
shorter lived than the device being bound, which is true for anything other than
the bus device private data struct.
next prev parent reply other threads:[~2026-07-28 21:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 18:39 [PATCH v10 0/7] drm/tyr: firmware loading and MCU boot support Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 1/7] drm/tyr: add resources to RegistrationData Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 2/7] drm/tyr: add a generic slot manager Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 3/7] drm/tyr: add Memory Management Unit (MMU) support Deborah Brouwer
2026-07-28 19:31 ` Danilo Krummrich
2026-07-28 20:35 ` Deborah Brouwer
2026-07-28 21:19 ` Danilo Krummrich [this message]
2026-07-28 18:39 ` [PATCH v10 4/7] drm/tyr: add GPU virtual memory (VM) support Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 5/7] drm/tyr: add a kernel buffer object Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 6/7] drm/tyr: add parser for firmware binary Deborah Brouwer
2026-07-28 18:39 ` [PATCH v10 7/7] drm/tyr: add Microcontroller Unit (MCU) booting Deborah Brouwer
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=DKAINVQDNE79.3JRKZDQJCSX9@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=alvin.sun@linux.dev \
--cc=beata.michalska@arm.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=boris.brezillon@collabora.com \
--cc=daniel.almeida@collabora.com \
--cc=deborah.brouwer@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=laura.nao@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
/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