Re: [PATCH 2/2] drm/omap: add OMAP_BO flags to affect buffer allocation

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Tomi,

Thank you for the patch.

On Monday 08 May 2017 11:51:22 Tomi Valkeinen wrote:
> On SoCs with TILER, we have to ways to allocate buffers: normal

s/to ways/two ways/

> dma_alloc or via TILER (which basically functions as an IOMMU). TILER
> can map 128MB at a time, and we only map the TILER buffers when they are
> used (i.e. not at alloc time). If TILER is present, omapdrm always
> uses TILER.
> 
> There are use cases that require lots of big buffers that are being used
> at the same time by different IPs. At the moment the userspace has a
> hard maximum of 128MB.
> 
> This patch adds three new flags that can be used by the userspace to
> solve the situation:
> 
> OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
> This can be used to avoid TILER if the userspace knows it needs more
> than 128M of memory at the same time.
> 
> OMAP_BO_MEM_TILER: The driver will use TILER to get the memory. There's
> nto much use for this flag at the moment, but it's here for

s/nto/not/

> completeness.

I assume the OMAP_BO_MEM_CONTIG and OMAP_BO_MEM_TILER flags are supposed to be 
mutually exclusive ? 

> OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and keep
> it pinned. This can be used to 1) get an error at alloc time if TILER
> space is full, and 2) get rid of the constant pin/unpin operations which
> may have some effect on performance.
> 
> If none of the flags are given, the behavior is the same as currently.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  drivers/gpu/drm/omapdrm/omap_gem.c | 23 ++++++++++++++++++++++-
>  include/uapi/drm/omap_drm.h        |  3 +++
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c index 5d73dccc1383..90ae8615f6c6
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -1292,6 +1292,9 @@ void omap_gem_free_object(struct drm_gem_object *obj)
>  	list_del(&omap_obj->mm_list);
>  	spin_unlock(&priv->list_lock);
> 
> +	if (omap_obj->flags & OMAP_BO_MEM_PIN)
> +		omap_gem_put_paddr_locked(obj);
> +
>  	/* this means the object is still pinned.. which really should
>  	 * not happen.  I think..
>  	 */
> @@ -1338,6 +1341,11 @@ struct drm_gem_object *omap_gem_new(struct drm_device
> *dev, return NULL;
>  		}
> 
> +		if (flags & OMAP_BO_MEM_CONTIG) {
> +			dev_err(dev->dev, "Tiled buffers require TILER 
memory\n");

I think we need more sanity checks, only part of the faulty cases are caught. 
The semantics of the new flags need to be defined more precisely and properly 
documented (with kerneldoc for all BO flags for instance). In particular, 
interactions between OMAP_BO_MEM_TILER and the existing OMAP_BO_TILED_* flags 
are not clear to me. I wonder whether we really should introduce 
OMAP_BO_MEM_TILER, relying on OMAP_BO_TILED seems enough to me.

In addition to this, I think there's a rule that new userspace APIs need a 
userspace implementation, and not just in libdrm, but in Xorg, Weston, Android 
or a similar project.

> +			return NULL;
> +		}
> +
>  		/*
>  		 * Tiled buffers are always shmem paged backed. When they are
>  		 * scanned out, they are remapped into DMM/TILER.
> @@ -1351,7 +1359,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device
> *dev, */
>  		flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
>  		flags |= tiler_get_cpu_cache_flags();
> -	} else if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
> +	} else if ((flags & OMAP_BO_MEM_CONTIG) ||
> +		((flags & OMAP_BO_SCANOUT) && !priv->has_dmm)) {
>  		/*
>  		 * OMAP_BO_SCANOUT hints that the buffer doesn't need to be
>  		 * tiled. However, to lower the pressure on memory allocation,
> @@ -1411,12 +1420,24 @@ struct drm_gem_object *omap_gem_new(struct
> drm_device *dev, goto err_release;
>  	}
> 
> +	if (flags & OMAP_BO_MEM_PIN) {
> +		dma_addr_t dummy;
> +
> +		ret = omap_gem_get_paddr(obj, &dummy, true);

Wouldn't it be better to modify omap_gem_get_paddr() to accept a NULL second 
parameter ?

> +		if (ret)
> +			goto err_free_dma;
> +	}
> +
>  	spin_lock(&priv->list_lock);
>  	list_add(&omap_obj->mm_list, &priv->obj_list);
>  	spin_unlock(&priv->list_lock);
> 
>  	return obj;
> 
> +err_free_dma:
> +	if (flags & OMAP_BO_MEM_DMA_API)
> +		dma_free_writecombine(dev->dev, size,
> +				omap_obj->vaddr, omap_obj->paddr);
>  err_release:
>  	drm_gem_object_release(obj);
>  err_free:
> diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
> index 7fb97863c945..a976e8682c5f 100644
> --- a/include/uapi/drm/omap_drm.h
> +++ b/include/uapi/drm/omap_drm.h
> @@ -40,6 +40,9 @@ struct drm_omap_param {
>  #define OMAP_BO_SCANOUT		0x00000001	/* scanout capable
>  (phys contiguous) */
> #define OMAP_BO_CACHE_MASK	0x00000006	/* cache type mask, see cache
> modes */
> #define OMAP_BO_TILED_MASK	0x00000f00	/* tiled mapping mask, see
> tiled modes */
> +#define OMAP_BO_MEM_CONTIG	0x00000008	/* only use contiguous dma mem
> */
> +#define OMAP_BO_MEM_TILER	0x00000010	/* only use TILER mem */
> +#define OMAP_BO_MEM_PIN		0x00000020	/* pin the buffer when
> allocating */
> 
>  /* cache modes */
>  #define OMAP_BO_CACHED		0x00000000	/* default */

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel