kernel/linux.git/drivers/gpu/drm/vmwgfx, branch v3.10.42

drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2

2014-05-31T04:52:14+00:00

commit cbd75e97a525e3819c02dc18bc2d67aa544c9e45 upstream. We already check that the buffer object we're accessing is registered with the file. Now also make sure that we can't DMA across buffer object boundaries. v2: Code commenting update. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: correct fb_fix_screeninfo.line_length

2014-05-31T04:52:14+00:00

commit aa6de142c901cd2d90ef08db30ae87da214bedcc upstream. Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but it would not adjust the FINFO properly, resulting in distorted screen rendering. The patch corrects that behaviour. See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples. Signed-off-by: Christopher Friedt Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Don't kill clients on VT switch

2013-11-13T03:05:34+00:00

commit c4249855ac5b2a383704d31e040d3831d6a25c6f upstream. DRI clients that tried to grab the TTM lock when the master (X server) was switched away during a VT switch were sent the SIGTERM signal by the kernel. Fix this so that they are only sent that signal when the master has exited. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Don't put resources with invalid id's on lru list

2013-11-13T03:05:34+00:00

commit 26682480c202e7360cbcdc3bc9e962bf749c6b8d upstream. The evict code may try to swap them out causing a BUG in the destroy function. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Split GMR2_REMAP commands if they are to large

2013-09-08T05:09:58+00:00

commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f upstream. This fixes the piglit test texturing/max-texture-size causing the VM to die due to a too large SVGA command. Signed-off-by: Jakob Bornecrantz Reviewed-by: Biran Paul Reviewed-by: Zack Rusin Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: convert to idr_alloc()

2013-02-28T03:10:16+00:00

Convert to the much saner new idr interface. Signed-off-by: Tejun Heo Acked-by: David Airlie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux into drm-next

2013-02-08T04:02:32+00:00

TTM reservations changes, preparing for new reservation mutex system. * 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux: drm/ttm: unexport ttm_bo_wait_unreserved drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2 drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2 drm/ttm: add ttm_bo_reserve_slowpath drm/ttm: cleanup ttm_eu_reserve_buffers handling drm/ttm: remove lru_lock around ttm_bo_reserve drm/nouveau: increase reservation sequence every retry drm/vmwgfx: always use ttm_bo_is_reserved

drm/vmwgfx: add proper framebuffer refcounting

2013-01-20T21:17:11+00:00

Afact vmwgfx already has all the right refcounting implemented on the backing storage, and we only need to ensure that the drm fb doesn't disappear untimely. So holding onto the fb reference from _lookup until vmw_kms_present has completed should be enough. Signed-off-by: Daniel Vetter

drm: create drm_framebuffer_lookup

2013-01-20T21:16:59+00:00

And replace all fb lookups with it. Also add a WARN to drm_mode_object_find since that is now no longer the blessed interface to look up an fb. And add kerneldoc to both functions. This only updates all callsites, but immediately drops the acquired refence again. Hence all callers still rely on the fact that a mode fb can't disappear while they're holding the struct mutex. Subsequent patches will instate proper use of refcounts, and then rework the rmfb and unref code to no longer serialize fb destruction with the mode_config lock. We don't want that since otherwise a compositor might end up stalling for a few frames in rmfb. v2: Don't use kref_get_unless_zero - Greg KH doesn't like that kind of interface. Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter

drm: revamp locking around fb creation/destruction

2013-01-20T21:16:58+00:00

Well, at least step 1. The goal here is that framebuffer objects can survive outside of the mode_config lock, with just a reference held as protection. The first step to get there is to introduce a special fb_lock which protects fb lookup, creation and destruction, to make them appear atomic. This new fb_lock can nest within the mode_config lock. But the idea is (once the reference counting part is completed) that we only quickly take that fb_lock to lookup a framebuffer and grab a reference, without any other locks involved. vmwgfx is the only driver which does framebuffer lookups itself, also wrap those calls to drm_mode_object_find with the new lock. Also protect the fb_list walking in i915 and omapdrm with the new lock. As a slight complication there's also the list of user-created fbs attached to the file private. The problem now is that at fclose() time we need to walk that list, eventually do a modeset call to remove the fb from active usage (and are required to be able to take the mode_config lock), but in the end we need to grab the new fb_lock to remove the fb from the list. The easiest solution is to add another mutex to protect this per-file list. Currently that new fbs_lock nests within the modeset locks and so appears redudant. But later patches will switch around this sequence so that taking the modeset locks in the fb destruction path is optional in the fastpath. Ultimately the goal is that addfb and rmfb do not require the mode_config lock, since otherwise they have the potential to introduce stalls in the pageflip sequence of a compositor (if the compositor e.g. switches to a fullscreen client or if it enables a plane). But that requires a few more steps and hoops to jump through. Note that framebuffer creation/destruction is now double-protected - once by the fb_lock and in parts by the idr_lock. The later would be unnecessariy if framebuffers would have their own idr allocator. But that's material for another patch (series). v2: Properly initialize the fb->filp_head list in _init, otherwise the newly added WARN to check whether the fb isn't on a fpriv list any more will fail for driver-private objects. v3: Fixup two error-case unlock bugs spotted by Richard Wilbur. Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter