linux-toradex.git/drivers/gpu/drm/vmwgfx, branch v4.1.26

drm/vmwgfx: respect 'nomodeset'

2016-02-15T20:45:26+00:00

[ Upstream commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 ]

Signed-off-by: Rob Clark 
Reviewed-by: Thomas Hellstrom .
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/vmwgfx: Fix up user_dmabuf refcounting

2015-11-09T22:33:39+00:00

commit 54c12bc374408faddbff75dbf1a6167c19af39c4 upstream.

If user space calls unreference on a user_dmabuf it will typically
kill the struct ttm_base_object member which is responsible for the
user-space visibility. However the dmabuf part may still be alive and
refcounted. In some situations, like for shared guest-backed surface
referencing/opening, the driver may try to reference the
struct ttm_base_object member again, causing an immediate kernel warning
and a later kernel NULL pointer dereference.

Fix this by always maintaining a reference on the struct
ttm_base_object member, in situations where it might subsequently be
referenced.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix execbuf locking issues

2015-09-13T16:07:42+00:00

commit 3e04e2fe6d87807d27521ad6ebb9e7919d628f25 upstream.

This addresses two issues that cause problems with viewperf maya-03 in
situation with memory pressure.

The first issue causes attempts to unreserve buffers if batched
reservation fails due to, for example, a signal pending. While previously
the ttm_eu api was resistant against this type of error, it is no longer
and the lockdep code will complain about attempting to unreserve buffers
that are not reserved. The issue is resolved by avoid calling
ttm_eu_backoff_reservation in the buffer reserve error path.

The second issue is that the binding_mutex may be held when user-space
fence objects are created and hence during memory reclaims. This may cause
recursive attempts to grab the binding mutex. The issue is resolved by not
holding the binding mutex across fence creation and submission.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'topic/drm-misc-2015-03-31' of git://anongit.freedesktop.org/drm-intel into drm-next

2015-03-31T22:23:25+00:00

Final drm-misc pull for 4.0, just various things all over, including a few
more important atomic fixes. btw I didn't pick up the vmwgfx patch from
Ville's series, but one patch has one hunk touching vmwgfx and
Thomas/Jakob didn't get around to ack it. I figured it's simple enough to
be ok though.

* tag 'topic/drm-misc-2015-03-31' of git://anongit.freedesktop.org/drm-intel:
  drm: line wrap DRM_IOCTL_DEF* macros
  drm/atomic: Don't try to free a NULL state
  drm/atomic: Clear crtcs, connectors and planes when clearing state
  drm: Rewrite drm_ioctl_flags() to resemble the new drm_ioctl() code
  drm: Use max() to make the ioctl alloc size code cleaner
  drm: Simplify core vs. drv ioctl handling
  drm: Drop ioctl->cmd_drv
  drm: Fix DRM_IOCTL_DEF_DRV()
  drm/atomic-helpers: Properly avoid full modeset dance
  drm: atomic: Allow setting CRTC active property
  drm: atomic: Expose CRTC active property
  drm: crtc_helper: Update hwmode before mode_set call
  drm: mode: Allow NULL modes for equality check
  drm: fb_helper: Simplify exit condition
  drm: mode: Fix typo in kerneldoc
  drm/dp: Print the number of bytes processed for aux nacks

drm: Drop ioctl->cmd_drv

2015-03-27T15:08:34+00:00

ioctl->cmd_drv is pointless and we can just as well stick the full ioctl
definition into ioctl->cmd.

Cc: Jakob Bornecrantz 
Cc: Thomas Hellstrom 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter

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

2015-03-11T18:47:41+00:00

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:41+00:00

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:40+00:00

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:40+00:00

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:13+00:00

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