>
> 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 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
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
> 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,
> 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
>
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
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
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
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
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
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
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
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
-8bb647b66b1c
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
01dd5500a0c2533c64bdb3f5360567
change-id: 20250320-gpuvm-29d3e0726f34
Best regards,
--
Daniel Almeida
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
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
---
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
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
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
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
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
: 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
> 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 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
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 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
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 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 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 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 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,
> 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:
>
> 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:
>
> 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: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:
>
> 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
> 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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: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:
>
> 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
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: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: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: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: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: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: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:
>
> 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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:
>
> 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
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
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
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
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
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
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
/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
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
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 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;
>> +
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 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
> 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 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
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
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
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 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
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
87 matches
Mail list logo
