Re: [PATCH 0/6] rust: drm: Higher-Ranked Lifetime private data

[Boris Brezillon <boris.brezillon@collabora.com>]

On Tue, 19 May 2026 21:28:17 +0200
"Danilo Krummrich" <dakr@kernel.org> wrote:

> On Tue May 19, 2026 at 8:59 PM CEST, Boris Brezillon wrote:
> > On Thu, 14 May 2026 21:07:11 +0200
> > "Danilo Krummrich" <dakr@kernel.org> wrote:
> >  
> >> On Thu May 14, 2026 at 8:59 PM CEST, Deborah Brouwer wrote:  
> >> > let unreg_dev = drm::UnregisteredDevice::<TyrDrmDriver>::new(pdev, data)?;    
> >> 
> >> You shouldn't need this anymore as the drm::Registration itself has private data
> >> now that is bound to the lifetime of the underlying bus device, which should be
> >> the correct lifetime for juggling the GPU page tables.  
> >
> > The problem we have is that, to initialize some of the sub-components
> > of the driver, we need to be able to allocate GEM objects before the DRM
> > device is exposed (registered), and because the data we want to attach
> > to the final registration contains these sub-components, we need to
> > defer the data assignment to the registration step (which was allowed
> > by [1], but apparently this was dropped from the latest version of
> > the series for some reason).  
> 
> I'm perfectly aware, what I'm saying above is that you probably want to store
> those GEM objects (that you can create with the previously allocated
> drm::Device) in the drm::Registration data. This fulfills this requirement *and*
> ties the lifetime of those GEM objects to the lifetime of the underlying bus
> device being bound to the driver, which is exactly what you want for GEM objects
> that contain the device page tables.

Yeah, I don't think the problem Deborah was mentioning was about not
being able to allocate GEMs early on, or making sure those GEMs don't
outlive the bus-device. Oh, and BTW, we don't use GEMs for the page
tables themselves, those still go through regular page allocation and
are entirely handled by the io-pgtable-arm.c logic. We need early GEM
allocation to populate FW sections, and to map those to the VM attached
to the FW we need GPUVM too (because the FW also lives behind the GPU
MMU and has its own page table that's populated by the driver).

What I think Deborah was pointing out is the chicken-and-egg issue,
where the registration data is only fully populated after all
sub-components of the drivers have been initialized, and one of these
sub-components (the FW) needs to allocate GEMs and map them to its VM.
So, GEM allocation and GPUVM are required are required early on, and
both want a drm::Device of some sort (Unregistered or Registered). So
the question is, are you happy with having [1] applied before/after
your patchset to address this chicken-and-egg issue I mentioned, or are
you proposing something else (Option<Subcomponent> so that we start
with all sub-components set to None and progressively populate those,
which I remember Daniel was strongly opposed to)?

[1]https://lore.kernel.org/dri-devel/20260320233645.950190-4-lyude@redhat.com/