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.
> + };
prev parent 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