| Age | Commit message (Collapse) | Author | 
|---|
|  | 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> | 
|  | Userspace needs to know the patch-revision in addition to just the
gpu-id (ie. 320, 305, etc).
Signed-off-by: Rob Clark <robclark@freedesktop.org> | 
|  | 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> |