| Age | Commit message (Collapse) | Author |
|---|
|
They are less and easier to track than the public ones. The macro
drm_public will be going away by the end of the series.
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
4c2766b (drm_mmap/drm_unmap) brought this error for every .c file that
was not #including config.h:
In file included from private.h:4:0,
from abi16.c:29:
../libdrm.h: In function 'drm_munmap':
../libdrm.h:81:4: error: size of unnamed array is negative
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
Hiding fd_device_del_locked, and fd_cleanup_bo_cache.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
|
|
Don't even bother trying DRM_KGSL_GEM_CREATE_FD. It hasn't worked since
(afaict) 2.6.35 kernels. And in some cases seems to cause some
problems. Instead just allocate a minimum size dummy object (just for
purposes of having a handle) and then mmap the framebuffer as user-mem
(which is deprecated, but seems to still work.. and as far as I can tell
is the best option for now).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Workloads which create many transient buffers cause significant CPU
overhead in buffer allocation, zeroing, cache maint, and mmap setup.
By caching and re-using existing buffers, the CPU overhead drops
significantly. See:
http://bloggingthemonkey.blogspot.com/2013/09/freedreno-update-moar-fps.html
A simple time based policy is used for purging the cache. Once the
kernel supports it, we could use madvise style API to handle memory
pressure scenarios a bit better.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Split out common code and backend. Current backend is for 'kgsl'
android driver, but a new backend will provide support for the
upstream msm drm/kms driver.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
