litmus-rt-odroidx.git/drivers/gpu/drm/i915, branch odroidx

drm/i915: correctly order the ring init sequence

2012-08-26T22:12:11+00:00

commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.

We may only start to set up the new register values after having
confirmed that the ring is truely off. Otherwise the hw might lose the
newly written register values. This is caught later on in the init
sequence, when we check whether the register writes have stuck.

Reviewed-by: Jani Nikula 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Tested-by: Yang Guang 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix eDP blank screen after S3 resume on HP desktops

2012-07-16T15:47:39+00:00

commit 6db65cbb941f9d433659bdad02b307f6d94465df upstream.

This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.

It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2.  Otherwise it doesn't take effect on these
SNB machines.

Tested with 3.5-rc3 kernel.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233

Signed-off-by: Takashi Iwai 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: wait for a vblank to pass after tv detect

2012-06-09T15:32:59+00:00

commit bf2125e2f7e931b50a6c76ba0435ba001409ccbf upstream.

Otherwise the hw will get confused and result in a black screen.

This regression has been most likely introduce in

commit 974b93315b2213b74a42a87e8a9d4fc8c0dbe90c
Author: Chris Wilson 
Date:   Sun Sep 5 00:44:20 2010 +0100

    drm/i915/tv: Poll for DAC state change

That commit replace the first msleep(20) with a busy-loop, but failed
to keep the 2nd msleep around. Later on we've replaced all these
msleep(20) by proper vblanks.

For reference also see the commit in xf86-video-intel:

commit 1142be53eb8d2ee8a9b60ace5d49f0ba27332275
Author: Jesse Barnes 
Date:   Mon Jun 9 08:52:59 2008 -0700

    Fix TV programming:  add vblank wait after TV_CTL writes

    Fxies FDO bug #14000; we need to wait for vblank after
    writing TV_CTL or following "DPMS on" calls may not actually enable the output.

v2: As suggested by Chris Wilson, add a small comment to ensure that
no one accidentally removes this vblank wait again - there really
seems to be no sane explanation for why we need it, but it is
required.

Launchpad: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688
Reported-and-Tested-by: Robert Lowery 
Cc: Rodrigo Vivi 
Acked-by: Chris Wilson 
Signed-Off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: properly handle interlaced bit for sdvo dtd conversion

2012-06-09T15:32:59+00:00

commit 59d92bfa5f0cdf57f82f5181b0ad6af75c3fdf41 upstream.

We've simply ignored this, which isn't too great. With this, interlaced
1080i works on my HDMI screen connected through sdvo. For no apparent
reason anything else still doesn't work as it should.

While at it, give these magic numbers in the dtd proper names and
add a comment that they match with EDID detailed timings.

v2: Actually use the right bit for interlaced.

Tested-by: Peter Ross 
Reviewed-by: Paulo Zanoni 
Signed-Off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: don't clobber the pipe param in sanitize_modesetting

2012-06-01T07:12:59+00:00

commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream.

... we need it later on in the function to clean up pipe <-> plane
associations. This regression has been introduced in

commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
Author: Chris Wilson 
Date:   Thu Mar 22 15:00:50 2012 +0000

    drm/i915: Sanitize BIOS debugging bits from PIPECONF

Spotted by staring at debug output of an (as it turns out) totally
unrelated bug.

v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
Chris Wilson.

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

drm/i915: [GEN7] Use HW scheduler for fixed function shaders

2012-06-01T07:12:59+00:00

commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream.

This originally started as a patch from Bernard as a way of simply
setting the VS scheduler. After submitting the RFC patch, we decided to
also modify the DS scheduler. To be most explicit, I've made the patch
explicitly set all scheduler modes, and included the defines for other
modes (in case someone feels frisky later).

The rest of the story gets a bit weird. The first version of the patch
showed an almost unbelievable performance improvement. Since rebasing my
branch it appears the performance improvement has gone, unfortunately.
But setting these bits seem to be the right thing to do given that the
docs describe corruption that can occur with the default settings.

In summary, I am seeing no more perf improvements (or regressions) in my
limited testing, but we believe this should be set to prevent rendering
corruption, therefore cc stable.

v1: Clear bit 4 also (Ken + Eugeni)
Do a full clear + set of the bits we want (Me).

Cc: Bernard Kilarski 
Reviewed-by (RFC): Kenneth Graunke 
Signed-off-by: Ben Widawsky 
Reviewed-by: Eugeni Dodonov 
Reviewed-by: Kenneth Graunke 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Avoid a double-read of PCH_IIR during interrupt handling

2012-06-01T07:12:59+00:00

commit 9adab8b5a7fde248504f484e197589f3e3c922e2 upstream.

Currently the code re-reads PCH_IIR during the hotplug interrupt
processing. Not only is this a wasted read, but introduces a potential
for handling a spurious interrupt as we then may not clear all the
interrupts processed (since the re-read IIR may contains more interrupts
asserted than we clear using the result of the original read).

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

drm/i915: fix integer overflow in i915_gem_do_execbuffer()

2012-05-07T15:56:34+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:56:33+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: handle input/output sdvo timings separately in mode_set

2012-05-07T15:56:33+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