Skip to content

GitLab

Switch branch/tag
  1. 14 Jan, 2014 2 commits
  3. 18 Dec, 2013 3 commits
  5. 28 Nov, 2013 1 commit
  7. 06 Nov, 2013 3 commits
  9. 04 Nov, 2013 1 commit
  11. 23 Oct, 2013 4 commits
  13. 11 Oct, 2013 1 commit
    • Daniel Vetter's avatar
      drm: Add separate Kconfig option for fbdev helpers · 92b6f89f
      Daniel Vetter authored 
      
For drivers which might want to disable fbdev legacy support.

Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.

v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!

v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.

Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
Acked-by: default avatarDave Airlie <airlied@linux.ie>
Reviewed-by: default avatarChon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      92b6f89f
  15. 09 Oct, 2013 1 commit
    • David Herrmann's avatar
      drm: kill ->gem_init_object() and friends · 16eb5f43
      David Herrmann authored 
      
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.

New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.

Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      16eb5f43
  17. 27 Aug, 2013 1 commit
    • David Herrmann's avatar
      drm: verify vma access in TTM+GEM drivers · acb46527
      David Herrmann authored 
      
GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
    access was denied.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      acb46527
  19. 19 Aug, 2013 1 commit
    • Daniel Vetter's avatar
      drm: remove FASYNC support · b0e898ac
      Daniel Vetter authored 
      
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.

First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...

Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.

No merged drm driver has ever done that.

After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:

commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <airlied@linux.ie>
Date:   Sun Aug 29 12:04:35 2004 +0000

    Drop GAMMA DRM from a great height ...

Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.

So stop this particular cargo-cult and rip it all out.

v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.

v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.

v4: Actually git add ... tsk.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      b0e898ac
  21. 18 Aug, 2013 1 commit
  23. 07 Aug, 2013 1 commit
  25. 06 Aug, 2013 1 commit
  27. 25 Jul, 2013 1 commit
    • David Herrmann's avatar
      drm/ttm: convert to unified vma offset manager · 72525b3f
      David Herrmann authored 
      
Use the new vma-manager infrastructure. This doesn't change any
implementation details as the vma-offset-manager is nearly copied 1-to-1
from TTM.

The vm_lock is moved into the offset manager so we can drop it from TTM.
During lookup, we use the vma locking helpers to take a reference to the
found object.
In all other scenarios, locking stays the same as before. We always
guarantee that drm_vma_offset_remove() is called only during destruction.
Hence, helpers like drm_vma_node_offset_addr() are always safe as long as
the node has a valid offset.

This also drops the addr_space_offset member as it is a copy of vm_start
in vma_node objects. Use the accessor functions instead.

v4:
 - remove vm_lock
 - use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock)

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Martin Peres <martin.peres@labri.fr>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarDave Airlie <airlied@gmail.com>
      72525b3f
  29. 24 Jul, 2013 3 commits
    • Dave Airlie's avatar
      qxl: convert qxl driver to proper use for reservations · 8002db63
      Dave Airlie authored 
      The recent addition of lockdep support to reservations and their subsequent
use by TTM showed up a number of potential problems with the way qxl was using
TTM objects.

a) it was allocating objects, and reserving them later without validating
underneath the reservation, which meant in extreme conditions the objects could
be evicted before the reservation ever used them.

b) it was reserving objects straight after allocating them, but with no
ability to back off should the reservations fail. It now allocates the necessary
objects then does a complete reservation pass on them to avoid deadlocks.

c) it had two lists per release tracking objects, unnecessary complicating
the reservation process.

This patch removes the dual object tracking, adds reservations ticket support
to the release and fence object handling. It then ports the internal fb
drawing code and the userspace facing ioctl to use the new interfaces properly,
along with cleanup up the error ...
      8002db63
    • Dave Airlie's avatar
      qxl: allow creation of pre-pinned objects and use for releases. · 4f49ec92
      Dave Airlie authored 
      
In order to fix an issue with reservations we need to create the releases
as pre-pinned objects, this changes the placement interface and bo creation
interface to allow creating pinned objects to save nested reservations later.

This is just a stepping stone to main fix which follows to actually fix how
qxl deals with reservations.
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      4f49ec92
    • Dave Airlie's avatar
      drm/qxl: add delayed fb operations · 0665f9f8
      Dave Airlie authored 
      
Due to the nature of qxl hw we cannot queue operations while in an irq
context, so we queue these operations as best we can until atomic allocations
fail, and dequeue them later in a work queue.

Daniel looked over the locking on the list and agrees it should be sufficent.

The atomic allocs use no warn, as the last thing we want if we haven't memory
to allocate space for a printk in an irq context is more printks.
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0665f9f8
  31. 05 Jul, 2013 9 commits
  33. 28 Jun, 2013 2 commits
  35. 27 Jun, 2013 1 commit
  37. 17 Jun, 2013 1 commit
  39. 31 May, 2013 1 commit
  41. 28 May, 2013 1 commit

Powered by Integricloud