| 0023a1e8 | 07-May-2026 |
Lyude Paul <lyude@redhat.com> |
rust/drm/gem: Use DeviceContext with GEM objects
Now that we have the ability to represent the context in which a DRM device is in at compile-time, we can start carrying around this context with GEM
rust/drm/gem: Use DeviceContext with GEM objects
Now that we have the ability to represent the context in which a DRM device is in at compile-time, we can start carrying around this context with GEM object types in order to allow a driver to safely create GEM objects before a DRM device has registered with userspace.
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20260507220044.3204919-4-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 43a5d04a | 07-May-2026 |
Lyude Paul <lyude@redhat.com> |
rust/drm/gem: Add DriverAllocImpl type alias
This is just a type alias that resolves into the AllocImpl for a given T: drm::gem::DriverObject.
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-
rust/drm/gem: Add DriverAllocImpl type alias
This is just a type alias that resolves into the AllocImpl for a given T: drm::gem::DriverObject.
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20260507220044.3204919-3-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 571d4242 | 07-May-2026 |
Lyude Paul <lyude@redhat.com> |
rust/drm: Introduce DeviceContext
One of the tricky things about DRM bindings in Rust is the fact that initialization of a DRM device is a multi-step process. It's quite normal for a device driver t
rust/drm: Introduce DeviceContext
One of the tricky things about DRM bindings in Rust is the fact that initialization of a DRM device is a multi-step process. It's quite normal for a device driver to start making use of its DRM device for tasks like creating GEM objects before userspace registration happens. This is an issue in rust though, since prior to userspace registration the device is only partly initialized. This means there's a plethora of DRM device operations we can't yet expose without opening up the door to UB if the DRM device in question isn't yet registered.
Additionally, this isn't something we can reliably check at runtime. And even if we could, performing an operation which requires the device be registered when the device isn't actually registered is a programmer bug, meaning there's no real way to gracefully handle such a mistake at runtime. And even if that wasn't the case, it would be horrendously annoying and noisy to have to check if a device is registered constantly throughout a driver.
In order to solve this, we first take inspiration from `kernel::device::DeviceContext` and introduce `kernel::drm::DeviceContext`. This provides us with a ZST type that we can generalize over to represent contexts where a device is known to have been registered with userspace at some point in time (`Registered`), along with contexts where we can't make such a guarantee (`Uninit`).
It's important to note we intentionally do not provide a `DeviceContext` which represents an unregistered device. This is because there's no reasonable way to guarantee that a device with long-living references to itself will not be registered eventually with userspace. Instead, we provide a new-type for this: `UnregisteredDevice` which can provide a guarantee that the `Device` has never been registered with userspace. To ensure this, we modify `Registration` so that creating a new `Registration` requires passing ownership of an `UnregisteredDevice`.
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20260507220044.3204919-2-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 9c815968 | 07-May-2026 |
Laura Nao <laura.nao@collabora.com> |
rust: drm: add FEAT_RENDER flag for render node support
Add FEAT_RENDER bool constant to the Driver trait to control render node support. When enabled, the driver exposes /dev/dri/renderDXX render n
rust: drm: add FEAT_RENDER flag for render node support
Add FEAT_RENDER bool constant to the Driver trait to control render node support. When enabled, the driver exposes /dev/dri/renderDXX render nodes to userspace. The flag defaults to false, drivers can opt in by setting it to true in their Driver implementation.
This is then enabled in the Tyr driver, while it's left disabled for Nova for the time being.
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Laura Nao <laura.nao@collabora.com> Link: https://patch.msgid.link/20260507080914.95478-2-laura.nao@collabora.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 37f748ed | 27-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
drm/gpuvm: rust: add RUST_DRM_GPUVM option to Kconfig
Since Rust uses GPUVM via the kernel crate, which is built-in, the GPUVM module must also be built-in to use GPUVM from Rust. Adjust the Kconfig
drm/gpuvm: rust: add RUST_DRM_GPUVM option to Kconfig
Since Rust uses GPUVM via the kernel crate, which is built-in, the GPUVM module must also be built-in to use GPUVM from Rust. Adjust the Kconfig settings accordingly.
Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260427-gpuvm-config-v1-1-8ece03771f8a@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 0b715b1e | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: gpuvm: add GpuVmCore::sm_map()
Finally also add the operation for creating new mappings. Mapping operations need extra data in the context since they involve a vm_bo coming from the outside.
rust: gpuvm: add GpuVmCore::sm_map()
Finally also add the operation for creating new mappings. Mapping operations need extra data in the context since they involve a vm_bo coming from the outside.
Co-developed-by: Asahi Lina <lina+kernel@asahilina.net> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-5-b16e6ada7261@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| dc384604 | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: gpuvm: add GpuVmCore::sm_unmap()
Add the entrypoint for unmapping ranges in the GPUVM, and provide callbacks and VA types for the implementation.
Co-developed-by: Asahi Lina <lina+kernel@asah
rust: gpuvm: add GpuVmCore::sm_unmap()
Add the entrypoint for unmapping ranges in the GPUVM, and provide callbacks and VA types for the implementation.
Co-developed-by: Asahi Lina <lina+kernel@asahilina.net> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-4-b16e6ada7261@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 5540a9c7 | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: gpuvm: add GpuVa struct
This struct will be used to keep track of individual mapped ranges in the GPU's virtual memory.
Sparse VAs are not yet supported.
Co-developed-by: Asahi Lina <lina+ke
rust: gpuvm: add GpuVa struct
This struct will be used to keep track of individual mapped ranges in the GPU's virtual memory.
Sparse VAs are not yet supported.
Co-developed-by: Asahi Lina <lina+kernel@asahilina.net> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net> Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-3-b16e6ada7261@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 71a39211 | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: gpuvm: add GpuVm::obtain()
This provides a mechanism to create (or look up) VMBO instances, which represent the mapping between GPUVM and GEM objects.
The GpuVmBoRegistered<T> type can be con
rust: gpuvm: add GpuVm::obtain()
This provides a mechanism to create (or look up) VMBO instances, which represent the mapping between GPUVM and GEM objects.
The GpuVmBoRegistered<T> type can be considered like ARef<GpuVm<T>>, except that no way to increment the refcount is provided.
The GpuVmBoAlloc<T> type is more akin to a pre-allocated GpuVmBo<T>, so it's not really a GpuVmBo<T> yet. Its destructor could call drm_gpuvm_bo_destroy_not_in_lists(), but as the type is currently private and never called anywhere, this perf optimization does not need to happen now.
Pre-allocating and obtaining the gpuvm_bo object is exposed as a single step. This could theoretically be a problem if one wanted to call drm_gpuvm_bo_obtain_prealloc() during the fence signalling critical path, but that's not a possibility because:
1. Adding the BO to the extobj list requires the resv lock, so it cannot happen during the fence signalling critical path. 2. obtain() requires that the BO is not in the extobj list, so obtain() must be called before adding the BO to the extobj list.
Thus, drm_gpuvm_bo_obtain_prealloc() cannot be called during the fence signalling critical path. (For extobjs at least.)
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-2-b16e6ada7261@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 0a69ac25 | 01-May-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
rust: drm: fix unsound initialization in drm::Device::new
If pinned initialization of drm::Device::Data fails, it calls drm::Device::release via drm_dev_put. This materializes a reference to &drm::D
rust: drm: fix unsound initialization in drm::Device::new
If pinned initialization of drm::Device::Data fails, it calls drm::Device::release via drm_dev_put. This materializes a reference to &drm::Device, but it's not fully constructed yet, because initializing `data` failed. It should not be dropped either. Instead, if pinned initialization fails, make sure drm::Device::release isn't called.
Fixes: 2e9fdbe5ec7a ("rust: drm: device: drop_in_place() the drm::Device in release()") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260501-fix-drm-1-v2-1-5c4f681837bc@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 2e42a17b | 23-Apr-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
rust: drm: gem: clean up GEM state in init failure case
Currently, if `drm_gem_object_init` fails, the object is freed without any cleanup. Perform the cleanup in that case.
Cc: stable@vger.kernel.
rust: drm: gem: clean up GEM state in init failure case
Currently, if `drm_gem_object_init` fails, the object is freed without any cleanup. Perform the cleanup in that case.
Cc: stable@vger.kernel.org Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Onur Özkan <work@onurozkan.dev> Link: https://patch.msgid.link/20260423-fix-gem-1-v1-1-e12e35f7bba9@nvidia.com [ Move safety comment closer to unsafe block to avoid a clippy warning. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 80df573a | 16-Mar-2026 |
Asahi Lina <lina@asahilina.net> |
rust: drm: gem: shmem: Add DRM shmem helper abstraction
The DRM shmem helper includes common code useful for drivers which allocate GEM objects as anonymous shmem. Add a Rust abstraction for this. D
rust: drm: gem: shmem: Add DRM shmem helper abstraction
The DRM shmem helper includes common code useful for drivers which allocate GEM objects as anonymous shmem. Add a Rust abstraction for this. Drivers can choose the raw GEM implementation or the shmem layer, depending on their needs.
Signed-off-by: Asahi Lina <lina@asahilina.net> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-6-lyude@redhat.com [ * DRM_GEM_SHMEM_HELPER is a tristate; when a module driver selects it, it becomes =m. The Rust kernel crate and its C helpers are always built into vmlinux and can't reference symbols from a module, causing link errors.
Thus, add RUST_DRM_GEM_SHMEM_HELPER bool Kconfig that selects DRM_GEM_SHMEM_HELPER, forcing it built-in when Rust drivers need it; use cfg(CONFIG_RUST_DRM_GEM_SHMEM_HELPER) for the shmem module.
* Add cfg_attr(not(CONFIG_RUST_DRM_GEM_SHMEM_HELPER), expect(unused)) on pub(crate) use impl_aref_for_gem_obj and BaseObjectPrivate, so that unused warnings are suppressed when shmem is not enabled.
* Enable const_refs_to_static (stabilized in 1.83) to prevent build errors with older compilers.
* Use &raw const for bindings::drm_gem_shmem_vm_ops and add #[allow(unused_unsafe, reason = "Safe since Rust 1.82.0")].
* Fix incorrect C Header path and minor spelling and formatting issues.
* Drop shmem::Object::sg_table() as the current implementation is unsound.
- Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 89b4964c | 16-Mar-2026 |
Lyude Paul <lyude@redhat.com> |
rust: drm: gem: Add raw_dma_resv() function
For retrieving a pointer to the struct dma_resv for a given GEM object. We also introduce it in a new trait, BaseObjectPrivate, which we automatically imp
rust: drm: gem: Add raw_dma_resv() function
For retrieving a pointer to the struct dma_resv for a given GEM object. We also introduce it in a new trait, BaseObjectPrivate, which we automatically implement for all gem objects and don't expose to users outside of the crate.
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Janne Grunau <j@jannau.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-3-lyude@redhat.com [ Fix incorrect reference in safety comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| bdf6b22f | 26-Mar-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: drm: use new sync::aref path for imports
ARef and AlwaysRefCounted are being moved to sync::aref, and the re-exports under types are planned to be removed. Thus, update imports to the new path
rust: drm: use new sync::aref path for imports
ARef and AlwaysRefCounted are being moved to sync::aref, and the re-exports under types are planned to be removed. Thus, update imports to the new path.
Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260326-drm-rust-next-fix-aref-v1-2-7f6f58d2828a@google.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
show more ...
|
| 206bada3 | 24-Mar-2026 |
Daniel Almeida <daniel.almeida@collabora.com> |
rust: drm: dispatch delayed work items to the private data
Much like the patch that dispatched (regular) work items, we also need to dispatch delayed work items in order not to trigger the orphan ru
rust: drm: dispatch delayed work items to the private data
Much like the patch that dispatched (regular) work items, we also need to dispatch delayed work items in order not to trigger the orphan rule. This allows a drm::Device<T> to dispatch the delayed work to T::Data.
Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20260323-aref-workitem-v3-4-f59729b812aa@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
show more ...
|
| 72a723df | 24-Mar-2026 |
Daniel Almeida <daniel.almeida@collabora.com> |
rust: drm: dispatch work items to the private data
This implementation dispatches any work enqueued on ARef<drm::Device<T>> to its driver-provided handler. It does so by building upon the newly-adde
rust: drm: dispatch work items to the private data
This implementation dispatches any work enqueued on ARef<drm::Device<T>> to its driver-provided handler. It does so by building upon the newly-added ARef<T> support in workqueue.rs in order to call into the driver implementations for work_container_of and raw_get_work.
This is notably important for work items that need access to the drm device, as it was not possible to enqueue work on a ARef<drm::Device<T>> previously without failing the orphan rule.
The current implementation needs T::Data to live inline with drm::Device in order for work_container_of to function. This restriction is already captured by the trait bounds. Drivers that need to share their ownership of T::Data may trivially get around this:
// Lives inline in drm::Device struct DataWrapper { work: ..., // Heap-allocated, shared ownership. data: Arc<DriverData>, }
Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20260323-aref-workitem-v3-2-f59729b812aa@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
show more ...
|
| 442ba16a | 16-Mar-2026 |
Lyude Paul <lyude@redhat.com> |
rust: gem: Introduce DriverObject::Args
This is an associated type that may be used in order to specify a data-type to pass to gem objects when constructing them, allowing for drivers to more easily
rust: gem: Introduce DriverObject::Args
This is an associated type that may be used in order to specify a data-type to pass to gem objects when constructing them, allowing for drivers to more easily initialize their private-data for gem objects.
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-5-lyude@redhat.com [ Resolve merge conflicts in Tyr. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 6ad005ce | 22-Jan-2026 |
Lyude Paul <lyude@redhat.com> |
rust/drm: Remove imports covered by prelude::*
This just removes any explicit imports of items in files that are already being pulled in by `use prelude::*;`.
There should be no functional changes
rust/drm: Remove imports covered by prelude::*
This just removes any explicit imports of items in files that are already being pulled in by `use prelude::*;`.
There should be no functional changes in this patch.
Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260122214316.3281257-2-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|