linux-toradex.git/drivers/gpu/drm/i915, branch v3.2.16

drm/i915: make rc6 module parameter read-only

2012-04-22T22:30:57+00:00

commit f57f9c167af7cb3fd315e6a8ebe194a8aea0832a upstream.

People have been getting confused and thinking this is a runtime control.

Signed-off-by: Jesse Barnes 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: properly compute dp dithering for user-created modes

2012-04-22T22:30:57+00:00

commit c4867936474183332db4c19791a65fdad6474fd5 upstream.

We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.

Chris Wilson pointed out that we still get things wrong for bpp > 24,
but that should be fixed in another patch (and it'll be easier because
this patch consolidates the logic).

The likely culprit for this regression is

commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2
Author: Keith Packard 
Date:   Wed Jan 25 08:16:25 2012 -0800

    drm/i915: Force explicit bpp selection for intel_dp_link_required

v2: Fix indentation and tune down the too bold claim that this should
fix the world. Both noticed by Chris Wilson.

v3: Try to really git add things.

Reported-and-tested-by: Brice Goglin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170
Cc: stable@kernel.org
Reviewed-by: Adam Jackson 
Signed-Off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g

2012-04-22T22:30:57+00:00

commit 27c1cbd06a7620b354cbb363834f3bb8df4f410d upstream.

The 845g shares the errata with i830 whereby executing a command
within 2 cachelines of the end of the ringbuffer may cause a GPU hang.

Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: mask transcoder select bits before setting them on LVDS

2012-04-22T22:30:56+00:00

commit 7885d2052bd94395e337709cfba093a41f273ff1 upstream.

The transcoder port may changed from mode set to mode set, so make sure
to mask out the selection bits before setting the right ones or we'll
get black screens when going from transcoder B to A.

Tested-by: Vincent Vanackere 
Signed-off-by: Jesse Barnes 
Reviewed-by: Keith Packard 
Signed-off-by: Keith Packard 
Cc: Jonathan Nieder 
Signed-off-by: Greg Kroah-Hartman

drm/i915: quirk away broken OpRegion VBT

2012-04-13T15:33:47+00:00

commit 25e341cfc33d94435472983825163e97fe370a6c upstream.

Somehow the BIOS manages to screw things up when copying the VBT
around, because the one we scrap from the VBIOS rom actually works.

Tested-by: Markus Heinz 
Acked-by: Chris Wilson 
Reviewed-by: Rodrigo Vivi 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
Signed-Off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Add lock on drm_helper_resume_force_mode

2012-04-13T15:33:47+00:00

commit 927a2f119e8235238a2fc64871051b16c9bdae75 upstream.

i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.

Signed-off-by: Sean Paul 
Reviewed-by: Chris Wilson 
Signed-Off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Sanitize BIOS debugging bits from PIPECONF

2012-04-13T15:33:47+00:00

commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 upstream.

Quoting the BSpec from time immemorial:

  PIPEACONF, bits 28:27: Frame Start Delay (Debug)

  Used to delay the frame start signal that is sent to the display planes.
  Care must be taken to insure that there are enough lines during VBLANK
  to support this setting.

An instance of the BIOS leaving these bits set was found in the wild,
where it caused our modesetting to go all squiffy and skewiff.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
Reported-and-tested-by: Eva Wang 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
Reported-and-tested-by: Carl Richell 
Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: no-lvds quirk on MSI DC500

2012-04-13T15:33:47+00:00

commit 97effadb65ed08809e1720c8d3ee80b73a93665c upstream.

This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.

Signed-off-by: Anisse Astier 
Acked-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: suspend fbdev device around suspend/hibernate

2012-04-02T16:53:07+00:00

commit 3fa016a0b5c5237e9c387fc3249592b2cb5391c6 upstream.

Looking at hibernate overwriting I though it looked like a cursor,
so I tracked down this missing piece to stop the cursor blink
timer. I've no idea if this is sufficient to fix the hibernate
problems people are seeing, but please test it.

Both radeon and nouveau have done this for a long time.

I've run this personally all night hib/resume cycles with no fails.

Reviewed-by: Keith Packard 
Reported-by: Petr Tesarik 
Reported-by: Stanislaw Gruszka 
Reported-by: Lots of misc segfaults after hibernate across the world.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=37142
Tested-by: Dave Airlie 
Tested-by: Bojan Smojver 
Tested-by: Andreas Hartmann 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Only clear the GPU domains upon a successful finish

2012-04-02T16:52:46+00:00

commit c501ae7f332cdaf42e31af30b72b4b66cbbb1604 upstream.

By clearing the GPU read domains before waiting upon the buffer, we run
the risk of the wait being interrupted and the domains prematurely
cleared. The next time we attempt to wait upon the buffer (after
userspace handles the signal), we believe that the buffer is idle and so
skip the wait.

There are a number of bugs across all generations which show signs of an
overly haste reuse of active buffers.

Such as:

  https://bugs.freedesktop.org/show_bug.cgi?id=29046
  https://bugs.freedesktop.org/show_bug.cgi?id=35863
  https://bugs.freedesktop.org/show_bug.cgi?id=38952
  https://bugs.freedesktop.org/show_bug.cgi?id=40282
  https://bugs.freedesktop.org/show_bug.cgi?id=41098
  https://bugs.freedesktop.org/show_bug.cgi?id=41102
  https://bugs.freedesktop.org/show_bug.cgi?id=41284
  https://bugs.freedesktop.org/show_bug.cgi?id=42141

A couple of those pre-date i915_gem_object_finish_gpu(), so may be
unrelated (such as a wild write from a userspace command buffer), but
this does look like a convincing cause for most of those bugs.

Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Reviewed-by: Eugeni Dodonov 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman