linux-toradex.git/drivers/gpu, branch v3.3.5

nouveau: initialise has_optimus variable.

2012-05-07T15:53:36+00:00

commit addde4ec31456c5f1e9b61aae3edcfeb0f338f87 upstream.

We should initialise this to 0 really to avoid getting false positives.

Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix integer overflow in i915_gem_do_execbuffer()

2012-05-07T15:53:22+00:00

commit 44afb3a04391a74309d16180d1e4f8386fdfa745 upstream.

On 32-bit systems, a large args->num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.

This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
allocation for execbuffer object list").

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

drm/i915: fix integer overflow in i915_gem_execbuffer2()

2012-05-07T15:53:22+00:00

commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b upstream.

On 32-bit systems, a large args->buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.

This vulnerability was introduced in commit 8408c282 ("drm/i915:
First try a normal large kmalloc for the temporary exec buffers").

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

drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.

2012-05-07T15:53:21+00:00

commit 3a69ddd6f872180b6f61fda87152b37202118fbc upstream.

Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in
OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when
using separate stencil buffers.  Without it, the GPU tries to use the
LRA eviction policy, which isn't supported.  This was supposed to be off
by default, but seems to be on for many machines.

This cannot be done in gen6_init_clock_gating with most of the other
workaround bits; the render ring needs to exist.  Otherwise, the
register write gets dropped on the floor (one printk will show it
changed, but a second printk immediately following shows the value
reverts to the old one).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535
Cc: Rob Castle 
Cc: Eric Appleman 
Cc: aaron667@gmx.net
Cc: Keith Packard 
Signed-off-by: Kenneth Graunke 
Reviewed-by: Daniel Vetter 
Acked-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: handle input/output sdvo timings separately in mode_set

2012-05-07T15:53:21+00:00

commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905 upstream.

We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.

Clarify the situation by adding an explicit output_dtd to the sdvo
mode_set function and streamline the code-flow by moving the input and
output mode setting in the sdvo encode together.

Furthermore testing showed that the sdvo input timing needs the
unadjusted dotclock, the sdvo chip will automatically compute the
required pixel multiplier to get a dotclock above 100 MHz.

Fix this up when converting a drm mode to an sdvo dtd.

This regression was introduced in

commit c74696b9c890074c1e1ee3d7496fc71eb3680ced
Author: Pavel Roskin 
Date:   Thu Sep 2 14:46:34 2010 -0400

    i915: revert some checks added by commit 32aad86f

particularly the following hunk:

#	diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
#	b/drivers/gpu/drm/i915/intel_sdvo.c
#	index 093e914..62d22ae 100644
#	--- a/drivers/gpu/drm/i915/intel_sdvo.c
#	+++ b/drivers/gpu/drm/i915/intel_sdvo.c
#	@@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder,
#
#	     /* We have tried to get input timing in mode_fixup, and filled into
#		adjusted_mode */
#	-    if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
#	-        intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
#	+    intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
#	+    if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
#		 input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
#	-    } else
#	-        intel_sdvo_get_dtd_from_mode(&input_dtd, mode);
#
#	     /* If it's a TV, we already set the output timing in mode_fixup.
#	      * Otherwise, the output timing is equal to the input timing.

Due to questions raised in review, below a more elaborate analysis of
the bug at hand:

Sdvo seems to have two timings, one is the output timing which will be
sent over whatever is connected on the other side of the sdvo chip (panel,
hdmi screen, tv), the other is the input timing which will be generated by
the gmch pipe. It looks like sdvo is expected to scale between the two.

To make things slightly more complicated, we have a bunch of special
cases:
- For lvds panel we always use a fixed output timing, namely
  intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
- Sdvo has an interface to generate a preferred input timing for a given
  output timing. This is the confusing thing that I've tried to clear up
  with the follow-on patches.
- A special requirement is that the input pixel clock needs to be between
  100MHz and 200MHz (likely to keep it within the electromechanical design
  range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
  doubled/quadrupled.

The thing this patch tries to fix is that the pipe needs to be
explicitly instructed to double/quadruple the pixels and needs the
correspondingly higher pixel clock, whereas the sdvo adaptor seems to
do that itself and needs the unadjusted pixel clock. For the sdvo
encode side we already set the pixel mutliplier with a different
command (0x21).

This patch tries to fix this mess by:
- Keeping the output mode timing in the unadjusted plain mode, safe
  for the lvds case.
- Storing the input timing in the adjusted_mode with the adjusted
  pixel clock. This way we don't need to frob around with the core
  crtc mode set code.
- Fixing up the pixelclock when constructing the sdvo dtd timing
  struct. This is why the first hunk of the patch is an integral part
  of the series.
- Dropping the is_tv special case because input_dtd is equivalent to
  adjusted_mode after these changes. Follow-up patches clear this up
  further (by simply ripping out intel_sdvo->input_dtd because it's
  not needed).

v2: Extend commit message with an in-depth bug analysis.

Reported-and-Tested-by: Bernard Blackham 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
Reviewed-by: Jesse Barnes 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: need to set up ss on DP bridges as well

2012-05-07T15:53:21+00:00

commit 700698e7c303f5095107c62a81872c2c3dad1702 upstream.

Makes Nutmeg DP to VGA bridges work for me.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=42490

Noticed by Jerome Glisse (after weeks of debugging).

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix load detect on rn50 with hardcoded EDIDs.

2012-04-22T22:39:18+00:00

commit a09d431f344d854e4fe9cfac44f78cb8202f3eb7 upstream.

When the force changes went in back in 3.3.0, we ended up returning
disconnected in the !force case, and the connected in when forced,
as it hit the hardcoded check.

Fix it so all exits go via the hardcoded check and stop spurious
modesets on platforms with hardcoded EDIDs.

Reported-by: Evan McNabb (Red Hat)
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: disable MSI on RV515

2012-04-22T22:39:18+00:00

commit 16a5e32b83fd946312b9b13590c75d20c95c5202 upstream.

My rv515 card is very flaky with msi enabled. Every so often it loses a rearm
and never comes back, manually banging the rearm brings it back.

Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: fix the regression of DVI connector check

2012-04-22T22:39:18+00:00

commit e36325071832f1ba96ac54fb8ba1459f08b05dd8 upstream.

The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms:
fix analog load detection on DVI-I connectors] is obviously wrong, and
it's the culprit of the regression on my workstation with DVI-analog
connection resulting in the blank output.

Fixed the typo now.

Signed-off-by: Takashi Iwai 
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Hold mode_config lock whilst changing mode for lastclose()

2012-04-22T22:39:18+00:00

commit c291be9dba370ba696a0d482249a212cf5c15f45 upstream.

Upon lastclose(), we switch back to the fbcon configuration. This
requires taking the mode_config lock in order to serialise the change
with output probing elsewhere.

Reported-by: Oleksij Rempel 
References: https://bugs.freedesktop.org/show_bug.cgi?id=48652
Signed-off-by: Chris Wilson 
Acked-by: Jesse Barnes 
Signed-Off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman