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
57 matches
Mail list logo
