linux/drivers/gpu, branch v3.6

Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

2012-09-27T07:58:53Z

Another spurious dmesg quitening. * 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN

drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN

2012-09-26T23:13:43Z

PFIFO_INTR = 0x40000000 appears to be a normal case on nvc0/nve0 PFIFO, the binary driver appears to completely ignore it in its PFIFO interrupt handler and even masks off the bit (as we do) in PFIFO_INTR_EN at init time. The bits still light up in the hardware sometimes though, so lets just ignore any bits we haven't explicitely requested. Signed-off-by: Ben Skeggs

drm/udl: limit modes to the sku pixel limits.

2012-09-26T08:40:21Z

Otherwise when X starts we commonly get a black screen scanning out nothing, its wierd dpms on/off from userspace brings it back, With this on F18, multi-seat works again with my 1920x1200 monitor which is above the sku limit for the device I have. Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie

vmwgfx: corruption in vmw_event_fence_action_create()

2012-09-26T08:40:06Z

We don't allocate enough data for this struct. As soon as we start modifying event->event on the next lines, then we're going beyond the end of the memory we allocated. Signed-off-by: Dan Carpenter cc: stable@vger.kernel.org Signed-off-by: Dave Airlie

drm/nvc0/ltcg: mask off intr 0x10

2012-09-26T02:43:10Z

NVIDIA do that at startup too on Fermi, so perhaps the heap of 0x10 intrs we receive are normal and we can ignore them. On Kepler NVIDIA *don't* do this, but the hardware appears to come up with the bit masked off by default - so that's probably why :) This should silence some interrupt spam seen on Fermi+ boards. Backported patch from reworked nouveau kernel tree. Signed-off-by: Ben Skeggs

drm/nouveau: silence a debug message triggered by newer userspace

2012-09-26T02:41:19Z

Signed-off-by: Ben Skeggs

Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

2012-09-21T10:46:01Z

Daniel writes: Essentially just flush my -fixes queue before I head off to xdc. - gen2 regression fixer, we've enabled the lvds stuff too late. Not causing any known issues, but this restores the sequence before a refactor that landed in 3.5, and lvds is a fickle beast. And seriously, who runs gen2 still ... - downgrade a BUG to a WARN - we haven't root-caused/fixed the underlying issue yet, but this should help bug reporters quite a bit. - properly disable hdmi audio - we've lost track of this, which resulted in the alsa driver again losing track of the unplug event. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: HDMI - Clear Audio Enable bit for Hot Plug drm/i915: Reduce a pin-leak BUG into a WARN drm/i915: enable lvds pin pairs before dpll on gen2

drm/nouveau: add dmi quirk for gpio reset

2012-09-21T14:17:15Z

This fixes the gpio reset problem so the Retina MBP works, but avoids breaking the Dell systems. Ben will work on a better solution for 3.7. Tested by me on retina MBP. Signed-off-by: Dave Airlie

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

2012-09-20T20:50:40Z

fixes a resume regression on pre-r6xx asics. * 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: Prevent leak of scratch register on resume from suspend

drm/radeon: Prevent leak of scratch register on resume from suspend

2012-09-20T16:59:16Z

Cards typically have 5-7 scratch registers; one of these is reserved for rdev->rptr_save_reg. Unfortunately the reservation is done in function r100_cp_init, which is called by all drivers except r600 - and this function is also invoked on resume from suspend. After several resumes, no scratch registers are free and graphics acceleration is disabled. Dmesg then reports either: *ERROR* radeon: cp failed to get scratch reg (-22). *ERROR* radeon: cp isn't working(-22). radeon 0000:01:00.0: failed initializing CP (-22). or: *ERROR* radeon: failed to get scratch reg (-22). *ERROR* radeon: failed testing IB on GFX ring (-22). *ERROR* ib ring test failed (-22). The chain of calls on boot for all except r600 is: radeon_init -> ... -> (rXXX_init) -> rXXX_startup -> r100_cp_init The chain of calls on resume for all except r600 is: rXXX_resume -> rXXX_startup -> r100_cp_init. R600 correctly allocates rptr_save_reg in r600_init (ie once only, not in resume). However moving the code into the init functions for all drivers means touching 4 drivers. So instead, this patch just adds a test in r100_cp_init to avoid reallocating on resume. As the rdev structure is allocated via kzalloc in radeon_driver_load_kms, and zero is not a valid registerid, zero safely implies not-yet-allocated. This issue appears to have been introduced in c7eff978 (3.6.0-rcN) Signed-off-by: Simon Kitching Signed-off-by: Alex Deucher