Rust for Linux List
 help / color / mirror / Atom feed
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>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	rust-for-linux@vger.kernel.org, laura.nao@collabora.com,
	boris.brezillon@collabora.com, samitolvanen@google.com
Subject: Re: [PATCH] drm/tyr: move probe resources into registration data
Date: Thu, 04 Jun 2026 15:12:50 +0200	[thread overview]
Message-ID: <DJ0AHUXK4V11.8FGPD9P9NVE4@kernel.org> (raw)
In-Reply-To: <20260603-use_tyr_reg_data-v1-1-97f64e951cf6@collabora.com>

On Thu Jun 4, 2026 at 1:19 AM CEST, Deborah Brouwer wrote:
> @@ -59,21 +61,36 @@ pub(crate) struct TyrPlatformDriverData<'bound> {
>  }
>  
>  #[pin_data]
> -pub(crate) struct TyrDrmDeviceData {
> +pub(crate) struct TyrDrmDeviceData;
> +
> +/// Resources kept alive by the DRM registration.
> +#[pin_data]
> +pub(crate) struct TyrDrmRegistrationData<'bound> {
> +    /// Parent platform device.
>      pub(crate) pdev: ARef<platform::Device>,

This can just be &'bound platform::Device, or even &'bound platform::Device<Bound>.

>  
> +    /// Firmware sections.
> +    pub(crate) fw: Arc<Firmware<'bound>>,

This doesn't seem like it needs to be reference counted; at least from the
context I have from this patch.

> +
>      #[pin]
>      clks: Mutex<Clocks>,
>  
>      #[pin]
>      regulators: Mutex<Regulators>,
>  
> +    /// GPU MMIO register mapping.
> +    pub(crate) iomem: Arc<IoMem<'bound>>,

This may not need to be reference counted either; at least eventually.

It seems like this reference count only exists, so you are able to also store it
in struct Firmware.

This goes away once pin-init has the self-referential feature.

If there is no other reason for this reference count, you could temporarily do
what we do in nova-core [1] and obtain a &'bound IoMem<'bound> reference to
store in struct Firmware unsafely.

[1] https://lore.kernel.org/nova-gpu/20260525225838.276108-2-dakr@kernel.org/

> +
>      /// Some information on the GPU.
>      ///
>      /// This is mainly queried by userspace, i.e.: Mesa.
>      pub(crate) gpu_info: GpuInfo,
>  }
>  
> +impl ForLt for TyrDrmRegistrationData<'static> {
> +    type Of<'bound> = TyrDrmRegistrationData<'bound>;
> +}

This isn't wrong, but the intention is to use the ForLt! macro for this.

diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
index acf5080a5467..694958509da7 100644
--- a/drivers/gpu/drm/tyr/driver.rs
+++ b/drivers/gpu/drm/tyr/driver.rs
@@ -87,9 +87,6 @@ pub(crate) struct TyrDrmRegistrationData<'bound> {
     pub(crate) gpu_info: GpuInfo,
 }
 
-impl ForLt for TyrDrmRegistrationData<'static> {
-    type Of<'bound> = TyrDrmRegistrationData<'bound>;
-}
 
 fn issue_soft_reset(dev: &Device, iomem: &IoMem<'_>) -> Result {
     iomem.write_reg(GPU_COMMAND::reset(ResetMode::SoftReset));
@@ -221,7 +218,7 @@ fn drop(self: Pin<&mut Self>) {}
 #[vtable]
 impl drm::Driver for TyrDrmDriver {
     type Data = TyrDrmDeviceData;
-    type RegistrationData = TyrDrmRegistrationData<'static>;
+    type RegistrationData = ForLt!(TyrDrmRegistrationData<'_>);
     type File = TyrDrmFileData;
     type Object<R: drm::DeviceContext> = drm::gem::shmem::Object<BoData, R>;
     type ParentDevice<Ctx: DeviceContext> = platform::Device<Ctx>;

> +
>  fn issue_soft_reset(dev: &Device, iomem: &IoMem<'_>) -> Result {
>      iomem.write_reg(GPU_COMMAND::reset(ResetMode::SoftReset));
>  
> @@ -119,7 +136,7 @@ fn probe<'bound>(
>          let sram_regulator = Regulator::<regulator::Enabled>::get(pdev.as_ref(), c"sram")?;
>  
>          let request = pdev.io_request_by_index(0).ok_or(ENODEV)?;
> -        let iomem = request.iomap_sized::<SZ_2M>()?;
> +        let iomem = Arc::new(request.iomap_sized::<SZ_2M>()?, GFP_KERNEL)?;
>  
>          issue_soft_reset(pdev.as_ref(), &iomem)?;
>          gpu::l2_power_on(pdev.as_ref(), &iomem)?;
> @@ -137,8 +154,23 @@ fn probe<'bound>(
>  
>          let platform: ARef<platform::Device> = pdev.into();
>  
> -        let data = try_pin_init!(TyrDrmDeviceData {
> +        let dev_data = try_pin_init!(TyrDrmDeviceData {});
> +
> +        let unreg_dev = drm::UnregisteredDevice::<TyrDrmDriver>::new(pdev, dev_data)?;

Keeping TyrDrmDeviceData and calling the above try_pin_init! seems unnecessary;
you can just pass Ok(()) to drm::UnregisteredDevice::new().

> +
> +        let mmu = Mmu::new(iomem.as_arc_borrow(), &gpu_info)?;
> +
> +        let firmware = Firmware::new(
> +            pdev,
> +            iomem.clone(),
> +            &unreg_dev,
> +            mmu.as_arc_borrow(),
> +            &gpu_info,
> +        )?;
> +
> +        let reg_data = try_pin_init!(TyrDrmRegistrationData {
>                  pdev: platform.clone(),
> +                fw: firmware,
>                  clks <- new_mutex!(Clocks {
>                      core: core_clk,
>                      stacks: stacks_clk,
> @@ -148,11 +180,16 @@ fn probe<'bound>(
>                      _mali: mali_regulator,
>                      _sram: sram_regulator,
>                  }),
> +                iomem,
>                  gpu_info,
>          });
>  
> -        let tdev = drm::UnregisteredDevice::<TyrDrmDriver>::new(pdev, data)?;
> -        let reg = drm::Registration::new(pdev.as_ref(), tdev, (), 0)?;
> +        // SAFETY: `reg` is stored in the platform driver data and is not leaked or
> +        // forgotten, so it is dropped before the `'bound` registration data can become
> +        // invalid.
> +        let reg = unsafe {
> +            drm::driver::Registration::new_with_lt(pdev.as_ref(), unreg_dev, reg_data, 0)?

This is re-exported as drm::Registration.

> +        };

      reply	other threads:[~2026-06-04 13:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-03 23:19 [PATCH] drm/tyr: move probe resources into registration data Deborah Brouwer
2026-06-04 13:12 ` Danilo Krummrich [this message]

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=DJ0AHUXK4V11.8FGPD9P9NVE4@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.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=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=samitolvanen@google.com \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    /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