linux/drivers/gpu/drm, branch v3.10.2

drm/qxl: add missing access check for execbuffer ioctl

2013-06-28T03:27:40Z

Reported-by: Mathieu Desnoyers Signed-off-by: Dave Airlie

drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.

2013-06-25T00:39:57Z

Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 ("drm/i915: create compact dma scatter lists for gem objects") makes certain assumptions about the under laying DMA API that are not always correct. On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup I see: [drm:intel_pipe_set_base] *ERROR* pin & fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Bit of debugging traced it down to dma_map_sg failing (in i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB). That unfortunately are sizes that the SWIOTLB is incapable of handling - the maximum it can handle is a an entry of 512KB of virtual contiguous memory for its bounce buffer. (See IO_TLB_SEGSIZE). Previous to the above mention git commit the SG entries were of 4KB, and the code introduced by above git commit squashed the CPU contiguous PFNs in one big virtual address provided to DMA API. This patch is a simple semi-revert - were we emulate the old behavior if we detect that SWIOTLB is online. If it is not online then we continue on with the new compact scatter gather mechanism. An alternative solution would be for the the '.get_pages' and the i915_gem_gtt_prepare_object to retry with smaller max gap of the amount of PFNs that can be combined together - but with this issue discovered during rc7 that might be too risky. Reported-and-Tested-by: Konrad Rzeszutek Wilk CC: Chris Wilson CC: Imre Deak CC: Daniel Vetter CC: David Airlie CC: Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Dave Airlie

Merge tag 'drm-intel-fixes-2013-06-24' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

2013-06-25T00:38:44Z

One remaining regression fix for i915. I've left it in -fixes for more than a week since it's in tricky code, and it took us a few kernel releases to notice the regression at all. The fence leak is especially annoying on gen2/3 and will kill userspace there quickly. For extra paranoia we've added a WARN in -next to catch this, things seem to be solid now. * tag 'drm-intel-fixes-2013-06-24' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Restore fences after resume and GPU resets

Merge branch 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2013-06-20T22:52:19Z

One user visible fix to stop misreport GPU hangs and subsequent resets. * 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: update lockup tracking when scheduling in empty ring

drm/radeon: update lockup tracking when scheduling in empty ring

2013-06-20T18:45:08Z

There might be issue with lockup detection when scheduling on an empty ring that have been sitting idle for a while. Thus update the lockup tracking data when scheduling new work in an empty ring. Signed-off-by: Jerome Glisse Tested-by: Andy Lutomirski Cc: stable@vger.kernel.org Reviewed-by: Christian König Signed-off-by: Alex Deucher

Merge branch 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2013-06-19T01:48:36Z

Alex writes: Remove some harmless but confusing VM related error messages fix a regression with suspend and UVD, fix UVD on big endian. * 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: fix UVD on big endian drm/radeon: fix write back suspend regression with uvd v2 drm/radeon: do not try to uselessly update virtual memory pagetable

drm/prime: Honor requested file flags when exporting a buffer

2013-06-19T01:34:54Z

The DRM PRIME API passes file flags to the driver for the exported buffer. Honor them instead of hardcoding 0600. Signed-off-by: Laurent Pinchart Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie

drm/i915: Restore fences after resume and GPU resets

2013-06-15T23:10:45Z

Stéphane Marchesin found that fences for pinned objects (i.e. the scanout) were not being restored upon resume, leading to corruption on the display and reference counting issues. This is due to a bug in commit 312817a39f17dbb4de000165b5b724e3728cd91c [2.6.38] Author: Chris Wilson Date: Mon Nov 22 11:50:11 2010 +0000 drm/i915: Only save and restore fences for UMS that zapped the pinned fences even though they were in use. Fortuitously, whilst we forced a VT switch during suspend and resume, no fences were ever pinned at the time. However, we now can do switchless S3 transitions and so the old bug finally surfaces. Reported-by: Stéphane Marchesin Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Stéphane Marchesin Signed-off-by: Daniel Vetter

drm/radeon: fix UVD on big endian

2013-06-14T21:05:57Z

This fixes the kernel side so that the ring should come up and ring and IB tests should work. The userspace UVD drivers will also need big endian fixes. Signed-off-by: Alex Deucher

drm/radeon: fix write back suspend regression with uvd v2

2013-06-12T12:16:29Z

UVD ring can't use scratch thus it does need writeback buffer to keep a valid address or radeon_ring_backup will trigger a kernel fault. It's ok to not unpin the write back buffer on suspend as it leave in gtt and thus does not need eviction. v2: Fix the uvd case. Reported and tracked by Wojtek Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher