linux/drivers/gpu/drm, branch v3.0.31

drm/i915: fix integer overflow in i915_gem_do_execbuffer()

2012-05-07T15:56:34Z

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:33Z

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:33Z

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: fix load detect on rn50 with hardcoded EDIDs.

2012-04-22T23:21:45Z

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-22T23:21:45Z

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-22T23:21:45Z

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/radeon: only add the mm i2c bus if the hw_i2c module param is set

2012-04-22T23:21:22Z

commit 46783150a6552f9513f08e62cfcc07125d6e502b upstream. It seems it can corrupt the monitor EDID in certain cases on certain boards when running sensors detect. It's rarely used anyway outside of AIW boards. http://lists.lm-sensors.org/pipermail/lm-sensors/2012-April/035847.html http://lists.freedesktop.org/archives/xorg/2011-January/052239.html Signed-off-by: Alex Deucher Acked-by: Jean Delvare Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

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

2012-04-22T23:21:22Z

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: quirk away broken OpRegion VBT

2012-04-13T15:14:07Z

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:14:06Z

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