[PATCH v4 4/4] drm: allow to use mmuless SoC
Daniel Vetter
daniel at ffwll.ch
Wed Dec 7 10:27:41 UTC 2016
On Wed, Dec 07, 2016 at 11:06:51AM +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add a cma helper
> function to help implementing mmuless display driver
>
> version 4:
> - add documentation about drm_gem_cma_get_unmapped_area()
> - stub it MMU case
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at linaro.org>
Shouldn't we also update DRM_FB_HELPER_DEFAULT_OPS? With that addressed
this all looks good to me.
-Daniel
> ---
> Documentation/gpu/drm-mm.rst | 11 ++++++
> drivers/gpu/drm/Kconfig | 4 +--
> drivers/gpu/drm/drm_gem_cma_helper.c | 69 ++++++++++++++++++++++++++++++++++++
> include/drm/drm_gem_cma_helper.h | 17 +++++++++
> 4 files changed, 99 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index bca8085..6e7efab 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -303,6 +303,17 @@ created.
> Drivers that want to map the GEM object upfront instead of handling page
> faults can implement their own mmap file operation handler.
>
> +For platforms without MMU GEM care provides a helper method
> +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call
> +this to get a proposed address for the mapping.
> +
> +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the
> +struct :c:type:`struct file_operations <file_operations>` get_unmapped_area
> +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
> +
> +More detailed information about get_unmapped_area can be found in
> +Documentation/nommu-mmap.txt
> +
> Memory Coherency
> ----------------
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83ac815..0eae4ad 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -6,7 +6,7 @@
> #
> menuconfig DRM
> tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
> - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
> + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> select HDMI
> select FB_CMDLINE
> select I2C
> @@ -98,7 +98,7 @@ config DRM_LOAD_EDID_FIRMWARE
>
> config DRM_TTM
> tristate
> - depends on DRM
> + depends on DRM && MMU
> help
> GPU memory management subsystem for devices with multiple
> GPU memory types. Will be enabled automatically if a device driver
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 1d6c335..01016b1 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -358,6 +358,75 @@ int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
>
> +#ifndef CONFIG_MMU
> +/**
> + * drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU cases
> + * @filp: file object
> + * @addr: memory address
> + * @len: buffer size
> + * @pgoff: page offset
> + * @flags: memory flags
> + *
> + * This function is used in noMMU platforms to propose address mapping
> + * for a given buffer.
> + *
> + * Returns:
> + * mapping address on success or a negative error code on failure
> + */
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags)
> +{
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *obj = NULL;
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> + struct drm_vma_offset_node *node;
> +
> + if (drm_device_is_unplugged(dev))
> + return -ENODEV;
> +
> + drm_vma_offset_lock_lookup(dev->vma_offset_manager);
> + node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
> + pgoff,
> + len >> PAGE_SHIFT);
> + if (likely(node)) {
> + obj = container_of(node, struct drm_gem_object, vma_node);
> + /*
> + * When the object is being freed, after it hits 0-refcnt it
> + * proceeds to tear down the object. In the process it will
> + * attempt to remove the VMA offset and so acquire this
> + * mgr->vm_lock. Therefore if we find an object with a 0-refcnt
> + * that matches our range, we know it is in the process of being
> + * destroyed and will be freed as soon as we release the lock -
> + * so we have to check for the 0-refcnted object and treat it as
> + * invalid.
> + */
> + if (!kref_get_unless_zero(&obj->refcount))
> + obj = NULL;
> + }
> +
> + drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
> +
> + if (!obj)
> + return -EINVAL;
> +
> + if (!drm_vma_node_is_allowed(node, priv)) {
> + drm_gem_object_unreference_unlocked(obj);
> + return -EACCES;
> + }
> +
> + cma_obj = to_drm_gem_cma_obj(obj);
> +
> + drm_gem_object_unreference_unlocked(obj);
> +
> + return cma_obj->vaddr ? (unsigned long)cma_obj->vaddr : -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_cma_get_unmapped_area);
> +#endif
> +
> #ifdef CONFIG_DEBUG_FS
> /**
> * drm_gem_cma_describe - describe a CMA GEM object for debugfs
> diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
> index acd6af8..180b586 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -53,6 +53,23 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
>
> extern const struct vm_operations_struct drm_gem_cma_vm_ops;
>
> +#ifndef CONFIG_MMU
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags);
> +#else
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags)
> +{
> + return -EINVAL;
> +}
> +#endif
> +
> #ifdef CONFIG_DEBUG_FS
> void drm_gem_cma_describe(struct drm_gem_cma_object *obj, struct seq_file *m);
> #endif
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list