Hi Xiaoyong.
Comments below (other code removed for brevity)
+/**
+ * struct vdec_av1_slice_slot - slot info need save in global instance
+ * @frame_info: frame info for each slot
+ * @timestamp: time stamp info
+ */
+struct vdec_av1_slice_slot {
+ struct vdec_av1_slice_frame_info frame_i
Hi Xiaoyong!
I have tested this and arrived at the same Fluster score:
173/239 - AOM
11/13 - Chromium 8bit
Reviewed-by: Daniel Almeida
Tested-by: Daniel Almeida
still working
on the IGT tests for that.
Let me know what you think.
-- Daniel
[0]
https://gitlab.collabora.com/dwlsalmeida/for-upstream/-/tree/panthor-devcoredump?ref_type=heads
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30651
Daniel Almeida (5):
drm: panthor: expose some
This is of interest to userspace, and similar in nature to the GPU
and CSIF information we already return in the query ioctl.
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/panthor/panthor_device.h | 3 +++
drivers/gpu/drm/panthor/panthor_drv.c| 8
drivers/gpu/drm/panthor
Dump the GPU state using devcoredump. This is useful for debugging
purposes.
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/panthor/Kconfig | 1 +
drivers/gpu/drm/panthor/Makefile| 1 +
drivers/gpu/drm/panthor/panthor_dump.c | 376
drivers/gpu
In preparation for future patches, add support for debugfs in
panthor_sched.c.
Follow-up patches will make use of debugfs files to control aspects of
the dumping process.
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/panthor/panthor_drv.c | 1 +
drivers/gpu/drm/panthor/panthor_sched.c
round this limitation.
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/panthor/panthor_sched.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
b/drivers/gpu/drm/panthor/panthor_sched.c
index afd644c7d9f1..ea2696c1075a 100644
counter is controlled through a debugfs file.
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/panthor/panthor_dump.c | 229
drivers/gpu/drm/panthor/panthor_dump.h | 15 ++
drivers/gpu/drm/panthor/panthor_sched.c | 20 ++-
3 files changed, 186 insertions(+), 78 deletion
Dump the state of the GPU. This feature is useful for debugging purposes.
---
Hi everybody!
For those looking for a branch instead, see [0].
I know this patch has (possibly many) issues. It is meant as a
discussion around the GEM abstractions for now. In particular, I am
aware of the series intro
Hi Liviu,
> Hi Daniel,
>
> I know this is an RFC, but are you trying to avoid Cc-ing Panthor maintainers
> by mistake or by choice? I will be away on sabbatical from next week, but
> Steven Price at least would be interested in having a look.
Definitely by mistake. Boris is my coworker, but ever
Hi Steven, thanks for the review!
>
> This is defining the ABI to userspace and as such we'd need a way of
> exporting this for userspace tools to use. The C approach is a header in
> include/uabi. I'd also suggest making it obvious this enum can't be
> rearranged (e.g. a comment, or assigning sp
> On 12 Jul 2024, at 11:53, Danilo Krummrich wrote:
>
> You could also just define those structures in a C header directly and use it
> from Rust, can't you?
>
Sure, I am open to any approach here. Although this looks a bit reversed to me.
i.e.: why should I declare these structs in a sepa
Hi Dave,
>
> I think I'm on the uapi should remain in C for now, we define uapi
> types with the kernel types and we have downstream tools to scan and
> parse them to deal with alignments and padding (I know FEX relies on
> it), so I think we should be bindgen from uapi headers into rust for
> no
Hi Sima!
>
> Yeah I'm not sure a partially converted driver where the main driver is
> still C really works, that pretty much has to throw out all the type
> safety in the interfaces.
>
> What I think might work is if such partial drivers register as full rust
> drivers, and then largely delega
Hi Alice, thanks for the review!
>> +fn alloc_mem(&mut self, size: usize) -> Option<*mut u8> {
>> +assert!(size % 8 == 0, "Allocation size must be 8-byte
>> aligned");
>> +if isize::try_from(size).unwrap() == isize::MAX {
>> +return None;
>> +
The script (and the panthor_regs.rs file it generates) is at
https://gitlab.collabora.com/dwlsalmeida/for-upstream/-/commit/783be55acf8d3352901798efb0118cce43e7f60b
As you can see, it’s all regexes. It works, but I agree
that it’s simpler to generate something more idiomatic by hand.
— Daniel
Hi Steven!
> On 24 Jul 2024, at 10:54, Steven Price wrote:
>
> [1] Although I have to admit for a debugging feature like devcoredump
> there might well be pressure to implement this in C as well purely so
> that customer issues can be debugged…
FYI: I picked devcoredump because it was self-cont
/dwlsalmeida/for-upstream/-/tree/panthor-devcoredump?ref_type=heads
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30651
Daniel Almeida (5):
drm: panthor: expose some fw information through the query ioctl
drm: panthor: add devcoredump support
drm: panthor: add debugfs support in
ObjectRef {
> +let ptr = self.ptr as *const _;
> +core::mem::forget(self);
> +
> +ObjectRef { ptr }
> +}
> +}
> +
> +impl Drop for UniqueObjectRef {
> +fn drop(&mut self) {
> +// SAFETY: Having a UniqueObjectRef implies holding a GEM
> +// reference. The free callback will take care of deallocation.
> +unsafe {
> +bindings::drm_gem_object_put((*self.ptr).gem_obj() as *const _
> as *mut _);
> +}
> +}
> +}
> +
> +impl Deref for UniqueObjectRef {
> +type Target = T;
> +
> +fn deref(&self) -> &Self::Target {
> +// SAFETY: The pointer is valid per the invariant
> +unsafe { &*self.ptr }
> +}
> +}
> +
> +impl DerefMut for UniqueObjectRef {
> +fn deref_mut(&mut self) -> &mut Self::Target {
> +// SAFETY: The pointer is valid per the invariant
> +unsafe { &mut *self.ptr }
> +}
> +}
> +
> +pub(super) fn create_fops() -> bindings::file_operations {
> +bindings::file_operations {
> +owner: core::ptr::null_mut(),
> +open: Some(bindings::drm_open),
> +release: Some(bindings::drm_release),
> +unlocked_ioctl: Some(bindings::drm_ioctl),
> +#[cfg(CONFIG_COMPAT)]
> +compat_ioctl: Some(bindings::drm_compat_ioctl),
> +#[cfg(not(CONFIG_COMPAT))]
> +compat_ioctl: None,
> +poll: Some(bindings::drm_poll),
> +read: Some(bindings::drm_read),
> +llseek: Some(bindings::noop_llseek),
> +mmap: Some(bindings::drm_gem_mmap),
> +..Default::default()
> +}
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index a767942d0b52..c44760a1332f 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -5,4 +5,5 @@
> pub mod device;
> pub mod drv;
> pub mod file;
> +pub mod gem;
> pub mod ioctl;
> --
> 2.45.1
This looks good to me,
Reviewed-by: Daniel Almeida
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> An optional trait method for implementing a CRTC's atomic state check.
A more thorough explanation like you had in your last patch would be nice here.
By `atomic state check` you mean after the state has been duplicated, and
mutated,
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A mandatory trait method used for implementing DRM's atomic plane update
> callback.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 39 +++-
> 1 file changed, 38 insertions(+), 1 de
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> This introduces basic bindings for DRM CRTCs which follow the same general
> pattern as connectors and planes (e.g. AsRawCrtc, AsRawCrtcState, etc.).
> There is one big difference though - drm_crtc_state appears to be the one
> atomic s
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> Since we allow drivers to have multiple implementations of DriverConnector
> and DriverConnectorState (in C, the equivalent of this is having multiple
> structs which embed drm_connector) - there are some situations we will run
> into w
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> Same thing as OpaqueCrtc and OpaqueCrtcState, but for plane states now.
>
> Signed-off-by: Lyude Paul
>
> ---
>
> TODO:
> * Finish adding upcast functions.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 143 +
Hi Lyude
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Next up is introducing bindings that we can use to represent the global DRM
> atomic state, along with all of the various object states contained within.
> We do this by introducing a few new concepts: borrowed states, atomic state
> mut
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A mandatory trait method used for implementing DRM's atomic plane update
> callback.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 39 +++-
> 1 file changed, 38 insertions(+), 1 deletion(-
Hi Lyude
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Add a binding for checking drm_plane_state.crtc. Note that we don't have a
> way of knowing what DriverCrtc implementation would be used here (and want
> to make this function also available on OpaquePlaneState types), so we
> return an
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> This is just a crate-private helper to use Lock::from_raw() to provide an
> immutable reference to the DRM event_lock, so that it can be used like a
> normal rust spinlock. We'll need this for adding vblank related bindings.
>
> Signed
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A binding for checking drm_device.num_crtcs. We'll need this in a moment
> for vblank support, since setting it up requires knowing the number of
> CRTCs that a driver has initialized.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A binding for checking drm_crtc_state.active.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/rust/kernel/drm/kms/crtc.rs b/rust/kernel/drm/kms/crtc.rs
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> This adds some very simple bindings for drm_framebuffer. We don't use them
> much yet, but we'll eventually be using them when rvkms eventually gets CRC
> and writeback support. Just like Connector objects, these use RcModeObject.
Yeah, for th
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Optional trait method for implementing a plane's atomic_check().
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 41 +++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Add a binding for drm_atomic_helper_check_plane_state(). Since we want to
> make sure that the user is passing in the new state for a Crtc instead of
> an old state, we explicitly ask for a reference to a BorrowedCrtcState.
>
> Signed-
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Same thing as OpaquePlane, but for encoders now.
>
> Signed-off-by: Lyude Paul
>
> ---
>
> TODO:
> * Add upcast functions for this
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/encoder.rs | 55 +
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> Next up is filling out some of the basic connector hotplugging callbacks -
> which we'll need for setting up the fbdev helpers for KMS devices. Note
> that connector hotplugging in DRM follows a BFL scheme: pretty much all
A what schem
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> A simple binding for drm_add_modes_noedid() using the ConnectorGuard type
> we just added.
>
> Signed-off-by: Lyude Paul
> ---
> rust/bindings/bindings_helper.h | 2 ++
> rust/kernel/drm/kms/connector.rs | 11 +++
> 2 files ch
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> Now that we have more then one way to refer to connectors, we also want to
nit: typo here, s/then/than
> ensure that any methods which are common to any kind of connector type can
> be used on all connector representations. This is wh
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Same thing as RawConnector and RawConnectorState, just for CRTCs now.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git
Hi Lyude
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Same thing as RawCrtc and RawCrtcState, but for DRM planes now
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/rust/kernel
Hi Lyude
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> This adds a simple binding for completing the last step of creating a DRM
> connector - attaching its encoder. This function should only be called
> before the connector is registered, and DRM should enforce this itself by
> returning an
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> The next step is adding a set of basic bindings to create a plane, which
> has to happen before we can create a CRTC (since we need to be able to at
> least specify a primary plane for a CRTC upon creation). This mostly
> follows the sa
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> Add a wrapper for `drm_set_preferred_mode()` for our new
> `ConnectorGuard` type so we can set the preferred mode for RVKMS
> connectors.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/connector.rs | 6 ++
> 1 file chang
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> This is the same thing as OpaqueConnector and OpaqueConnectorState, but for
> CRTCs now.
>
> Signed-off-by: Lyude Paul
>
> ---
>
> TODO:
> * Add upcast functions
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs |
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Returns the Framebuffer currently assigned in an atomic plane state.
A bit unrelated to this patch, but can you have more than one framebuffer
active?
i.e.: for things like overlays, etc
>
> Signed-off-by: Lyude Paul
> ---
> rust
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Optional trait methods for implementing the atomic_begin and atomic_flush
> callbacks for a CRTC.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs | 78 -
> 1 file changed, 76 insert
Hi Lyude
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Optional trait methods for implementing the atomic_enable and
> atomic_disable callbacks of a CRTC.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs | 76 -
> 1 file changed, 74 inser
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> We start off by introducing wrappers for the first important type of mode
> object: a DRM display connector. This introduces Connector DriverConnector> and ConnectorState. Both
> DriverConnector and DriverConnectorState must be implemen
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> The KMS API has a very consistent idea of a "mode config object", which
> includes any object with a drm_mode_object struct embedded in it. These
> objects have their own object IDs which DRM exposes to userspace, and we
> introduce the
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> For drivers which use the shmem based GEM helpers, they'll want to use the
> relevant drm_fbdev_shmem_setup() functions instead of the
> drm_fbdev_dma_setup() functions. To allow for this, introduce another
> FbdevImpl that such drivers
Hi Lyude,
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> This commit adds some traits for registering DRM devices with KMS support,
> implemented through the kernel::drm::kms::Kms trait. Devices which don't
> have KMS support can simply use PhantomData.
>
> Signed-off-by: Lyude Paul
>
> --
Hi Lyude, sorry for the late review!
> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>
> This adds some very basic rust bindings for fourcc. We only have a single
> format code added for the moment, but this is enough to get a driver
> registered.
>
> TODO:
> * Write up something to automatically
Hi Lyude
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A quick note: this is one of my favorite bindings so far :). It sounds way
> overly complicated, but so far actually writing implementations of this in
> rust has been a breeze.
>
> Anyway: RVKMS has a slightly different atomic_commit_t
Hi Lyude,
> On 27 Nov 2024, at 18:21, Lyude Paul wrote:
>
> On Tue, 2024-11-26 at 15:18 -0300, Daniel Almeida wrote:
>> Hi Lyude,
>>
>>> On 30 Sep 2024, at 20:09, Lyude Paul wrote:
>>>
>>> This commit adds some traits for registering DRM devic
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> This commit adds bindings for implementing vblank support for a driver's
> CRTCs. These bindings are optional, to account for the fact that not all
> drivers have dedicated hardware vblanks.
>
> In order to accomplish this, we introduc
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Now that we've added all of the bits that we need for the KMS API, it's
> time to introduce rvkms! This is a port of the VKMS driver to rust, with
> the intent of acting as an example usecase of the KMS bindings that we've
> come up wit
Hi Lyude,
> On 3 Dec 2024, at 19:41, Lyude Paul wrote:
>
> On Tue, 2024-11-26 at 15:18 -0300, Daniel Almeida wrote:
>>
>>
>>> +
>>> +/// Return a [`ModeConfigInfo`] structure for this [`device::Device`].
>>> +fn mod
Hi Lyude,
>>>
>>> +impl FormatInfo {
>>> +// SAFETY: `ptr` must point to a valid instance of a
>>> `bindings::drm_format_info`
>>> +pub(super) unsafe fn from_raw<'a>(ptr: *const
>>> bindings::drm_format_info) -> &'a Self {
>>
>> I think FormatInfoRef would be more appropriate, since yo
Asahi Lina
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index
5ab351409312b5a0de542df2b63627
From: Asahi Lina
There doesn't seem to be a way for the Rust bindings to get a
compile-time constant reference to drm_gem_shmem_vm_ops, so we need to
duplicate that structure in Rust... this isn't nice...
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
drive
01dd5500a0c2533c64bdb3f5360567
change-id: 20250320-gpuvm-29d3e0726f34
Best regards,
--
Daniel Almeida
Hi Miguel, thanks for having a look at this:
> On 24 Mar 2025, at 14:36, Miguel Ojeda
> wrote:
>
> Hi Daniel,
>
> A few quick notes for future versions on style/docs to try to keep
> things consistent upstream -- not an actual review.
>
> On Mon, Mar 24, 202
GpuVm::lock(), which is a similar approach as the one
taken by CondVar.
It is up to drivers to make sure that the guard indeed provides the
required locking. Any operations that modifies the interval tree is only
available after the VM has been locked as per above.
Signed-off-by: Asahi Lina
Co-dev
From: Asahi Lina
This is just for basic usage in the DRM shmem abstractions for implied
locking, not intended as a full DMA Reservation abstraction yet.
Signed-off-by: Asahi Lina
---
rust/bindings/bindings_helper.h | 4 +++-
rust/helpers/dma-resv.c | 13 +
rust/helpers/hel
: Daniel Almeida
---
rust/bindings/bindings_helper.h | 3 +
rust/helpers/drm.c | 46 +
rust/helpers/helpers.c | 1 +
rust/helpers/scatterlist.c | 13 ++
rust/kernel/drm/gem/mod.rs | 2 +
rust/kernel/drm/gem/shmem.rs| 422
drm_gem_private_object_init.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/drm_gem.c | 1 +
drivers/gpu/drm/drm_prime.c | 5 +
include/drm/drm_gem.h | 8
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
From: Asahi Lina
This allows drivers to control whether a given GEM object is allowed to
be exported via PRIME to other drivers.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
rust/kernel/drm/gem/mod.rs | 13 +
rust/kernel/drm/gem/shmem.rs | 4
2 files
From: Asahi Lina
This is just for basic usage in the DRM shmem abstractions for implied
locking, not intended as a full DMA Reservation abstraction yet.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
rust/bindings/bindings_helper.h | 1 +
rust/helpers/dma-resv.c | 13
From: Asahi Lina
Allow a GEM object to share another object's DMA reservation, for use
with drm_gpuvm. To keep memory safety, we hold a reference to the GEM
object owning the resv, and drop it when the child object is freed.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
-8bb647b66b1c
Best regards,
--
Daniel Almeida
GpuVm::lock(), which is a similar approach as the one
taken by CondVar.
It is up to drivers to make sure that the guard indeed provides the
required locking. Any operations that modifies the interval tree is only
available after the VM has been locked as per above.
Signed-off-by: Asahi Lina
Co-dev
rs.c | 2 +
rust/kernel/drm/gpuvm.rs| 807
rust/kernel/drm/mod.rs | 2 +
6 files changed, 855 insertions(+)
---
base-commit: e7de41cc4b01dd5500a0c2533c64bdb3f5360567
change-id: 20250320-gpuvm-29d3e0726f34
Best regards,
--
Daniel Almeida
From: Asahi Lina
This is just for basic usage in the DRM shmem abstractions for implied
locking, not intended as a full DMA Reservation abstraction yet.
Signed-off-by: Asahi Lina
---
rust/bindings/bindings_helper.h | 1 +
rust/helpers/dma-resv.c | 13 +
rust/helpers/helper
Hi Danilo,
FYI, most of this patch still retains the original code from the Asahi project,
> On 22 Apr 2025, at 18:16, Danilo Krummrich wrote:
>
> (Not a full review, but some things that took my attention from a brief look.)
>
> On Tue, Apr 22, 2025 at 01:41:53PM -0300, Danie
Hi Alex,
> On 17 Feb 2025, at 11:04, Alexandre Courbot wrote:
>
> It is common to build a u64 from its high and low parts obtained from
> two 32-bit registers. Conversely, it is also common to split a u64 into
> two u32s to write them into registers. Add an extension trait for u64
> that implem
Hi Alex,
> On 17 Feb 2025, at 11:04, Alexandre Courbot wrote:
>
> Signed-off-by: Alexandre Courbot
> ---
> rust/kernel/error.rs | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/rust/kernel/error.rs b/rust/kernel/error.rs
> index
> f6ecf09cb65f4ebe9b88da68b3830ae79aa4f182..8858eb13b3df6
> On 19 Feb 2025, at 17:23, Dave Airlie wrote:
>
> On Thu, 20 Feb 2025 at 06:22, John Hubbard wrote:
>>
>> On 2/19/25 4:51 AM, Alexandre Courbot wrote:
>>> Yes, that looks like the optimal way to do this actually. It also
>>> doesn't introduce any overhead as the destructuring was doing both
Hi Alyssa,
>
+/**
+ * @DRM_ASAHI_BIND_SINGLE_PAGE: Map a single page of the BO
repeatedly
+ * across the VA range.
+ *
+ * This is useful to fill a VA range with scratch pages or zero
pages.
+ * It is intended as a mechanism t
Hi Lyude,
> On 5 Mar 2025, at 19:59, Lyude Paul wrote:
>
> Next up is filling out some of the basic connector hotplugging callbacks -
> which we'll need for setting up the fbdev helpers for KMS devices. Note
> that connector hotplugging in DRM follows a BFL scheme: pretty much all
> probing is p
will live as long as
> // the GEM object lives, hence the pointer must be valid.
> -unsafe { &*self.dev }
> +unsafe { self.dev.as_ref() }
> }
>
> fn as_raw(&self) -> *mut bindings::drm_gem_object {
> --
> 2.48.1
>
>
Reviewed-by: Daniel Almeida
er is null befoe calling as_ref(),
> ensuring that `ptr` is a
> +// valid pointer to an initialized `Self`.
> +// XXX: The expect lint here is to workaround
> +// https://github.com/rust-lang/rust-clippy/issues/13024
> +#[expect(clippy::undocumented_unsafe_blocks)]
> +let obj = (!ptr.is_null())
> +.then(|| unsafe { Self::as_ref(ptr) })
> +.ok_or(ENOENT)?;
> +
> +// SAFETY:
> +// - We take ownership of the reference of `drm_gem_object_lookup()`.
> +// - Our `NonNull` comes from an immutable reference, thus ensuring
> it is a valid pointer to
> +// `Self`.
> +Ok(unsafe { ARef::from_raw(obj.into()) })
> }
>
> /// Creates an mmap offset to map the object from userspace.
> --
> 2.48.1
>
>
With the extra safety requirement,
Reviewed-by: Daniel Almeida
ments are valid per the type invariant.
> Ok(unsafe {
> -bindings::drm_vma_node_offset_addr(ptr::addr_of_mut!(
> -(*self.into_gem_obj().get()).vma_node
> -))
> +
> bindings::drm_vma_node_offset_addr(ptr::addr_of_mut!((*self.as_gem_obj()).vma_node))
Hmm, I thought we were on a quest to remove addr_of_mut!() in favor of &raw mut?
Anyways, this is again orthogonal to your patch.
> })
> }
> }
> --
> 2.48.1
>
>
This looks good.
Reviewed-by: Daniel Almeida
get(self.as_raw()) };
> -}
> -
> -unsafe fn dec_ref(obj: NonNull) {
> -// SAFETY: `obj` is a valid pointer to an `Object`.
> -let obj = unsafe { obj.as_ref() };
> -
> -// SAFETY: The safety requirements guarantee that the refcount is
> non-zero.
> -unsafe { bindings::drm_gem_object_put(obj.as_raw()) }
> -}
> -}
> -
> impl super::private::Sealed for Object {}
>
> impl Deref for Object {
> --
> 2.48.1
>
>
Reviewed-by: Daniel Almeida
Hi Lyude,
> On 5 Mar 2025, at 19:59, Lyude Paul wrote:
>
> This adds some very basic rust bindings for fourcc. We only have a single
> format code added for the moment, but this is enough to get a driver
> registered.
>
> Signed-off-by: Lyude Paul
>
> ---
> V3:
> * Drop FormatList and Modifie
Hi Lyude,
> On 5 Mar 2025, at 19:59, Lyude Paul wrote:
>
> This commit adds some traits for registering DRM devices with KMS support,
> implemented through the kernel::drm::kms::KmsDriver trait. Devices which
> don't have KMS support can simply use PhantomData.
>
> Signed-off-by: Lyude Paul
>
> On 5 Mar 2025, at 19:59, Lyude Paul wrote:
>
> We start off by introducing wrappers for the first important type of mode
> object: a DRM display connector. This introduces Connector DriverConnector> and ConnectorState. Both
> DriverConnector and DriverConnectorState must be implemented by KM
Hi Lyude,
This patch is similar to the last one, I see that most of my
comments also apply here.
> On 5 Mar 2025, at 19:59, Lyude Paul wrote:
>
> The next step is adding a set of basic bindings to create a plane, which
> has to happen before we can create a CRTC (since we need to be able to at
>
> The lock might be held already by the driver or by TTM when things are called
> from TTM callbacks.
>
> This is why GPUVM never takes locks by itself, but asserts that the correct
> lock
> is held.
>
> I think we really want to get proof by the driver by providing lock guard
> references.
Hi Christian
> On 22 May 2025, at 05:44, Christian König wrote:
>
> On 5/21/25 22:29, Lyude Paul wrote:
>> From: Asahi Lina
>>
>> This is just for basic usage in the DRM shmem abstractions for implied
>> locking, not intended as a full DMA Reservation abstraction yet.
>
> Looks good in genera
Hi Beata,
> On 19 Jun 2025, at 07:21, Beata Michalska wrote:
>
> With the Opaque, the expectations are that Rust should not make any
> assumptions on the layout or invariants of the wrapped C types.
> That runs rather counter to ioctl arguments, which must adhere to
> certain data-layout constra
Hi Benno,
> On 19 Jun 2025, at 08:01, Benno Lossin wrote:
>
> On Thu Jun 19, 2025 at 12:55 PM CEST, Danilo Krummrich wrote:
>> On Thu, Jun 19, 2025 at 12:21:02PM +0200, Beata Michalska wrote:
>>> diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
>>> index 445639404fb7..12b29613167
Hi Boris,
> On 19 Jun 2025, at 08:57, Boris Brezillon
> wrote:
>
> Hi,
>
> On Fri, 13 Jun 2025 13:42:59 -0300
> Daniel Almeida wrote:
>
>> Danilo,
>>
>>
>>>
>>>
>>>>>> +// SAFETY: DRM GpuVmBo objects are alw
> On 19 Jun 2025, at 09:26, Daniel Almeida wrote:
>
> Hi Benno,
>
>> On 19 Jun 2025, at 08:01, Benno Lossin wrote:
>>
>> On Thu Jun 19, 2025 at 12:55 PM CEST, Danilo Krummrich wrote:
>>> On Thu, Jun 19, 2025 at 12:21:02PM +0200, Beata Michalska w
Hi Beata,
> There is no concurrent access nor shared references, unless the
> handler decides otherwise
It can’t do so in safe code. There is no way to manufacture a shared
reference from a mutable one in safe code and if it passes that to C, then
it’s already using a unsafe block for the ffi ca
Danilo,
>
>
+// SAFETY: DRM GpuVmBo objects are always reference counted and the
get/put functions
+// satisfy the requirements.
+unsafe impl AlwaysRefCounted for GpuVmBo {
+fn inc_ref(&self) {
+// SAFETY: The drm_gpuvm_get function satisfies the requi
0d6b..f369da5b12fb876f23eda8ea7665990919f3960c
100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -7,6 +7,7 @@
pub mod file;
pub mod gem;
pub mod ioctl;
+pub mod mm;
pub use self::device::Device;
pub use self::driver::Driver;
---
base-commit: dc35ddcf97e99b18559d0855071030e664aae44d
change-id: 20250623-topics-tyr-drm_mm-d1d43d436311
Best regards,
--
Daniel Almeida
eemed both somewhat sufficient
and required for upcoming drivers.
Note that all operations provided were tested on a real driver and on a
real device. Specifically, all operations so far are required.
Signed-off-by: Asahi Lina
Co-developed-by: Daniel Almeida
Signed-off-by: Daniel Almeida
---
Hi
Hi Danilo,
> The lock might be held already by the driver or by TTM when things are called
> from TTM callbacks.
>
> This is why GPUVM never takes locks by itself, but asserts that the correct
> lock
> is held.
>
> I think we really want to get proof by the driver by providing lock guard
> refe
Hi Danilo,
[…]
>
>> +
>> +impl OpMap {
>> +/// Returns the base address of the new mapping.
>> +#[inline]
>> +pub fn addr(&self) -> u64 {
>> +self.0.va.addr
>> +}
>> +
>> +/// Returns the range of the new mapping.
>> +#[inline]
>> +pub fn range(&self) -> u64 {
I’ll fix the missing “rust: drm:” tags on a v2.
— Daniel
Signed-off-by: Alice Ryhl
Co-developed-by: Beata Michalska
Signed-off-by: Beata Michalska
Co-developed-by: Carsten Haitzler
Signed-off-by: Carsten Haitzler
Co-developed-by: Rob Herring
Signed-off-by: Rob Herring
Signed-off-by: Daniel Almeida
---
The development of Tyr itself started in
1 - 100 of 135 matches
Mail list logo
