kernel.git/drivers/gpu/drm/vmwgfx, branch linux-4.0.y

drm/vmwgfx: Fix an issue with the device losing its irq line on module unload

2015-03-11T18:47:41Z

Starting with commit b4b55cda5874 ("x86/PCI: Refine the way to release PCI IRQ resources") the device lost its irq resource on module unload. While that's ok and apparently intentional, the driver never got the resource back on module load The code apparently wants drivers to disable the pci device at pci device driver removal, so lets do that. That fixes the issue. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul

drm/vmwgfx: Correctly NULLify dma buffer pointer on failure

2015-03-11T18:47:41Z

cppcheck on lines 917 and 977 show an ineffective assignment to the dma buffer pointer: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? On a successful DMA buffer lookup, the dma buffer pointer is assigned, however, on failure it currently is left in an undefined state. The original intention in the error exit path was to nullify the pointer on an error (which the original code failed to do properly). This patch fixes this also ensures all failure paths nullify the buffer pointer on the error return. Fortunately the callers to vmw_translate_mob_ptr and vmw_translate_guest_ptr are checking on a return status and not on the dma buffer pointer, so the original code worked. Reviewed-by: Thomas Hellstrom Signed-off-by: Colin Ian King

drm/vmwgfx: Reorder device takedown somewhat

2015-03-11T18:47:40Z

To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh

drm/vmwgfx: Fix a couple of lock dependency violations

2015-03-11T18:47:40Z

Experimental lockdep annotation added to the TTM lock has unveiled a couple of lock dependency violations in the vmwgfx driver. In both cases it turns out that the device_private::reservation_sem is not needed so the offending code is moved out of that lock. Cc: Acked-by: Sinclair Yeh Signed-off-by: Thomas Hellstrom

drm/vmwgfx: Replace the hw mutex with a hw spinlock

2015-01-19T11:02:13Z

Fixes a case where we call vmw_fifo_idle() from within a wait function with task state !TASK_RUNNING, which is illegal. In addition, make the locking fine-grained, so that it is performed once for every read- and write operation. This is of course more costly, but we don't perform much register access in the timing critical paths anyway. Instead we have the extra benefit of being sure that we don't forget the hw lock around register accesses. I think currently the kms code was quite buggy w r t this. This fixes Red Hat Bugzilla Bug 1180796 Cc: stable@vger.kernel.org Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz

drm/ttm: optionally move duplicates to a separate list

2014-12-03T23:26:52Z

This patch adds an optional list_head parameter to ttm_eu_reserve_buffers. If specified duplicates in the execbuf list are no longer reported as errors, but moved to this list instead. Reviewed-by: Thomas Hellstrom Signed-off-by: Christian König Signed-off-by: Alex Deucher

drm/vmwgfx: (Re)bind shaders to MOBs with the correct offset

2014-12-03T08:48:14Z

This codepath is mostly hit when rebinding after a backup buffer swapout. It's amazing that this error hasn't been more obvious but probably the shaders are not reread from guest memory that often.. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Reviewed-by: Sinclair Yeh

drm/vmwgfx: Fix fence event code

2014-12-03T08:48:14Z

The commit "vmwgfx: Rework fence event action" introduced a number of bugs that are fixed with this commit: a) A forgotten return stateemnt. b) An if statement with identical branches. Cc: Reported-by: Rob Clark Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Reviewed-by: Sinclair Yeh

drm/vmwgfx: Don't use memory accounting for kernel-side fence objects

2014-12-03T08:48:14Z

Kernel side fence objects are used when unbinding resources and may thus be created as part of a memory reclaim operation. This might trigger recursive memory reclaims and result in the kernel running out of stack space. So a simple way out is to avoid accounting of these fence objects. In principle this is OK since while user-space can trigger the creation of such objects, it can't really hold on to them. However, their lifetime is quite long, so some form of accounting should perhaps be implemented in the future. Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 with low system memory settings. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Reviewed-by: Sinclair Yeh

drm/vmwgfx: Fix error printout on signals pending

2014-12-03T08:48:14Z

The function vmw_master_check() might return -ERESTARTSYS if there is a signal pending, indicating that the IOCTL should be rerun, potentially from user-space. At that point we shouldn't print out an error message since that is not an error condition. In short, avoid bloating the kernel log when a process refuses to die on SIGTERM. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz