[PATCH v4 4/4] drm: allow to use mmuless SoC

Daniel Vetter daniel at ffwll.ch
Wed Dec 7 14:49:10 UTC 2016


On Wed, Dec 07, 2016 at 04:32:44PM +0200, Laurent Pinchart wrote:
> Hi Benjamin,
> 
> Thank you for the patch.
> 
> On Wednesday 07 Dec 2016 11:06:51 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>
> > ---
> >  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
> 
> s/GEM care/the GEM core/
> 
> > +: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.
> 
> I would add
> 
> "It's intended to be used as a direct handler for the :c:type:`struct 
> file_operations <file_operations>` .get_unmapped_area() operation."

If' it's kernel-doc you can use shortcuts to autogenerate the links. Only
works with kernel-doc comments though, not with .rst in general:

"It's intended to be used as a direct handler for the struct 
&file_operations .get_unmapped_area() operation."

And +1 from me on sprinkling links all over docs. We might want to do that
for all the fbdev fops, for consistency.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list