[WIP RFC v2 03/35] rust: drm/kms/fbdev: Add FbdevShmem

Daniel Almeida daniel.almeida at collabora.com
Tue Nov 26 19:58:16 UTC 2024


Hi Lyude,

> On 30 Sep 2024, at 20:09, Lyude Paul <lyude at redhat.com> 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 can use instead of FbdevDma.
> 
> Signed-off-by: Lyude Paul <lyude at redhat.com>
> ---
> rust/bindings/bindings_helper.h    |  1 +
> rust/kernel/drm/kms/fbdev.rs       |  8 +++++++-
> rust/kernel/drm/kms/fbdev/shmem.rs | 33 ++++++++++++++++++++++++++++++
> 3 files changed, 41 insertions(+), 1 deletion(-)
> create mode 100644 rust/kernel/drm/kms/fbdev/shmem.rs
> 
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 4a8e44e11c96a..9803e0ecac7c1 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -13,6 +13,7 @@
> #include <drm/drm_file.h>
> #include <drm/drm_fourcc.h>
> #include <drm/drm_fbdev_dma.h>
> +#include <drm/drm_fbdev_shmem.h>
> #include <drm/drm_gem.h>
> #include <drm/drm_gem_framebuffer_helper.h>
> #include <drm/drm_gem_shmem_helper.h>
> diff --git a/rust/kernel/drm/kms/fbdev.rs b/rust/kernel/drm/kms/fbdev.rs
> index bdf97500137d8..a1035d948949a 100644
> --- a/rust/kernel/drm/kms/fbdev.rs
> +++ b/rust/kernel/drm/kms/fbdev.rs
> @@ -5,6 +5,12 @@
> use crate::{private::Sealed, drm::{kms::*, device::Device, gem}};
> use bindings;
> 
> +#[cfg(CONFIG_DRM_GEM_SHMEM_HELPER = "y")]
> +mod shmem;
> +
> +#[cfg(CONFIG_DRM_GEM_SHMEM_HELPER = "y")]
> +pub use shmem::FbdevShmem;
> +
> pub(crate) mod private {
>     use super::*;
> 
> @@ -17,7 +23,7 @@ pub trait FbdevImpl {
> /// The main trait for a driver's DRM implementation.
> ///
> /// Drivers are expected not to implement this directly, and to instead use one of the objects
> -/// provided by this module such as [`FbdevDma`].
> +/// provided by this module such as [`FbdevDma`] and [`FbdevShmem`].
> pub trait FbdevImpl: private::FbdevImpl {}
> 
> /// The fbdev implementation for drivers using the gem DMA helpers.
> diff --git a/rust/kernel/drm/kms/fbdev/shmem.rs b/rust/kernel/drm/kms/fbdev/shmem.rs
> new file mode 100644
> index 0000000000000..16c3533ad2a0f
> --- /dev/null
> +++ b/rust/kernel/drm/kms/fbdev/shmem.rs
> @@ -0,0 +1,33 @@
> +//! The GEM shmem fbdev implementation for rust.
> +//!
> +//! This module provides an Fbdev implementation that can be used by Rust KMS drivers using the GEM
> +//! shmem helpers provided by [`shmem`].
> +
> +use core::marker::*;
> +use crate::drm::{gem::shmem, kms::*, device::Device};
> +use super::{private::FbdevImpl as FbdevImplPrivate, FbdevImpl};
> +use bindings;
> +
> +/// The fbdev implementation for drivers using the gem shmem helpers.
> +///
> +/// KMS Drivers which use the GEM helpers provided by [`shmem`] should use this for [`Kms::Fbdev`].
> +pub struct FbdevShmem<T: Driver>(PhantomData<T>);

As I said in the preceding patch, I find this a bit confusing. On one hand, it seems like there’s the possibility
of a mismatch when reading the paragraph above, 

> +
> +impl<T, G> FbdevImplPrivate for FbdevShmem<T>
> +where
> +    T: Driver<Object = shmem::Object<G>>,
> +    G: shmem::DriverObject

But on the other hand, you seem to be enforcing some consistency using bounds.

Again, a small example would be nice in a future iteration.

> +{
> +    #[inline]
> +    fn setup_fbdev<D: Driver>(drm: &Device<D>, mode_config_info: &ModeConfigInfo) {
> +        // SAFETY: Our implementation bounds are proof that this driver is using the gem shmem
> +        // helpers
> +        unsafe { bindings::drm_fbdev_shmem_setup(drm.as_raw(), mode_config_info.preferred_depth) };
> +    }
> +}
> +
> +impl<T, G> FbdevImpl for FbdevShmem<T>
> +where
> +    T: Driver<Object = shmem::Object<G>>,
> +    G: shmem::DriverObject
> +{}
> -- 
> 2.46.1
> 

Barring the comment above, the rest of this patch looks good to me.

— Daniel



More information about the dri-devel mailing list