kernel/drivers/gpu, branch linux-3.3.y

nouveau: nouveau_set_bo_placement takes TTM flags

2012-06-01T07:15:51Z

commit c284815debba2f14ee2fd07b1b4cc972ab116110 upstream. This seems to be wrong to me, spotted while thinking about dma-buf. Reviewed-by: Ben Skeggs Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

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

2012-06-01T07:15:51Z

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:15:50Z

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:15:50Z

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

gma500: Fix Poulsbo suspend/resume crash on devices with SDVO ports

2012-06-01T07:15:50Z

commit 7beff62ee39d3ccf088bb77f61a63037f714d235 upstream. Reported-by: Guillaume Clément Signed-off-by: Alan Cox Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+

2012-05-12T16:32:04Z

commit 2e7a44814d802c8ba479164b8924070cd908d6b5 upstream. I've flagged this while reviewing the first version and Ken Graunke fixed it up in v2, but unfortunately Dave Airlie picked up the wrong version. Cc: Dave Airlie Cc: Kenneth Graunke Signed-Off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: disable sdvo hotplug on i945g/gm

2012-05-12T16:32:04Z

commit 768b107e4b3be0acf6f58e914afe4f337c00932b upstream. Chris Wilson dug out a hw erratum saying that there's noise on the interrupt line on i945G chips. We also have a bug report from a i945GM chip with an sdvo hotplug interrupt storm (and no apparent cause). Play it safe and disable sdvo hotplug on all i945 variants. Note that this is a regression that has been introduced in 3.1, when we've enabled sdvo hotplug support with commit cc68c81aed7d892deaf12d720d5455208e94cd0a Author: Simon Farnsworth Date: Wed Sep 21 17:13:30 2011 +0100 drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442 Reported-and-tested-by: Dominik Köppl Reviewed-by: Chris Wilson Signed-Off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: enable dip before writing data on gen4

2012-05-12T16:32:03Z

commit c1230df7e19e0f27655c0eb9d966c7e03be7cc50 upstream. While testing with the intel_infoframes tool on gen4, I see that when video DIP is disabled, what we write to the DATA memory is not exactly what we read back later. This regression has been introduce in commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b Author: Jesse Barnes Date: Thu Sep 22 11:16:00 2011 +0530 drm/i915: fix ILK+ infoframe support That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Tested-by: Yang Guang Signed-off-by: Paulo Zanoni Reviewed-by: Eugeni Dodonov [danvet: Pimped commit message by using the usual commit citation layout.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

nouveau: initialise has_optimus variable.

2012-05-07T15:53:36Z

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

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