linux-stable.git/drivers/gpu, branch v3.4.29

radeon_display: Use pointer return error codes

2013-02-04T00:24:40+00:00

commit b2f4b03f8a378cd626d2ea67d19e7470c050a098 upstream.

drm_mode_addfb() expects fb_create return error code
instead of NULL.

Signed-off-by: xueminsu 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix cursor corruption on DCE6 and newer

2013-02-04T00:24:40+00:00

commit e521a29014794d139cca46396d1af8faf1295a26 upstream.

Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.

agd5f: check DCE6 rather than ARUBA since the issue is DCE
version specific rather than family specific.

Signed-off-by: Jerome Glisse 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled

2013-01-28T04:47:44+00:00

commit 4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream.

Quoting from Bspec, 3D_CHICKEN1, bit 10

This bit needs to be set always to "1", Project: DevSNB "

Reviewed-by: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 
Signed-off-by: Abdallah Chatila 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Invalidate the relocation presumed_offsets along the slow path

2013-01-28T04:47:42+00:00

commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream.

In the slow path, we are forced to copy the relocations prior to
acquiring the struct mutex in order to handle pagefaults. We forgo
copying the new offsets back into the relocation entries in order to
prevent a recursive locking bug should we trigger a pagefault whilst
holding the mutex for the reservations of the execbuffer. Therefore, we
need to reset the presumed_offsets just in case the objects are rebound
back into their old locations after relocating for this exexbuffer - if
that were to happen we would assume the relocations were valid and leave
the actual pointers to the kernels dangling, instant hang.

Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
Author: Chris Wilson 
Date:   Sun Nov 21 22:07:12 2010 +0000

    drm/i915: Handle pagefaults in execbuffer user relocations

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter

Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"

2013-01-17T16:51:17+00:00

commit 48e858340dae43189a4e55647f6eac736766f828 upstream.

This reverts commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364.

The bogus lvds output is actually a lvds->hdmi bridge, which we don't
really support. But unconditionally disabling it breaks some existing
setups.

Reported-by: John Tapsell 
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237
Signed-off-by: Daniel Vetter 
Cc: Luis Henriques 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Flush the pending flips on the CRTC before modification

2013-01-17T16:51:17+00:00

commit 5bb61643f6a70d48de9cfe91ad0fee0d618b6816 upstream.

This was meant to be the purpose of the
intel_crtc_wait_for_pending_flips() function which is called whilst
preparing the CRTC for a modeset or before disabling. However, as Ville
Syrjala pointed out, we set the pending flip notification on the old
framebuffer that is no longer attached to the CRTC by the time we come
to flush the pending operations. Instead, we can simply wait on the
pending unpin work to be finished on this CRTC, knowning that the
hardware has therefore finished modifying the registers, before proceeding
with our direct access.

Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply
schedule the flip immediately when the pipe is disabled, leading
to other funny issues.

Signed-off-by: Chris Wilson 
[danvet: Added i-g-t note and cc: stable]
Signed-off-by: Daniel Vetter 
Signed-off-by: Julien Cristau 
Signed-off-by: Greg Kroah-Hartman

drm/i915: call drm_handle_vblank before finish_page_flip

2013-01-17T16:51:17+00:00

commit 74d44445afb9f50126eba052adeb89827cee88f3 upstream.

... since finish_page_flip needs the vblank timestamp generated
in drm_handle_vblank. Somehow all the gmch platforms get it right,
but all the pch platform irq handlers get is wrong. Hooray for copy&
pasting!

Currently this gets papered over by a gross hack in finish_page_flip.
A second patch will remove that.

Note that without this, the new timestamp sanity checks in flip_test
occasionally get tripped up, hence the cc: stable tag.

Reviewed-by: mario.kleiner@tuebingen.mpg.de
Tested-by: Imre Deak 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: no loop over pipes in ivybridge_irq_handler(),
 so make a similar change to that in ironlake_irq_handler()]
Signed-off-by: Ben Hutchings 
Signed-off-by: Julien Cristau 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix GT_MODE default value

2013-01-17T16:51:14+00:00

commit f8f2ac9a76b0f80a6763ca316116a7bab8486997 upstream.

I can't even find how I figured this might be needed anymore. But sure
enough, the value I'm reading back on platforms doesn't match what the
docs recommends.

It seemed to fix Chris' GT1 in limited testing as well.

Tested-by: Chris Wilson 
Signed-off-by: Ben Widawsky 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: open-code _MASKED_BIT_{ENABLE,DISABLE}]
Signed-off-by: Ben Hutchings 
Signed-off-by: Julien Cristau 
Signed-off-by: Greg Kroah-Hartman

drm/i915: prevent possible pin leak on error path

2013-01-17T16:51:08+00:00

commit ab3951eb74e7c33a2f5b7b64d72e82f1eea61571 upstream.

We should not hit this under any sane conditions, but still, this does not
looks right.

Reported-by: Herton Ronaldo Krzesinski 
CC: Chris Wilson 
CC: Daniel Vetter 
Reviewed-by: Chris Wlison 
Signed-off-by: Eugeni Dodonov 
Signed-off-by: Daniel Vetter 
Signed-off-by: Julien Cristau 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Reduce a pin-leak BUG into a WARN

2013-01-17T16:51:08+00:00

commit 7e81a42e341a4f15d76624b7c02ffb21b085b56f upstream.

Pin-leaks persist and we get the perennial bug reports of machine
lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that
the object cannot be pinned at that time it should prevent the driver from
locking up, and hopefully restore a semblance of working whilst still
leaving us a OOPS to debug.

Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Julien Cristau 
Signed-off-by: Greg Kroah-Hartman