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

drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().

2012-10-30T23:26:46+00:00

commit 082918471139b07964967cfe5f70230909c82ae1 upstream.

radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
to destroy each of them.
radeon_ext_tmds_enc_destroy() however also has code to destroy it's
associated I2C bus rec which has been obtained by radeon_i2c_lookup()
and is therefore also in the i2c_bus[] list.
This causes a double free resulting in a kernel panic when unloading
the radeon driver.
Removing destroy code from radeon_ext_tmds_enc_destroy() fixes this
problem.

agd5f: fix compiler warning

Signed-off-by: Egbert Eich 
Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

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

2012-10-30T23:26:30+00:00

commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364 upstream.

This box claims to have an LVDS interface but doesn't
actually have one.

Signed-off-by: Sjoerd Simons 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915: don't pwrite tiled objects through the gtt

2012-10-30T23:26:30+00:00

commit c07496fa61f4c5cb2addd1c57f6b22fcaeea2eeb upstream.

... we will botch up the bit17 swizzling. Furthermore tiled pwrite is
a (now) unused slowpath, so no one really cares.

This fixes the last swizzling issues I have with i-g-t on my bit17
swizzling i915G. No regression, it's been broken since the dawn of
gem, but it's nice for regression tracking when really _all_ i-g-t
tests work.

Actually this is not true, Chris Wilson noticed while reviewing this
patch that the commit

commit d9e86c0ee60f323e890484628f351bf50fa9a15d
Author: Chris Wilson 
Date:   Wed Nov 10 16:40:20 2010 +0000

    drm/i915: Pipelined fencing [infrastructure]

contained a functional change that broke things.

Reviewed-by: Chris Wilson 
Signed-Off-by: Daniel Vetter 
[Luís Picciochi Oliveira: I picked the commit Daniel suggested and
edited it to affect the code that matched the same logical location on
the same function.]
Signed-off-by: Ben Hutchings

drm/i915: clear fencing tracking state when retiring requests

2012-10-17T02:50:13+00:00

commit 15a13bbdffb0d6288a5dd04aee9736267da1335f upstream.

This fixes a resume regression introduced in

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson 
Date:   Wed Mar 21 10:48:18 2012 +0000

    drm/i915: Mark untiled BLT commands as fenced on gen2/3

which fixed fencing tracking for untiled blt commands.

A side effect of that patch was that now also untiled objects have a
non-zero obj->last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.

Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv->next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj->last_fenced_seqno from before the suspend.

The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.

Reported-and-tested-by: "Rafael J. Wysocki" 
Cc: Jiri Slaby 
Reviewed-by: Chris Wilson 
Signed-Off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915: Mark untiled BLT commands as fenced on gen2/3

2012-10-17T02:50:12+00:00

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba upstream.

The BLT commands on gen2/3 utilize the fence registers and so we cannot
modify any fences for the object whilst those commands are in flight.
Currently we marked tiled commands as occupying a fence, but forgot to
restrict the untiled commands from preventing a fence being assigned
before they were completed.

One side-effect is that we ten have to double check that a fence was
allocated for a fenced buffer during move-to-active.

Reported-by: Jiri Slaby 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43427
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47990
Reviewed-by: Daniel Vetter 
Testcase: i-g-t/tests/gem_tiled_after_untiled_blt
Tested-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: The nesting of if-statements in the old
 i915_gem_execbuffer_reserve() differs from pin_and_fence_object(),
 so don't move the assignment of obj->pending_fenced_gpu_access but
 adjust the boolean expression as recommended by Daniel Vetter.]
Signed-off-by: Ben Hutchings

drm/i915: fix swizzle detection for gen3

2012-10-17T02:50:11+00:00

commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa upstream.

It looks like the desktop variants of i915 and i945 also have the DCC
register to control dram channel interleave and cpu side bit6
swizzling.

Unfortunately internal Cspec/ConfigDB documentation for these ancient chips
have already been dropped and there seem to be no archives. Also
somebody thought the swizzling behaviour is surely a worthy secret to
keep and redacted any mention of these fields from the published Intel
datasheets.

I suspect the hw engineers were really proud of the page coloring
they've achieved in their first dual channel dram controller with
bit17 - after all Bspec explains in great length the optimal layout of
page frame numbers modulo 4 for the color and depth buffers, too.
Later on when they've started to work on VT-d they shamefully
discoverd their stupidity and tried to cover the tracks ...

Tested-by: Daniel Vetter  (i915g)
Tested-by: Pavel Ondračka  (i945g)
Tested-by: Chris Wilson 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42625
Signed-Off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)

2012-10-17T02:49:55+00:00

commit 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 upstream.

- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access

This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.

v2: fix crtc enabled check noticed by Luca Tettamanti

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2:
 - Drop DCE6 cases
 - Call evergreen_mc_wait_for_idle() directly
 - Add dce4_wait_for_vblank() (commits 3ae19b750bdc09ce233e1504348320141593ffda
   and 4a15903db02026728d0cf2755c6fabae16b8db6a) and call it directly
Signed-off-by: Ben Hutchings

drm/i915: Fix GT_MODE default value

2012-10-17T02:49:32+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

drm/i915: call drm_handle_vblank before finish_page_flip

2012-10-17T02:49:31+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

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

2012-10-17T02:49:22+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: Ben Hutchings