On SoCs with DMM/TILER, we have two ways to allocate buffers: normal
dma_alloc or via DMM (which basically functions as an IOMMU). DMM can
map 128MB at a time, and we only map the DMM buffers when they are used
(i.e. not at alloc time). If DMM is present, omapdrm always uses DMM.
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 DMM if the userspace knows it needs more than
128M of memory at the same time.
OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's not
much use for this flag at the moment, as on platforms with DMM it is
used by default, but it's here for completeness.
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 DMM
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>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-9-jjhiblot@ti.com
OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not
bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for
the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK
instead.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-6-jjhiblot@ti.com
Many user space API headers have licensing information, which is either
incomplete, badly formatted or just a shorthand for referring to the
license under which the file is supposed to be. This makes it hard for
compliance tools to determine the correct license.
Update these files with an SPDX license identifier. The identifier was
chosen based on the license information in the file.
GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license
identifier with the added 'WITH Linux-syscall-note' exception, which is
the officially assigned exception identifier for the kernel syscall
exception:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
This exception makes it possible to include GPL headers into non GPL
code, without confusing license compliance tools.
Headers which have either explicit dual licensing or are just licensed
under a non GPL license are updated with the corresponding SPDX
identifier and the GPLv2 with syscall exception identifier. The format
is:
((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE)
SPDX license identifiers are a legally binding shorthand, which can be
used instead of the full boiler plate text. The update does not remove
existing license information as this has to be done on a case by case
basis and the copyright holders might have to be consulted. This will
happen in a separate step.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne. See the previous patch in this series for the
methodology of how this patch was researched.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The omapdrm driver uses a custom API to synchronize with the SGX GPU.
This is unusable as such in the mainline kernel as the API is only
partially implemented and requires additional out-of-tree patches.
Furthermore, as no SGX driver is available in the mainline kernel, the
API can't be considered as a stable mainline API.
Now that the driver supports synchronization through fences, remove
legacy buffer synchronization support. The two userspace ioctls are
turned into no-ops to avoid breaking userspace and will be removed in
the future.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Consistently use types from linux/types.h like in other uapi drm/*_drm.h
header files to fix the following drm/omap_drm.h userspace compilation
errors:
/usr/include/drm/omap_drm.h:36:2: error: unknown type name 'uint64_t'
uint64_t param; /* in */
/usr/include/drm/omap_drm.h:37:2: error: unknown type name 'uint64_t'
uint64_t value; /* in (set_param), out (get_param) */
/usr/include/drm/omap_drm.h:56:2: error: unknown type name 'uint32_t'
uint32_t bytes; /* (for non-tiled formats) */
/usr/include/drm/omap_drm.h:58:3: error: unknown type name 'uint16_t'
uint16_t width;
/usr/include/drm/omap_drm.h:59:3: error: unknown type name 'uint16_t'
uint16_t height;
/usr/include/drm/omap_drm.h:65:2: error: unknown type name 'uint32_t'
uint32_t flags; /* in */
/usr/include/drm/omap_drm.h:66:2: error: unknown type name 'uint32_t'
uint32_t handle; /* out */
/usr/include/drm/omap_drm.h:67:2: error: unknown type name 'uint32_t'
uint32_t __pad;
/usr/include/drm/omap_drm.h:77:2: error: unknown type name 'uint32_t'
uint32_t handle; /* buffer handle (in) */
/usr/include/drm/omap_drm.h:78:2: error: unknown type name 'uint32_t'
uint32_t op; /* mask of omap_gem_op (in) */
/usr/include/drm/omap_drm.h:82:2: error: unknown type name 'uint32_t'
uint32_t handle; /* buffer handle (in) */
/usr/include/drm/omap_drm.h:83:2: error: unknown type name 'uint32_t'
uint32_t op; /* mask of omap_gem_op (in) */
/usr/include/drm/omap_drm.h:88:2: error: unknown type name 'uint32_t'
uint32_t nregions;
/usr/include/drm/omap_drm.h:89:2: error: unknown type name 'uint32_t'
uint32_t __pad;
/usr/include/drm/omap_drm.h:93:2: error: unknown type name 'uint32_t'
uint32_t handle; /* buffer handle (in) */
/usr/include/drm/omap_drm.h:94:2: error: unknown type name 'uint32_t'
uint32_t pad;
/usr/include/drm/omap_drm.h:95:2: error: unknown type name 'uint64_t'
uint64_t offset; /* mmap offset (out) */
/usr/include/drm/omap_drm.h:102:2: error: unknown type name 'uint32_t'
uint32_t size; /* virtual size for mmap'ing (out) */
/usr/include/drm/omap_drm.h:103:2: error: unknown type name 'uint32_t'
uint32_t __pad;
Fixes: ef6503e891 ("drm: Kbuild: add omap_drm.h to the installed headers")
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Remove unused defines related to SGX plugin which are not used.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Now that the omapdss interface has been reworked so that omapdrm can use
dispc directly, we have been able to fix the remaining functional kms
issues with omapdrm. And in the mean time the PM sequencing and many
other of that open issues have been solved. So I think it makes sense
to finally move omapdrm out of staging.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Sean Paul